SharedSound Module 1.11
Colin Ferris (399) 1818 posts |
Running RO 5.19 5-Mar-13 – SharedSound 1.11 |
Colin Ferris (399) 1818 posts |
Just an update: The SharedSound version 1.12 (14 Apr 2013) from RO 5.21 – seems to be working ok with RO 5.19. 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. Has anyone done a “AMPlayer” module that uses the hardware FPU of the “Beagle” etc? |
jim lesurf (2082) 1438 posts |
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 |
jim lesurf (2082) 1438 posts |
Grrr. Found it. Although the API says SoundControl_ for the swi prefix it is in reality SoundCtrl_. So much for the API document! :-/ Jim |
Colin Ferris (399) 1818 posts |
Which module does SoundCtrl reside in – it doesn’t seem to in the RPC version of RO5? |
jim lesurf (2082) 1438 posts |
Its provided by the ‘SoundControl’ module. On the ARMiniX if you do a 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 |
Chris (121) 472 posts |
Sources are at castle/RiscOS/Sources/Audio/SoundCtrl Here’s a link to the files online. Looks like it’s written in C. |
Colin Ferris (399) 1818 posts |
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! Would be handy if someone could do a *rmsave of the module – and put a link to it. The module looks to be in Assembler – no Procedures :-( But someone likes their 26bit bits! ie |
jim lesurf (2082) 1438 posts |
Thanks, I’ll have a look, but almost certainly won’t understand it! :-/ Jim |
jim lesurf (2082) 1438 posts |
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 |
Rick Murray (539) 13850 posts |
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. |
Jeffrey Lee (213) 6048 posts |
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? |
Rick Murray (539) 13850 posts |
Oh, right. I ignored that link because Colin is talking about assembler and Chris’ link was to C code.
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… |
jim lesurf (2082) 1438 posts |
IIUC the sources are available via files like 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 Am I correct to think the SoundControl ‘system’ gain is applied before the ‘headphone’ gain, but comes after the established 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. |
Trevor Johnson (329) 1645 posts |
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.
In which case I guess it’s nothing to do with ESP’s sources. |
jim lesurf (2082) 1438 posts |
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 Jim |
nemo (145) 2556 posts |
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’. |
Jeffrey Lee (213) 6048 posts |
Correct. |
jim lesurf (2082) 1438 posts |
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 |
jim lesurf (2082) 1438 posts |
Just did a quick test. Either I was doing something wrong or the ‘system’ gain for MixVolume isn’t working. I tried using 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 |
nemo (145) 2556 posts |
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). |
jim lesurf (2082) 1438 posts |
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 |
Rick Murray (539) 13850 posts |
Ring a bell then clap twice… |
Trevor Johnson (329) 1645 posts |
The Priest? How about The Sentinel? |
jim lesurf (2082) 1438 posts |
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
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 |