SharedSound Module 1.11

Running RO 5.19 5-Mar-13 – SharedSound 1.11
Using !LIRC (32bit Speak) and !MP3Radio.
There seems to be a conflict between them that is not there with SSound 1.07 (22 Mar 2002).
When ‘Darwin Radio oz’ is playing – and Speak is used in !LIRC – the radio cuts off – but doesn’t come back after the !LIRC speaking ends – which it does in SSound 1.07.
Any ideas?
Thanks

Just an update: The SharedSound version 1.12 (14 Apr 2013) from RO 5.21 – seems to be working ok with RO 5.19.
(RO 5.21 seems to need a new !Boot – which could be tricky – after all the mods over the years)

Is there a standard “SharedSound” module for all to use – it seems that the Iyonix RO 5.21 is different from the RPC version?

Is there full docs on using the “SSound” module – Jim Lesurf is asking on Acorn Programmer News group.
The stronghelp docs seems to be missing some SWI’s.

Has anyone done a “AMPlayer” module that uses the hardware FPU of the “Beagle” etc?

Is there full docs on using the “SSound” module – Jim Lesurf is asking on Acorn Programmer News group.

I do now have some documents that list SWI APIs for SharedSound and SoundControl. My current problem is getting them to work!

As I posted yesterday in c.s.a.prog, I’ve been writing some simple ‘Acorn/ROOL C’ progs to probe SoundControl_ but the programs don’t work. This is almost certainly an error on my part, but I haven’t found it. I’m wondering if the ‘mixer’ is simply being mis-set in some way that could explain the weird gross clipping behaviour I’ve been reporting.

As I’ve explained in the ‘audio puzzles’ topic on ‘General’ I can do checks and measurements to try and narrow down which sections of the chain from source to output might be causing the clipping. But I can’t read the assembler. So can only try and find which parts of the chain need investigation. At present it looks like somewhere in SharedSound or SoundControl or their settings. But this is only based on a process of elimination that may have missed something. (If people don’t know the background I’d request they read the audio puzzles topic on the General part of the forum. I’ve been wondering if I needed to explicitly raise this as a ‘bug’ here, so decided to respond here.)

BTW might it be practical/useful for me to try out newer versions of ShardedSound/SoundControl on my ARMiniX to see if that removes the clipping problem? If so, can someone tell me where to get the modules and and info I’d need to be able to use them OK?

Jim

As I posted yesterday in c.s.a.prog, I’ve been writing some simple ‘Acorn/ROOL C’ progs to probe SoundControl_ but the programs don’t work.

Grrr. Found it. Although the API says SoundControl_ for the swi prefix it is in reality SoundCtrl_. So much for the API document! :-/

Jim

Which module does SoundCtrl reside in – it doesn’t seem to in the RPC version of RO5?
SharedSound module is by ESP – I think – ie you don’t have to use it.
It seems that ‘espeak’ doesn’t.
Still getting a conflict between !MP3Radio/AMPlayer and !LIRC – espeak/speak.
Gone back to version SharedSound 1.07 – to see how it goes.

Which module does SoundCtrl reside in – it doesn’t seem to in the RPC version of RO5?

Its provided by the ‘SoundControl’ module.

On the ARMiniX if you do a help soundcontrol in a taskwindow it tells you that the machine has version 1.03 of the module and that it provides the *MixVolume command.

It also provides some swis that allow you to set and find out the settings, etc. Those were the ones whose name was incorrect in the API doc. I’m currently experimenting with writing a simple ‘probe’ program that will use these swis to tell the user all the current (nominal) settings. This is because the clipping might be caused by either something odd in the module or some inappropriate setting.

A possibility that – from what you say – may be consistent with the RPC not showing the clipping.

Too early to say.

If someone knows where on the CVS the code sits for the module, I’d be at least curious to get a copy. Although as I’ve explained, my ability to make sense of assembler is pretty low.

If I get a working probe for the SoundControl settings I’ll add that to the programs I’ve made available for probing PlayIt and other modules. People can then use them to poke about for themselves if they wish.

Jim

Sources are at castle/RiscOS/Sources/Audio/SoundCtrl

Here’s a link to the files online. Looks like it’s written in C.

How are you supposed to find it in there :-(

Have downloaded the OMAP4Dev5/21 – and dug out the module.

Is that where the *MixVolume is hiding!
SoundCtrl_ExamineMixer
SoundCtrl_SetMix
SoundCtrl_GetMix

Would be handy if someone could do a *rmsave of the module – and put a link to it.
Or use !Verma to extract it.

The module looks to be in Assembler – no Procedures :-(

But someone likes their 26bit bits!

ie
teq pc,pc
movne r8,pc
bicne r3,r8,#3
etc
Why in a 32bit only machine?

Here’s a link to the files online. Looks like it’s written in C

Thanks, I’ll have a look, but almost certainly won’t understand it! :-/

Jim

Is that where the *MixVolume is hiding!
SoundCtrl_ExamineMixer
SoundCtrl_SetMix
SoundCtrl_GetMix

FWIW I’ve now written a couple of progs that run though using _ExamineMixer and _GetMix to show the details. When I can I’ll pop a zip on the web so others can see what values/results they get.

Jim

But someone likes their 26bit bits!

ie
teq pc,pc
movne r8,pc
bicne r3,r8,#3
etc
Why in a 32bit only machine?

It doesn’t look as if anybody has replied to this, so…

On a 26 bit machine, comparing PC with PC will return different results as one operand will offer the pure PC, while the other will be the PC with the PSR bits. Therefore, comparing PC with itself in this respect will always return non-equal.

On a 32 bit machine, PC is PC. End of. Thus the result will always be equal.

Following the rest, on 26 bit machines only (condition NE), PC is copied into R8, and then bits zero and one are cleared and the result put into R3. You have not provided a link to where the sources may be found in the on-line CVS (or a path to where they are in your downloaded version), so I can’t say what the code is doing.
At any rate, it isn’t unexpected. It appears to be a 26 bit behaviour “option”. ;-)

You have not provided a link to where the sources may be found in the on-line CVS (or a path to where they are in your downloaded version), so I can’t say what the code is doing.

Read Chris’s post :)

That snippet of code that Colin has posted is almost certainly some assembler that CMHG has generated for the SWI/vector veneers. And despite what Colin says, SoundControl is written in C. I’m guessing Colin thought it was assembler because there aren’t any function names embedded in it; but if you’re building a release version of the module for embedding in a ROM, why waste valueable bytes on function names?

Oh, right. I ignored that link because Colin is talking about assembler and Chris’ link was to C code.
Okay, I’m with you now… ;-)

why waste valueable bytes on function names?

Ditto anything compiled with, IIRC, the -ff option to strip out function names. Can be useful to obscure what it going on, or hide from the world that you are crazy enough to name your functions after all of the characters in Daria. But it makes backtraces hellish – lots of anonymous functions…

IIUC the sources are available via files like

http://www.riscosopen.org/viewer/view/~checkout~/castle/RiscOS/Sources/Audio/SoundCtrl/c/module?rev=1.2;content-type=text%2Fplain

etc.

I couldn’t see any sign of a zip or tarball that contains all the files in their correct relative arrangements. So I downloaded the ones I found as a set of individual files. Whether I’ll ever be able to make sense of them is another matter! :-)

In general terms, the problem I face at present is one familiar to me as an engineer in other areas. Described by the maxim I’ve used before:

That in theory, theory and practice agree. But in practice they don’t.

In this case the documentation and what people tell me about what the code “should” do simply conflicts with the measurements. Given so many chunks of code, for more than module, etc, I’ve therefore been trying to eliminate areas from suspicion and see where others look plausible as candidates.

As yet my impression is that the cause of the unwanted gain/clipping is in the area of SharedSound and SoundControl and their settings and the way they may attach to the hardware layers. Specifically in between *volume and the ‘headphone’ gain provided by SoundControl.

Am I correct to think the SoundControl ‘system’ gain is applied before the ‘headphone’ gain, but comes after the established *volume gain? One of the next steps I plan is to try adjusting the SoundControl ‘system’ gain value to see it behaves like either the ‘headphone’ or *volume gain wrt clipping. At some point I’ll also try measurements with low level signals to see if I can use quantisation signatures as a clue to what is happening, and which option might give the best work-around until the problem is fixed.

I’ll keep looking. But given that Jeffrey is busy I’d certainly welcome someone who knows ‘C’ better than me having a look at this if they are willing.

in the area of SharedSound …

Further to the 2011 source release arranged with ESP Music, perhaps Andy Pierson may be willing to spare a small amount of time sharing his wisdom from memory (I doubt it’s realistic to expect an in-depth explanation/dusting off source code and working out what’s happenning all over again). I guess you’re hoping for the shedding of light and a few pointers, really.

… and SoundControl

In which case I guess it’s nothing to do with ESP’s sources.

Yes, I’m really just hoping that someone else with more understanding of the kind of coding involved may have a look. I can’t say if the problem is in SharedSound, or SoundControl, or in how they may interface with the hardware, or something odd about how the are being fed settings. So far all I’ve done is narrow it down to being in this area. The critical thing is that something goes wrong in between *volume and the ‘headphone’ gain setting of SoundControl. Beyond that, what and where exactly, I haven’t been able to pin down. Although I’m hoping to narrow this down a bit more or see if I can find other symptoms that may be diagnostic. My guess is that – when found – the problem will be ‘trivial’. But finding it may be more difficult. Needle in a haystack. I’m trying to reduce the volume of haystack that needs to be searched and get a better idea of what this particular ‘needle’ would look like! Plus aiming to see if their is an optimal way to minimise the damage it does.

Jim

SoundCtrl does nothing itself with the MixVolume value, it just sends it to the SetMix function of the appropriate mixer device.

So the actual gain is performed in the HAL Audio code for the platform in question… and it does different things for different ‘devices’.

Am I correct to think the SoundControl ‘system’ gain is applied before the ‘headphone’ gain, but comes after the established *volume gain?

Correct.

So the actual gain is performed in the HAL Audio code for the platform in question… and it does different things for different ‘devices’.

Ah! I was thinking of asking about that. So could the problem be that SoundControl is sending a ‘system gain setting’ value via the HAL to the TI chip that “should” mean ‘0dB. But that the value received by the chip is one which tells it ’XdB’ where X is large enough to get it to scale up the values by about x3?

I’ve been wondering about that, and the fact that x3 (base 10) is x11 (binary) and that maybe a binary ‘1’ is being accidentally turned into a binary ‘11’ somewhere along the way as a scaling factor to be applied?

There are other problems with the HAL. The deafeningly obvious one being the way trying to use 44.1/48k system rates cause mono in the baseband plus L-R double-sideband-suppressed carrier around a (suppressed) carrier frequency equal to the system rate. At least I know the reason for that!

This could also explain why the ‘headphone’ setting preserves any clipping. The chip may faithfully apply that gain after applying the x3 its been told (so far as it knows) to apply to the samples given to it.

Also, if these factors are being applied in the chip, it would help explain why the result is pretty clean when shy of clipping. The factors may be being applied to the values in 24bit form (or 32. not checked the sizes the chip uses internally) and being well dithered/noise-shaped as I’d expect from a good chip with its own gain stages.

Jim

Just did a quick test. Either I was doing something wrong or the ‘system’ gain for MixVolume isn’t working.

I tried using *MixVolume 0 0 0 0 <N> a few times with values of N ranging between +/-128. Using _GetMix and _ExamineMixer I could see the stated gain value change. (Changes showed with full 1/16dB resolution, not quantised to 6dB granularity.

However the actual volume of what I listened to didn’t change.

I was using DigitalCD to play LPCM wave. Tried changing MixVolume when DCD wasn’t running and nothing was playing. Still no effect.

Have I misunderstood or forgotten something?

Jim

So could the problem be that SoundControl is sending a ‘system gain setting’ value via the HAL to the TI chip that “should” mean ‘0dB. But that the value received by the chip is one which tells it ’XdB’ where X is large enough to get it to scale up the values by about x3?

Yes, in that SoundCtrl sends the value to the HAL, then the HAL code transmogrifies it into values to send to the hardware (if the hardware supports such a thing).

The HAL code is quite capable of getting the transmogrification wrong (stop me if I get too technical).

The HAL code is quite capable of getting the transmogrification wrong (stop me if I get too technical).

That’s OK. Its transsubstantiation that is a step too far for me. Mind you, I’m not keen on wine and biscuits as I can’t eat cheese these days. 8-]

However unless I made a mistake [no surprise if I did] then the ‘system’ value may not be getting through at all! Maybe we need a priest…

Jim

Maybe we need a priest…

Ring a bell then clap twice…

The Priest? How about The Sentinel?

Willi kindly contacted me this morning to confirm that the ‘system’ mixer gain control does nothing.

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.

Not having a clue I am wondering if these (binary)‘11’ values might mean a gain of x3.

I’ve asked Willi, but I’m just guessing so this is probably nonsense.

Jim