SharedSound Module 1.11

AIUI Willi and others are hampered by not having the full datasheets for the TI twl6040 audio chip. It took me months to prise out of TI the full datasheet of another of the TI chips on the PandaBoard for Willi.
For the last few months TI keeps telling me to contact one of their distributors and the distributors keep sending me the nine page chip summary. I’ll chase yet again on Monday if I can find the time.

Thanks Chris,

I’d also love to have the data. I do have some documents, but they lack any real detail in this area. I do appreciate that Willi and others have been facing many difficulties in ways like this. So I hope people don’t think I’m trying to make negative comments about them or their work! Just that I’m keen to get the most obvious problems sorted.

That said, I do have a 37 page PDF on the TWL6040. If you don’t have that and would like a copy, please let me know!

Jim

In my sheer ignorance I’ve also just noticed a line in the code for the ‘MixerTemplate’ of the HAL/OMAP which has
DCW &1B ; MixerSystemGain
which seems to be telling the mixer chip the main gain is fixed at &1B = (binary) 11011.

I’ve now had some discussions with Willi about the above.

AIUI the above is just a ‘placeholder’ value which gets overwritten later. More to the point this ‘system/ gain is for the inputs (i.e. AUX in, etc) not applied to output. So far as Willi is concerned the only output is ’headphone’. From the explanations he gave to me he made clear that he feels the clipping can’t be in the HAL/OMAP. Must be in one of the modules (SharedSound, SoundControl, etc) that feed into the SoundDMA.

His arguments sound perfectly reasonable to me, so may well be correct. Hence we still need to look at those areas. However – as with many other explanations I’ve been given – there is the possiblility that we are assuming that what happens in a give stage is actually what “should” happen. Clearly something somewhere is not behaving as it “should”.

I did some experiments a few days ago by modifying one of the PlugIns for DigitalCD to show me the values it is outputting in terms of a roughly calibrated PPM. This doesn’t show clipped values. So that observation implies that whatever buffer stage is being monitored “should” be before clipping. However I have some doubts and uncertainties about that which I want to ask about in case Andre or someone else can shed light.

The DCD SWIs seem to return ‘char2’ values and then examine just one byte to get a look at the MSByte for the PowerBars plugin (which I hacked). I’m not clear if these values are reading back from the SoundDMA buffers or from earlier in the chain. Can someone say? I’ll have more of a poke about.

What I have in mind here is reading back the actual values being placed into the SoundDMA buffers.

IF all the SoundControl/SharedSound/SoundDMA modules are working as the “should” would I be correct to deduce that IF the values read from the SoundDMA buffers cover the full range and accord with the input THEN the clipping MUST be after all these modules? And would that show the problem is in the HAL/OMAP?

The corrolary being that if the values reaching SoundDMA buffers are limited (or scaled up by x3) then the problem IS in one of the modules, not the HAL/OMAP?

Jim

It seems that SharedSound is a extra module – you may find a earlier Playit – not using it.
One less module to remove from the chain.

Like this ? ;-)
(Sorry Jeffrey!)

Update on my earlier comments.

I’ve now tried using DigitalCD with both the standard ‘PowerBars’ and my modified ‘PPM’ version. IIUC the DCD Help correctly the swi does read back from the SoundDMA buffer.

The results seem to indicate that the clipping occurs at or before this point. i.e. The problem is somewhere in the modules / settings prior to data being given to the DMA buffers not in the HAL/OMAP/Hardware.

The indicators get to about full range with a *volume of about 100. Changes in this value alter the audio output and the indicated levels.

However the behaviour of *volume is rather strange and I’m not sure it does what the PRM specifies.

e.g. *volume values that are as low as, say, 5, give a bigger indicated level than, say, 20! Yet do sound quieter. And higher levels don’t seem to fit the model of the value being in 16ths of a dB.

This is quite hard to see so I may have to write a fresh plugin to really examine the values with more care. The PowerBars one uses ‘char2’ and then seems to rip off the top byte to get a size. Maybe this is futzing the results for smaller values that still show something in the top byte.

But if the higher levels are working fairly well, it does seem to point the finger back at the modules rather than the HAL.

Comments welcome.

I’ll see if I can bypass various modules, or do some other experiments to again try and narrow this.

Good idea to see if I can bypass SharedSound.

But I’m now off to do some gardening… :-)

Jim

Hi Raik – that version seems to need – SharedSound – need something earlier.

Noticed with !MP3Radio/Amplayer – with the Iyonix 5.16
*aminfo gives
44100Hz
Should amplayer be outputting 48000 Hz
What system freqs should be used – with the various hardward?
How can you tell – what the machine uses?

Sorry. I do not understand everything well (linguistically and factually) what is written here;-). SharedSound is included in this PlayIt but I do not know if that can help.
At that time, it worked on my xM and Panda.

What system freqs should be used – with the various hardward?
How can you tell – what the machine uses?

These may help

http://jcgl.orpheusweb.co.uk/temp/PandaAudio.zip
http://jcgl.orpheusweb.co.uk/temp/scprogs.zip

The ‘PandaAudio’ zip contains a set of programs for finding out the current settings, what rates are available, and changing settings.

scprogs contains two utilities that list the SoundControl settings.

Note I’ve only used these on my ARminiX, so they may not work on something else! And the program to probe the state of PlayIt will only give a meaningful result if PlayIt is loaded and in use.

In general principle you should use a system rate that matches the file’s source rate. However in practice that may foul things up. So on the ARminiX you should use a system rate of 88.2k for 44.1k material. Can’t comment on the other ‘new’ machines as I’ve not tested/tried them.

Jim

Correction / update to what I wrote earlier wrt using DigitalCD and reading back values.

At the time I was using the DiskSample driver. I think that has its own internal auto-gain control. So I re-did the test with DigitalCD using PlayIt. (Probing the handle given to SharedSound confirmed this.)

The *volume results changed. This time issuing new volume values had only a quite small effect on the displayed results provided I kept to the range 127 – 3. There was some change in indicated level. But much smaller than when I used DiskSample as the driver. However I could clearly hear the volume scale up and down. Values below 3 simply caused the displayed level to fall to zero.

This makes me suspect that the DigitalCD swi I’m using to get values back from DMA is applying a ‘correction’ for the *volume value so hiding its effect. if so: I’m not seeing the actual DMA buffer values. Damn! I’ll have to poke about to see if I can remove that problem.

Jim

IF all the SoundControl/SharedSound/SoundDMA modules are working as the “should” would I be correct to deduce that IF the values read from the SoundDMA buffers cover the full range and accord with the input THEN the clipping MUST be after all these modules? And would that show the problem is in the HAL/OMAP?

Correct.

If you want to eliminate DigitalCD from the equation then there’s some sample code I wrote a few years ago for playing back WAV files using SharedSound over on the iconbar. The code is a bit nasty, but if you make sure that it’s given a mono/stereo 16bit WAV at the same sample rate that the system is using then it will play it back without modifying the samples in any way (no volume adjustment, no frequency adjustment, etc.). Although the article itself is a bit old I did update the source/binary a few years ago to make it ARMv7 safe (tested on BB I think, but PandaBoard should be the same). I think it would also be pretty straightforward to modify it to register directly with Sound_LinearHandler, to cut out SharedSound.

If you want to eliminate DigitalCD from the equation then there’s some sample code I wrote a few years ago for playing back WAV files using SharedSound over on the iconbar. The code is a bit nasty, but if you make sure that it’s given a mono/stereo 16bit WAV at the same sample rate that the system is using then it will play it back without modifying the samples in any way (no volume adjustment, no frequency adjustment, etc.).

Thanks for that, Jeffrey. I think it gives a clear indicator.

I played two test files.Both 88.2k rate (with my ARMiniX system rate set to 88.2k) stereo LPCM wave. One file a ‘full range’ 0dBFS 300Hz sinewave. The other similar but -10dBFS.

The first one clips exactly as when I play files either with *volume set to 127 or bypassing this volume.

The second is free of clipping.

So I take it from that we can reliably conclude that the problem is somewhere between the values being given to SharedSound and the output?

What I’m curious about is trying to determine the values being stuffed into the SoundDMA buffers. As I guess that is the effective ‘doorway’ between the module layers and the HAL/OMAP. Want to resolve which side of this doorway the clipping is being applied. Willi is confident it must be on the module side.

I’d hoped the DigitalCD swi / plugin would give me that, but I’m now thinking it may ‘correct’ for what it thinks the volume level is doing.

I’ve been wondering about experimenting with the volume values given to SharedSound by the handler, etc. When I read back the values for the handler using the SharedSound_HandlerInfo they seem to say unity gain.

However I’ll see if I can work out how to get to play direct to Sound_LinearHandler. Which in turn makes me wonder if I can get PlayIt to do that…

Jim

To be able to analyze where things might go wrong, wouldn’t it be a good idea to provide a “sound driver” that puts the samples that would be handed over to the HAL into a file?

To be able to analyze where things might go wrong, wouldn’t it be a good idea to provide a “sound driver” that puts the samples that would be handed over to the HAL into a file?

Probably very useful, yes. Ditto for being able to read the values as they are poked into the DMA buffer. Alas, as things are, both of these are way beyond my programming skills! That’s why I tried the trick of seeing if I could ‘hijack’ the DigitalCD swi that says it reads back from the DMA buffer. That way I was able to fiddle what I wanted from modifying an existing DigitalCD ‘plugin’ (PowerBars).

Jim

Can’t help much at the moment as my LCD monitor died on me after 7 years of service and so I am limited to my PC laptop until the new monitor arrives, but concerning DigitalCD:

1) DigitalCD sends volume information to the DCDUtils module which then uses it to rescale wave buffers requested by visualisation plug-ins (so that the waves displayed by te plug-in are independant of the replay volume).

2) The PowerBars uses the char2 typedef because it is only interested in the top 8-bits of the sample so having the generated code reading the top byte via an LDRB was the fastest. If you need the whole 16-bits, replace the char2 by a ‘signed short’ or by a ‘int16_t’ (you need an additional include for te latest, IIRC stdint.h).

3) DigitalCD offers several players like ‘Music Files’, ‘CD xxx’ and ‘Sound Monitor’. With this last one, you will be able to play a track named ‘SoundDMA’. Playing this track will do nothing except feed the SoundDMA buffers to the plug-ins started from that player. In other words you can monitor the sounds made by another (multitasking) player. If the other player is not playing at 100%, you can lower the volume settings of the ‘Sound Monitor’ to match and it will rescale the displayed wave to bring it back to 100%.

So if Jeffrey’s code works from a TaskWindow, using the ‘Sound Monitor’ player with its volume at 100%, you can see what’s in the SoundDMA buffers without any rescaling. Note also that if you untick ‘Single panel mode’ from the choices window, Skins section, you can open at the same type both the ‘Music File’ player and te ‘Sound Monitor’ and thus monitor the sound produced by the ‘Music File’ player as if it was an external player.

Thanks for the info, André. I’ll experiment and see what results I get! :-)

Jim

Is the debug output within SharedSnd enabled? How about related modules?

If you briefly saw a posting from me saying I hadn’t got this working, ignore it! I’ve now sussed how this works and got it working. :-)

I set up DigitalCD to show both the normal player window and a second ‘Sound Monitor’ window with its input set to look at the DMA. I can now get both windows to show Power indicator bars. I’ll do some tests and report.

Jim

Here’s a brief report whilst I ponder and think how to do some cross-checks.

With DCD showing both its normal player window and the ‘Sound Monitor’ one set to take its input from SoundDMA I played some files and experimented.

Start with *volume set to 100, and with both DCD windows ‘100%’ volume.
Using my ‘PPM’ modified version of PowerBars to observe. This is just the PowerBars plugin but hacked to go via a semi-log lookup table so the bar height scales approximately in proportion with the level in dB over the range from 0dBFS to -40dBFs. I also added colour bars at the -3/10/20/30/40dBFS levels (approx) to make estimating the levels easier over this range. ¹

Played a -10dBFS wave file: The player showed its bars up to -10dBFS. The Sound Monitor bars were up to about -19dBFS. That’s about right for *volume set to 100.

Played a 0dBFS wave file: Result matches the above. Player shows max level. Monitor shows about -9dBFS.

No clipping on the above.

So I opened a taskwindow and started typing in changes in the *volume. Going up from 100 to 105, 110, 115, 120, and 127, seeing what happened.

The bars on the Monitor rise much as you’d expect them to. And by the time I have *volume set to 127 they are at the max, matching the bars on the player. However as I typed in each new, higher value, the result became more and more clipped.

IIUC that correctly it clearly implies that the SoundDMA values are being increased to cover the full range. Nothing is clipping the values before they are given to the SoundDMA buffers, and nothing is scaling them up so that they clip well before the input reaches 0dBFS.

If so, the implication is, I presume, that the clipping is occuring after the values in the SoundDMA buffers are taken away though the HAL, etc.

Interested to see what people make of that.

BTW The more I use DigitalCD, the more impressed with it I become! :-)

Jim

¹ When I get a chance I’ll put up a copy of my ‘PPM’ plugin so anyone who wishes can check to see if I’ve made an error, or even use it if they wish.

Is the debug output within SharedSnd enabled? How about related modules?

No idea. Someone else may have to explain that! But if what I wrote earlier is correct I guess it won’t matter.

Jim

Followon from the above to ask some questions about the SharedSound swis, etc.

I’ve been extending the number of sound settings that my !SoundCheck app will read and display. For SharedSound I’m using the SharedSound_HandlerInfo swi.

This does list active handlers nicely. In fact I was impressed to find that I could use PlaySound+PlayIt to play a 44.1k wave file symultaneously with using DigitalCD+DiskSample to play a 88.2k flac. They played mixed together at their correct speeds, and both handlers where identified and named Ok by the _HandlerInfo swi. (And at the same time I was using DigitalCD to monitor the sizes of the values in the DMA buffers! :-) )

However although Robin Watt’s document on the swi says that r³ returns the sample rate this always returns a zero. Is this not working or am I doing something wrong?

Jim

However although Robin Watt’s document on the swi says that r3 returns the sample rate this always returns a zero. Is this not working or am I doing something wrong?

Is this accepted as a possible bug in SharedSound? I can’t get a sample rate
other than ‘0’ returned in r³ when using SharedSound_HandlerInfo.

I’ve also been told that the SoundControl swis return some strange values on an Iyonix. Is this a known problem?

Anyone who wants to check can use my !SoundCheck program which is on my audiomisc.co.uk/software.html page. I’ve included the source code so if someone wants they look to see if the problem is in my own code.

Jim

Using this code below:-
produces this output from RPC RO 5.21

RO 0 R1 0 R2 537508980 R3 45158400 R4 0 R5 -1

SYS"SharedSound_HandlerInfo",1 TO R0,R1,R2,R3,R4,R5
PRINT "RO “;R0” R1 “;R1” R2 “;R2” R3 ";R3 " R4 “;R4” R5 ";R5

Using this code below:-
produces this output from RPC RO 5.21

Erm.. was anything being played at the time?

Erm.. was anything being played at the time?The first call you make should be R0 = 0, not 1. That will return a value in R0 that tells you if there are any handlers. If there aren’t (i.e. you’re not playing any sounds) then a call with R0 = 1 may not work.

Erm.. was anything being played at the time?The first call you make should be R0 = 0, not 1. That will return a value in R0 that tells you if there are any handlers. If there aren’t (i.e. you’re not playing any sounds) then a call with R0 = 1 may not work.At least that’s my understanding of the API.

Erm.. was anything being played at the time?The first call you make should be R0 = 0, not 1. That will return a value in R0 that tells you if there are any handlers. If there aren’t (i.e. you’re not playing any sounds) then a call with R0 = 1 may not work.At least that’s my understanding of the API.FWIW The source code for !SoundCheck is in the app, so you can have a look at that to see what I mean (and see if I’ve made a mistake) if you can read ‘C’.

Erm.. was anything being played at the time?The first call you make should be R0 = 0, not 1. That will return a value in R0 that tells you if there are any handlers. If there aren’t (i.e. you’re not playing any sounds) then a call with R0 = 1 may not work.At least that’s my understanding of the API.FWIW The source code for !SoundCheck is in the app, so you can have a look at that to see what I mean (and see if I’ve made a mistake) if you can read ‘C’.Jim

Sorry the above is a mess.

For some reason the forum software added in things I deleted, dulplicated others, and refuses to let me edit it down or remove it!

Jim