RISCOS Filling the I2S buffer

Hi

I have finished testing the programs I have for driving the HIFIberry DACs and Digi cards
these appear to work fine if I fill the buffer with system interrupts set to off.

I have tried driving the cards by using Sharedsound via linear handler and also tried
adding code to Jeffery Lees simple simple sample player but although I get an output
the timing is incorrect I just get noise.

The buffer is only 32 × 32bits on I2S and the buffer fill seems to be much larger on shared
sound and the player so I think this is where the timing issue come from (I think).

I am assuming that if I played a wav file at 44.1khz
through the RISCOS sound system the buffers would contain the data in the correct format
(2x 16bit) 1 for left channel 1 for right channel.

I have downloaded the sources to the Raspberry PI and have been going through the code
this is the first time I have looked at the source so be gentle with me :-)

It looks like Sound0Hal does the main access to the sound hardware although I could be wrong :-)

Could the sound software be redirected to the I2S buffer instead of RISCOS sound output buffer?

The Base Memory used by I2S is 0×20203000
Register CS_A Base+0 (bit 17=1 indicates that the buffer can accept more data)
Register FiFO Base+4 (32 × 32bit buffer)

Most of the information is on page 119-137 in the BCM2835 Arm Peripherals PDF

I am assuming that the RISCOS sound system uses DMA, it may be that someone with
greater knowledge of RISCOS internals could have a go at this if this is the case
i’m sure I could supply a HiFiberry card.

Terry

The buffer is only 32 × 32bits on I2S and the buffer fill seems to be much larger on shared sound and the player so I think this is where the timing issue come from (I think).

Correct.

Could the sound software be redirected to the I2S buffer instead of RISCOS sound output buffer?

A 32 entry FIFO is far too small to be used reliably – it’d generate thousands of interrupts per second. If the CPU is busy doing something else and is slow to respond to the interrupt then the FIFO will drain and you’ll get glitchy output (often resulting in things like the stereo channels becoming swapped because the sender and/or receiver aren’t coping with the data starvation properly).

You’ll need a driver that uses DMA. How this works with Sound0HAL is that your code will program the I2S hardware to operate in DMA mode. Sound0HAL will then use DMAManager to set up the transfer (using information provided by your driver, like the FIFO address, DMA priority level, etc.). There’s some not-newbie-friendly docs on the wiki here which describe the API your driver is expected to implement in order to work with Sound0HAL (aka SoundDMA)

I assumed that the buffer would be much to small to be useful.

I had a quick look at the not-newbie docs wow some reading involved I think :-)

Perhaps I might get some clues from the known implementations list at the bottom of the web page.

Anyway many thanks for your reply

Hi

After a week having to work for a living I am looking at the I2S buffer module again.

I have the following block structures one for the audio device & mixer

; ---------------------------------------------------------------------------
; --------------------- HALDeviceAudio_AudC Template ------------------------
; ---------------------------------------------------------------------------
AudioDeviceTemplate
	DCW	HALDeviceType_Audio + HALDeviceAudio_AudC	; type
	DCW	3;HALDeviceID_AudC_VCHIQ			; id
        DCD     HALDeviceBus_Ser + HALDeviceSerBus_IIS
        DCD     &10000                  			; ver - 1.0
        DCD     AudioDevice_Desc
        DCD     0                       			; Add - N/A
        %       12                      			; Reserved
        DCD     AudioDevice_Activate
        DCD     AudioDevice_Deactivate
        DCD     AudioDevice_Reset
        DCD     AudioDevice_Sleep
        DCD     DeviceNoIRQ					; 55
        DCD     0						; no testIRQ
        %       8						; reserved
; ----- Device Discriptor ends here
        DCD     0 ; MixerDeviceTemplate                       	; Mixer
        DCD     1                      				; Outputs
        DCD     0                       			; Inputs
; ----- Device API 0 ends here (HALDevice_Audio_Size)
        DCD     0                       			; DMA R0 flag
	DCD     LOG_ChanNo            				; DMA R1
        DCD     0                       			; cycle speed
        DCD     2                       			; TX byte
        DCD     FiFoBuff            				; write add
; ----- dmaparams ends here
        DCD     AudioDevice_PreEnable
        DCD     AudioDevice_PostEnable
        DCD     AudioDevice_PreDisable
        DCD     AudioDevice_PostDisable
        DCD     AudioDevice_IRQHandle
	DCD	(AudioRateTable_End-AudioRateTable)/8
	DCD	AudioRateTable
        DCD     AudioDevice_SetRate
; ------ API 1 ends here

; ---------------------------------------------------------------------------


; ---------------------------------------------------------------------------
; --------------------- HALDeviceAudio_Mixer Template -----------------------
; ---------------------------------------------------------------------------
MixerDeviceTemplate
        DCW     HALDeviceType_Audio + HALDeviceAudio_Mixer	; type
	DCW	HALDeviceID_Mixer_Software				; id
  	DCD     HALDeviceBus_Ser + HALDeviceSerBus_IIC
        DCD     &0000                   			; API ver 0.0
        DCD     MixerDevice_Desc
        DCD     0                       			; Add - N/A
        %       12                      			; Reserved
        DCD     MixerDevice_Activate
        DCD     MixerDevice_Deactivate
        DCD     MixerDevice_Reset
        DCD     MixerDevice_Sleep
        DCD     -1                      			; Int N/A
        DCD     0
        %       8
; ----- Device Discriptor ends here
        DCD     AudioDeviceTemplate                       	; AudC
        DCD     MixerChCount            			; Chans
        DCD     MixerDevice_GetFeatures
        DCD     MixerDevice_SetMix
        DCD     MixerDevice_GetMix
        DCD     MixerDevice_GetMixLimits
; ---------------------------------------------------------------------------

In the Initialise routine of the module
I am allocating Workspace and copying the two structures into memory.

I’m then updating the memory to point to the new addresses within the module:-

ADR R1,AudioDevice+12
ADR R0,AudioDevice_Desc
STR R0,[R1]

ADR R1,AudioDevice+32
ADR R0,AudioDevice_Activate
STR R0,[R1]

; -—————- channel number -—————
MOV R0,#1
SWI DMA_AllocateLogicalChannels
ADR R1,AudioDevice+80
STR R0,[R1]
; -—————- channel number -—————

etc.

I have loaded to the workspace into Zap and it looks OK to me. Having said that a little knowledge is a dangerous thing :-)

Most of the routines just return and do very little for instance.

AudioDevice_Reset
MOV pc, lr

After Running the module I expected the AudioDevice_Activate routine to be called at some point but nothing happens.

The only effect I can see is if I run the sound plugin from !boot

On the PI I get the error Mixer not found.
On the Titanium I get an extra option in the audio controller drop down menu and then it crashes.

What kind of responses do the Audio / Mixer
at the most basic level need to allow the module to load correctly.

If anyone wants to look at my efforts so far download from the link below, I could be doing something very silly as programming RISCOS at this low level is very new to me.

http://www.mbelect.co.uk/RISCOS/progs/I2S.zip

Any help would be appreciated

TIA

I Just Looked at the source code and I was doing :-

ADR R0,AudioDeviceTemplate
MOV R8,#3
SWI XOS_Hardware

which should have been

ADR R0,AudioDevice
MOV R8,#3
SWI XOS_Hardware

I now have the no mixer error on the Titanium as well.

I now have DMA audio output streaming over I2S but the sample rate appears to be incorrect.
I have a few questions :-

Do I need to do anything special to initilise the AudioDevice

I am registering both the mixer and the audiodevice using
ADR R0,AudioDevice / Mixer
MOV R8,#2
SWI XOS_Hardware
When I double click to load my module I can see that the mixer activate routine is being run.
If I then try to select my device by using Sound_SelectDefaultController the system halts and mouse movement is very jumpy.
A system restart is needed.

But…
If I double click to load the module the mixer activate routine is being run.
Then Double click !boot
Then double click to load the module the mixer activate routine is being run.
Then I can select the audiodevice from the sound configuration tool.
I then have to double click to load the module again at this point I can see that the mixer & the audio activate routine is then run?
At this point Audio output is then sent over I2S

If I take a wav file(44100) and filetype it as a 0CD type file it plays but slightly to fast.
If I take a wav file(44100) and filetype it as a Waveform type file it plays very very fast.

I have a AudioRateTable and understand that it contains
Freq / time ,0,0,0 in each entry, with frequency increasing in value with each entry
I have tried multiple frequencies and a table with only one entry of 44100
what is the time (1/f=t) setting used for?

I understand the Setrate routine gives an index into this table, once I set the rate
do I have to respond in anyway for the system to know I can accept this rate?

I assumed maybe incorrectly that if I played a wave file that is sampled at 44100khz
it would be played back at 44100khz, I am using digitalCD to test the output
and also the jefferys simple sound player for wav files.

TIA

This is exciting! IMHO you have already done the hardest part. Hopefully you can work out what’s going on the arcanum of RO’s sound handling to get it behaving!

I have fixed the sample rate problem and can play back MP3 & CD quality files using DigitalCD with no problems also once the I2S output is selected all sound from the OS is output to the I2S device.

I can now also issue a Sound_SelectDefaultController command and the system accepts it OK and shows my I2S device in the !boot Sound setup.

I still have to load the module a few times to get it to work maybe I can just issue
*Audio off
*Audio On
commands to reset the sound system once the module is loaded and active
I will try this tomorrow as my PI setup is elsewhere.

I let you know how I get on.

I now have the I2S Module working on my system If you have a HiFiBerry card for the PI
please identify your card before running one of the programs as some cards are masters and some work
as slaves for the data clocks.

you can try by downloading below:-

http://www.mbelect.co.uk/RISCOS/progs/I2S.zip

Please let me know how you get on i have been running the module for some days now without any problems.

What the module does :-

Defines the GPIO pins as :-
GPIO 18 (I2S PCM)
GPIO 19 (I2S LRCK)
GPIO 20 (I2S Din)
GPIO 21 (I2s Dout)
GPIO 05 (used as an output to control HiFiBerry crystal selection)
GPIO 06 (used as an output to control HiFiBerry crystal selection)

Creates A I2S Sound audio device and uses DMA for background sound transfer.
Selects the I2S audio device to be the default controller.
Enables hifiberry cards DMA tranfers or disables the DMA (audio on /off)

You can select between the I2S audio and the standard output device using
the sound configuration module in !boot.

HiFiBerry Dac & Digi Card Setup
I have left the setup of the various cards as seperate BASIC programs
so people can write there own drivers for different cards and still
use the I2S module to enable the audio transfer, the supplied programs are:-

!Dac+Light (IC ES9023 ) uses PI I2S clk for sound generation
!Dac+Standard (IC PCM5122) uses PI I2S clk for sound generation
!Dac_Plus (IC PCM5122) uses its own dual board crystal osc
!Digi_B+ (IC WM8804G) uses its own single on board crystal osc clk
!Digi_Pro (IC WM8804G) uses its own dual board crystal osc

These Programs each load the module from the !module Directory 3 times
because of this once any program is run you will need to reset the computer
before running any of the programs again.

Please note:-
DAC or Digi Board based on the same ICs should work.
The main difference between the lower quality and higher quality boards
is the way the clock for audio is derived in the lower quality boards
they use the PIs I2S clock as a master which drives the HiFiberry board
in the higher quality boards the PI I2S clock becomes a slave which is driven
from the HiFiberry Boards.

Known Problems
I have to load the module 3 times to get it to register correctly ?
I have tried to cure the problem with no success, once the module loads
and registers it then works fine.

If someone with more knowledge wants to look
at the problem you can debug with no DAC or Digi card needed :-

Load the Module by Double Clicking the !module Directory
Double click the BASIC Program activate
This activates the module and then sends
Send a SYS “SharedSound_SampleRate”,0,44100*1024
if it crashes the modules has not reset correctly.
see below for more details.

DEBUGGING

M=Mixer Activate
A=Audio Activate

B=PreEnable
C=PostEnable

E=PreDisable
F=PostDisable

7=SetRate

If I load the Module I get
M
If I send then send SYS “Sound_SelectDefaultController” I get
A7BC

At this point I get a click if I try system beep from sound config.

*Audio off Gives me EF
*Audio on Gives me BC

If I Send a SYS “SharedSound_SampleRate”,0,44100*1024 I get
EF7BC mouse goes jerky system needs a restart.

But…
If I load the Module 3 times? I get
MMM
If I send then send SYS “Sound_SelectDefaultController” I get
A7BC
At this point sound now works OK?

If I Send a SYS “SharedSound_SampleRate”,0,44100*1024 I get
EF7BC now works OK

The only thing I can think of that changes when the module is loaded apart from the
loaded memory and workspace is the allocated logical channel
MOV R0,#1
SWI DMA_AllocateLogicalChannels
ADR R1,AudioDevice+80
STR R0,[R1]

On the first loading it has a values of
1st &1000
2nd &1001
3rd &1002 at this point it works?
4th &1003 will not work after this point

Sorry – I’ve been a bit busy with other things the past few weeks, so haven’t been able to take a look at this. Sometime this week I’ll try and find the time to look at the code and see if I can spot where the problems are.

Hi Jeffrey

I would be most grateful if you could have a quick look at the code
please treat it as unfinshed :-)

It’s a strange error as once it’s registered and activated it then appears to work OK
I am quite willing to have made an error if it fixes the problem though :-)

BTW I meant to say that the code will not work on the PI3 at the moment as it uses slightly different memory addresses I will add these later if Jeffrey has some success tracking down the error. I’m been running the code on a PI B+ for sometime with no problems.

Issues I’ve spotted when reading through the code:

• In the audio device descriptor, the DMA write address you’re using is wrong – it should be the (ARM) physical address of the FIFO, not a logical address. I.e. just use “I2S_Add + FIFO”. (You must have gotten lucky for the current code to work – the DMA driver masks off the top few bits of the address when it converts to the GPU address that’s programmed into the controller)
• You shouldn’t be using DMA_AllocateLogicalChannels for getting the DMA channel number. Instead, just use the number 2. The logical channel number gets passed to the DMA driver in the HAL, and is interpreted as the DMA request number that the channel should respond to. That’s why the module only works properly after you’ve loaded it three times – the hardware register field for storing the DMA request number is only 5 bits wide, so when DMA_AllocateLogicalChannels was returning &1002 it was getting masked down to the correct value of 2.
• On other platforms, a common problem with audio is that if one of the hardware FIFOs becomes empty the stereo channels will go out of sync (and taking a quick look at the BCM2835 manual, I see that they confirm that the Pi has the same behaviour). So to avoid this, we’re careful to only enable the “downstream” bits once the “upstream” buffers are fully filled. I.e. we program the DMA controller, enable the DMA request in the I2S unit, wait for the TX FIFO to become full, and only then enable the external chip (playback / I2S interface). So you’ll probably want:
  • Move (all?) the contents of PreEnable into PostEnable.
  • Possibly add code to PreEnable to manually fill the I2S FIFO with dummy data (i.e. zeros) if it’s not possible to have the DMA fill it prior to the I2S interface being enabled (otherwise you’d get an immediate FIFO underflow when the interface is enabled)
  • Make sure the code which enables playback in the DAC comes at the end of PostEnable (or at some time after PostEnables)
• You’ll want to make sure the mixer device advertises itself as API 0.1, otherwise the GetMixLimits function won’t be called

Hi Jeffrey

Many thanks for looking at the code, my PI setup it in work so I wont be able to try the changes you have advised until next Tuesday.

In the audio device descriptor, the DMA write address you’re using 
is wrong– it should be the (ARM) physical address of the FIFO, not
a logical address. I.e. just use “I2S_Add + FIFO”. (You must have
gotten lucky for the current code to work – the DMA driver masks off
the top few bits of the address when it converts to the GPU address
that’s programmed into the controller)

Having looked at the docs I can see I should have used the physical address I’m so used to using the Logical Addresses when accessing memory mapped areas, your right I was lucky to get any output at all.

You shouldn’t be using DMA_AllocateLogicalChannels for getting the 
DMA channel number. Instead, just use the number 2. The logical 
channel number gets passed to the DMA driver in the HAL, and is
interpreted as the DMA request number that the channel should
respond to. That’s why the module only works properly after you’ve
loaded it three times – the hardware register field for storing the
DMA request number is only 5 bits wide, so when 
DMA_AllocateLogicalChannels was returning &1002 it was getting
masked down to the correct value of 2.

I assumed incorrectly that as the docs asked for a logical channel number I needed to allocate one, does audio always use channel 2, are there any docs that describe the DMA channel uses?.

After doing the changes above I will add in a pre fill buffer routine and hopefully we might have a stable version of the module, many thanks again taking the time to reply and for pushing a newbie in roughly the right direction :-)

A quick update, the advice given by Jeffery worked well, the module now loads correctly and works fine.

All of the driver programs for the HiFI cards work fine on a PI B+.

The one problem remaining is:-
interference when using a PI3, crackling when replaying sound.

I loaded raspbian and can play sound OK but it looks like they had problems of their own with I2S

see:

https://support.hifiberry.com/hc/en-us/community/posts/207256895-Fix-for-DAC-Pro-on-RPi3-disable-bluetooth
https://github.com/raspberrypi/linux/pull/1340

I have compared my RISCOS settings for the I2S clocks and the HiFiberry card registers with Raspbian
and they are the same so I am assuming they made some changes to how the Raspbian kernel interacts with Bluetooth
so that the I2S interference was cured.

I will tidy up the code and release it.

If someone wants to investigate the PI3 problem I am always willing to test any changes.

@Terry Swanborough: Just went to http://www.mbelect.co.uk/RISCOS/progs/I2S.zip to grab a copy of the I2S module and get diverted to a page saying the Serif Webplus.net hosting service has now closed! Is there an alternative site where I can get this module?

Thanks
Robin

It seemed okay earlier in the year – https://web.archive.org/web/20190120012222/http://www.mbelect.co.uk/

I just tried to call (after apologising to some random Frenchie because I forgot the 0044 prefix!) but only an answering machine.

Unfortunately Wayback doesn’t appear to have taken a copy of I2S, perhaps because the RISC OS stuff isn’t linked from the main page (that I can see) so harder to spider.

It was OK a few days ago – the Serif community page gives 01/08/2019 as the date when sites would be blocked from the internet. It looks like there is a short window of opportunity in which to recover the site and then upload to a new host.

Hi

You should find that you can download from http://www.mbelect.co.uk/RISCOS/progs/I2S.zip now.

I have just moved our website to a new host , hours of fun !

Terry

Thanks Terry,

Got it! Now I’ve just got to write a driver for the PCM5101 as used in the HiFiBerry MiniAmp

Robin

Hi

I have only had a quick look at the data sheet and the device does not
seem to have a serial interface so you may find that the !Dac+Light driver
works with the PCM5101.

Terry

How’s it going with this? I finally got around to giving it a try. I’m using a PiFi DAC+ 2.0 which is really just a clone of the PiFiBerry DAC+ Standard. It’s on my Pi 3.
I’m using DigitalCD to play music. First thing I noticed reminded me of the mid 90’s playing an mp3 on my 486 with WinAMP. I had to make sure everything else was closed and disable the track name scrolling to get smooth sound. Of course in that case it was borderline processing power, but the result was a buffer underrun if I so much as breathed too hard near it.
I noticed immediately with DigitalCD that the screen updates, notably the artist and track name can easily upset the audio. Cranking up any buffers I found helped to a degree. TBQH I have no idea what’s what with that.

The crackling is interesting. It sounds like clipping or something similar. Not sure if it’s an audio level issue or what. I was messing with the digital volume level via IIC just now. Besides making my ears hurt and causing some really nasty distortion and clipping with the output turned up near 0 (inverse volume level in the registers)

I feel like there’s some kind of granularity issue. I’m listening to a track via sunfish. Buffer turned up to 4 sec. It’s not affected any differently to a local file now. However even typing this in StrongED is intefering with the music.

As I said above I have checked my settings for the I2S compared to Raspbian and can
see no differences also the code works fine on PI2 so its something to do with
the way the hardware is configured on the PI3.

Have you tried I2S on a PI2?

Terry

Hi. I have a couple of questions.

Are you using the I2S device’s internal clock or the Pi clock?

Would it be totally out of the question to do a basic PCM5102 version? IIRC it’s a lot like the PCM5122 but without digital volume control and no I2C either. I have one connected to the Pi zero that I’m typing this on. The PCM5122 can’t init because it can’t find I2C.
I2S is the only interface connected to the Pi on the basic module boards. The rest is up to the tinkerer.

Hi

If you use the DAC+Light BASIC program all it does is turn on the I2S system
and configures the speed and data format. It does not use I2C to talk to the card.
It also uses the PIs internal clock to drive the I2S data.

I have tried the programs on the PI2 / PI3 but not on a PI zero.

What is the actual error that you are getting?.

I’ll give it a try.

It also uses the PIs internal clock to drive the I2S data.

This. Do the others do this? Because of Pi I2S clock stability issues the PCMxxxx DACs on RPi use their internal clock, running as master.