HiFiBerry Dacs & Digi Boards & FasttickerV

Hi

I have been given some HiFIberry boards for a project at work I have the following :-
DAC+ Light
DAC+ Standard
DAC+ PRO
DIGI+
DIGI+ PRO

They were sitting next to a Raspberry PI running RISCOS so I thought would try to get them running under RISCOS

The DAC+ Light just needs I2S at the right speeds to work it needs on other setup.
The DAC+ Standard DAC+ PRO have a PCM5122 that needs I2C settings before it will work.
The DIGI+ and the DIGI+ PRO have a WM8804G that needs I2C settings before it will work

The good news is I have got these cards working all apart from the DAC+ PRO but that uses the
same chip as the DAC+ Standard so I can’t see that being a problem.

It took a while to get them up and running because some other GPIO pins were being used to control other things
like some boards have two oscillators and the GPIO selected one or the other.

I am currently copying a WAV file to the RAM disc and the streaming the data from the RAM disc to the I2S FIFO
I initially wrote the code in BASIC just to test I had the correct registers, the audio works but has some pops and
distortion. So I assumed that BASIC was to slow so I wrote a buffer fill routine in assembler and that gave the same results?.

So I went away and had a cup of coffee and then I thought interrupts, so I turned those off and it all works fine, in BASIC or
assembler :-)

The I2S on the Pi has a 64byte buffer but it seems that when you use two channels it drops to a 32byte buffer I am using wav / pcn cd audio which is 44,100khz 2 channel stereo which needs about 176,000 samples a second.

The best way of dealing with this would be to detect the interrupt from the I2S FIFO and then fill the buffer on demand this is where I get a bit vague I have no idea of how to do this under RISCOS.

One idea I thought of doing was trying to use fasttickerV is this fast enough to cope with the speed needed? how fast is this timer?. if it was fast enough do other interrupts occur while your in the ticker routine, in an ideal world it would be nice to read data off of a CD to RAM disc and then send this to the I2S FIFO buffer.

I have left work for shutdown now until the new year, once I have all the cards working I intend to release the code and hopefully it will be of use to others as a lot of the donkey work regarding card registers and getting the cards up an running it already done. Somebody with more knowledge of the RISCOS internals might be able to make use of this.

Please, keep going with this!

I’m able to set up the RPi, and talk to the DAC+ Pro (clone) via i2c, but had no idea whatsoever on how to do anything on the RISC OS side.
Only a couple of months ago I pulled apart a Zero I had set up with DAC and SPI ethernet because I was using RO on it and couldn’t use the hardware. And a few days ago shifted from using my Pi3 to Pi 1B becuase I wanted to use the DAC on my Pi3 again. Two different DACs there.

If you need someone to test code, please do say so.

Any DACs that use the same chip set should work but some cards do use GPIO
to switch things so you need to watch out for that.

I will finish the code when I get back to work and let you know where
you can download it from. At the moment while playing it turns the interrupts off
completely not a good idea but its really only test code at the moment.

I have an idea that might work as reading other threads here it seems that fasttickerV
is not supported by RISCOS 5, So I thought I might be able to jump onto the interrupt that fills
the internal sound system buffer but as I said this really is new territory for me.

something like OS_ClaimDeviceVector & DMA sound channel 0 OR DMA sound channel 1
I assume gets triggered when the sound buffer needs filling but as I said I’m guessing.

something like OS_ClaimDeviceVector & DMA sound channel 0 OR DMA sound channel 1

You might get away with claiming the Linear Handler after setting a suitable Sample rate and fill your device buffer instead of the SoundDMA buffer. I’m assuming you can poll the device to see if more data can be sent and that it’s not dependent on being filled at exhaustion.

You’ll want to pass the call onto the previous claimant once you’ve done your thing, if you want SharedSound to continue working.

Hi Jon

That looks like a good idea.

I’m using 44.1khz CD Audio mainly so I’ll release the code with interrupts switched off first just to let people
test to see if it works on other boards OK. I will then try your idea above an see how I get on.

Do you know what the workspace referred to by R2 in Sound_LinearHandler 1 is?
Is it just used for scratch pad memory?

Do you know what the workspace referred to by R2 in Sound_LinearHandler 1 is?

As documented, it’s the default value in R0 when your handler is called.

@Terry Swanborough: Did you release the code somewhere? Risc OS is the only OS on my Pi where I don’t have the Hifiberry working, and I would love to! :)

HI

The software is available from the link below:-
www.mbelect.co.uk/RISCOS/progs/HIFIberry.zip

Unzip the contents of the zip file copy the file corresponding to your HIFIberry card light / standard etc to your harddisc
copy the test/wav file from the classical folder to a RAM disc

These programs will play any wav file @44.1Khz in the ram disc on the HIFIberry cards
! Please note these programs are for test only system interrupts are turned OFF while the music is playing.

@Terry: Are there plans to allow the HiFiBerry to be used as the main sound output for Risc OS?

Yes that’s the idea I’m currently looking at DMA after Jeffrey Lee gave me some direction
This is something I have not tried before but I work with micro-controllers for a living
so I trying to imagine that RiscOS is a giant micro-controller :-)

I am trying to write a module (never tried that before) and then register the audio with
HALDeviceAudio_AudC for I2S support.

If your reading this Jeffery I looked at the DeviceNumber in the device descriptor and think
I should be using the value 20 but in some sources I have looked at they use 50? the docs
say this value gets passed on to OS_ClaimDeviceVector
Can I also set bit 31 of the DeviceNumber to pass the interrupt to the original RISCOS sound system.

TIA for the help as this is all very new to me.

Terry

If your reading this Jeffery I looked at the DeviceNumber in the device descriptor and think I should be using the value 20 but in some sources I have looked at they use 50? the docs say this value gets passed on to OS_ClaimDeviceVector

I believe 55 is the correct device number for the PCM/I2S controller.

https://www.riscosopen.org/viewer/view/mixed/RiscOS/Sources/HAL/BCM2835/hdr/BCM2835?rev=1.31#l557

Different platforms map their IRQ/device numbers differently, so copying a value from e.g. the Iyonix or OMAP sources isn’t likely to work!

Can I also set bit 31 of the DeviceNumber to pass the interrupt to the original RISCOS sound system.

No. Bit 31 is used if there are multiple devices in the system which have the same IRQ/device number. Since the PCM/I2S controller is the only thing assigned to device 55, there’s no need to set the bit.

As for passing the interrupt on (so that both audio devices can be active at once?) – that’s not supported yet. For SoundDMA to support concurrent output to multiple devices (one input audio stream being split to multiple outputs) there’d probably have to be an extra layer of buffering. You’ve got things to worry about like device-specific buffer size restrictions & data format restrictions (e.g. L/R channel ordering), different sample rates being supported (or even if they both support the same sample rate, there could be clock inaccuracies which will lead to large errors over time), buffer filling being out of sync due to interrupt timing or devices buffering different amounts of data internally, etc.

Thanks for the info I did read in the ARM peripherals PDF page 113 that PCM used 55
but I think the fact that it was connected with OS_ClaimDeviceVector confused me :-)

I have a module compiling with the device structures my plan is to try to get basic data
just streaming into the FiFo and then hopefully expand it from there. A bit of a steep
learning curve going on here :-)

Terry