audio puzzles, etc

Regarding *volume, you can make DigitalCD to ignore it (Choices window, at the bottom of Players section, tick “Ignore system volume”).

Regarding the x2.5 factor, if not for the fact that DigitalCD always sets to 0 bit 2 of PlayIt_Config,0 I would have suspected PlayIt’s strange way of taking into account the value of *volume. To be sure to eliminate PlayIt as the suspect you could always let DigitalCD play PCM wave files with te help of DiskSample. Edit the !DCDRes.Setup file and modify the entry for wave as follow “!FB1 = smp, playit”. Save the file and restart DigitalCD. Now DigitalCD will first ask DiskSample to play these files and only pass to PlayIt formats which DiskSample cannot play (ADPCM, …).

If the problem persists, I would suggest that you first confirm that setting different values of *SoundGain really doesn’t affect the output, then use *MixVolume to ensure that hardware amplification is 0dB (and control it with SWI SoundControl_GetMix mentionned in Jeffrey’s doc). In that regard, it would actually be nice if all those *Volume, *SoundGain and *MixVolume commands would list the current values if you don’t provide any parameters.

Regarding *volume, you can make DigitalCD to ignore it (Choices window, at the bottom of Players section, tick “Ignore system volume”).

Yes. However that brings me to another puzzle… cf below.

Regarding the x2.5 factor, if not for the fact that DigitalCD always sets to 0 bit 2 of PlayIt_Config,0 I would have suspected PlayIt’s strange way of taking into account the value of *volume. To be sure to eliminate PlayIt as the suspect you could always let DigitalCD play PCM wave files with te help of DiskSample.

I’ve just another test to check what I thought I was getting previously.

The following is with the “ignore system volume” ticked. I’m hoping what I describe may be diagnostic and help you and others spot the problem’s cause.

I used two files. One is a 300 Hz 0dBFS sinewave tone as an 88.2k LPCM wave file. The other is a flac version I generated from that using sox.

First I played the wave file with DCD and ensured that, yes, with the “ignore system volume” ticked, I could change the system volume whilst DCD wasn’t running, and changes to the *volume (which I checked had been enacted) did not change the output level.

However with DCD’s own volume level set at “100%” the output was grossly clipped.

I then tried the flac file. Same results as for wave. The system volume value was being ignored, but with the DCD volume at “100%” the output was clipped to the same extent as the wave file.

However IIUC playing the wave file I was using PlayIt, but when playing the flac I was using DiscSample. (If I am correct, PlayIt can’t play flac anyway.) Is this correct?

So with DCD I seem to need to have the system volume taken into account for the “100%” DCD volume setting to not clip the output.

I agree very much with what you say about the commands really should also return their existing set values if you omit the parameters. I keep wondering if other things are going on that are hard to check! But I must also say that I dislike having the feeling that all these “system gain controls” seem like “too many cooks spoil the broth”… or at least confuse the hell out of the poor user! :-/

I hope to do some more tests tomorrow, but I think the above shows you why I find some of the behaviour so odd.

TBH I have a feeling that some of the ‘flags’ or indicators used to set/bypass things may be misinterpreted by some other parts of the system. I keep having the feeling that some behaviours are being ‘inverted’.

If you can explain the above or say what I’m doing wrong, please let me know. Am I just doing something daft?

Jim

Just to confirm, I played a flac on my RPC, volume 100%.
DiskSample volume was set to 256 (100%) and there was no clipping.
I then increased the track’s relative volume in DigitalCD, causing
the DiskSample volume to go above 256 (it allows up to 1024).
The sound remains unchanged because DiskSample’s automatic gain control (AGC) feature kicks in.

DiskSample mixes in an internal buffer 32-bit buffer, and if the output goes beyound 100% the gain is adapted so that sound fits in the 16-bit buffers with no clipping. The AGC was originally designed for TimPlayer but I left it in for DiskSample to avoid nasty clipping when boosting the bass with the equalizer.

I would suggest to monitor monitor the output with DigitalCD’s TimPlayer visualisation plug-in. Even for files not played by TimPlayer
you will at least a display of the output of the SoundDMA buffers. If the wave is clipped that would suggest either an incompatibility of DiskSample with newer machines or a problem in subsequent manipulation of the buffer (mixing together the output of the 8-bit and 16-bit subssystems?). If there is no clipping, then it must be an incorrect gain of the output hardware.

Hi Andre,

I’ve been thinking about this overnight. I’m starting to suspect that the way the ARMiniX system applies the system and maybe ‘headphone’ gains might be why my results are inconsistent with other machines like the RPC. This thought was prompted by wondering about the details Jeffrey gave about these in his recent ‘wiki’ document.

I’ll do some tests later today and report the results.

BTW The fact that DiscSample auto-compresses does make me wary of using it. Is the behaviour documented somewhere? I general I find automated level compression a real PITA. It cripples the sound on many pop/rock CDs making them sound (and measure!) worse than old LP versions. Ditto for a lot of music on radio. So I’m wondering how benign or to-be-avoided the DiscSample process may be.

FWIW Up until the last few days I’ve only played LPCM wave files on my ARMiniX. Have only recently started experimenting with Flac, sox, etc, to compare with my Linux systems where flac is the file type I normally use.

Jim

I’ll do some tests later today and report the results.

<sigh> OK, I’ve now done the tests I had in mind. I had hoped this might crack the problem… but my immediate reaction is further bafflement!

As before I used DigitalCD to play a test file (0dBFS 300Hz sinewave 88k wave file. System rate 88.2k. DCD set to ‘ignore system volume’).

I was wondering if the headphone slider setting on the boot sound config was affecting the output level despite the ‘ignore system volume’ being chosen in DCD. If so, maybe it was actually boosting the signal. [ Again on the principle that theory == practice might return FALSE as seems the norm for reality. :-) ]

Two findings:

1) Yes, the ‘Headphone’ slider setting on the ARMiniX did scale the output level. If I move the slider and set a new value, the output changes amplitude.

however

2) It remains clipped to exactly the same extent.

So it looks like the ‘headphone’ gain setting is applied even when DCD is set to ‘ignore system volume’ BUT the ‘headphone’ scaling seems to be applied after the stage that is clipping the waveform.

Is it me, or is that crazy?

( OK I know an obvious answer is that the “or” could be “and” and might still be TRUE. 8-] )

I’m baffled. With the headphone slider at max (the default) the max unclipped output is about 1.04Vrms (i.e. about +/- 1.5V peak). But if you wind down the ‘headphone’ level this clipping level drops in proportion. Meaning this isn’t range clipping of the actual chip output. It is clipping being imposed at an earlier stage.

Which in turn strengthes a worry I’ve had. Maybe the clipping I see is always happening to limit the signal to less than the full 16bit range.

Weirdly, weirdly, Mr Cornelius…

Jim

So it looks like the ‘headphone’ gain setting is applied even when DCD is set to ‘ignore system volume’

That’s to be expected. The “headphone” and “system” (I think that’s what it’s called) sliders in Configure make settings via *MixVolume, and since that’s intended to be a general interface for mixing together N sound sources to produce M outputs, it’s unreasonable to assume that one sound source would be able to correctly ignore the gain controls on one particular path through the mixer. It would be like telling your CD player that you’ve got connected to a mixer to ignore a volume knob on one of the speakers.

bq. So it looks like the ‘headphone’ gain setting is applied even when DCD is set to ‘ignore system volume’

That’s to be expected. The “headphone” and “system” (I think that’s what it’s called) sliders in Configure make settings via *MixVolume, and since that’s intended to be a general interface for mixing together N sound sources to produce M outputs

However as things stand the ARMiniX only has one output.

If we had an available ‘line’ output that was seperate, I could see more point. Although this wasn’t the main thing I was pointing out as being crazy.

…it’s unreasonable to assume that one sound source would be able to correctly ignore the gain controls on one particular path through the mixer. It would be like telling your CD player that you’ve got connected to a mixer to ignore a volume knob on one of the speakers.

Talking about multiple sources is different from talking about multiple outputs.

However, the result is that when you play one source on a system with one output available we get a situation where the result clips even when we try to set all the gains offerred by the GUI on boot and playing app to as close to “100%” as seems possible according to what the user sees.

The headphone gain is being applied after the ‘system’ gain (or its bypass). This implies that the clipping is acting at an earlier stage than the ‘headphone’ part of the chain.

So we’re back to a situation where using the default settings for the ARMiniX, if we use DCD with ‘ignore system volume’ and set its shown gain to “100%” the result clips grossly when playing either 16bit LPCM wave (PlayIt) or flac (DiskSample).

The basic question is: what is causing the clipping and how do we fix it?

This matters particularly as (I assume) most users won’t be able to connect a scope to the output and establish that the output is clipped that way. And they probably won’t use any star commands or swis to fiddle with the settings. They’ll just use Boot and their player controls…. and get clipping unless they wind down the gain to well below “100%”.

Which to me implies that a stage (other than the system volume scaling, or PlayIt/DiscSample) along the way is scaling the values to overflow 16bit.

The real point of my checking the ‘headphone’ setting was as a diagnostic. I’m not surprised (or bothered) that it does change the gain. What is the (perhaps diagnostic) outcome is that it doesn’t remove the clipping when it reduces the size of the output. That tells us something more about where the problem is caused.

I had been wondering if the DAC was simply unable to output the full range for some reason. (e.g. wrong reference voltage/current for the conversion). Seen that in some other situations. But the ‘headphone’ behaviour implies that can’t be the problem. So I think we can eliminate that possibility. Not certain, though.

IIRC I actually got different behaviour with PlaySound+PlayIt. I’ll check that when I can. But today I’ve been mainly soldering some hardware and trying to fit it into a box.

Jim

This matters particularly as (I assume) most users won’t be able to connect a scope to the output and establish that the output is clipped that way.

BTW if someone wants to check this for themself but they don’t have a scope, etc. If you have a linux box with an analogue ‘line’ input you may be able to use the ROX_scope and ROX_mini_scope apps on my audiomisc site to turn your box into an audio scope/spectrum analyser. Not as good as the real thing, and you’d need to set it up and calibrate it, etc. But does work within its limits. I tend to use it along with ROX_tone and an external DAC as a sig gen for quick tests.

Jim

A slight tangent, but may be relevant…

I’m using a simple short ‘C’ prog I wrote to check the current settings inc. the *volume. IIRC I took the relevant details from the PRM, but wrote it a while ago. I’d like to check one point. Relevant few lines of the code below

Using this a *volume of ‘127’ gives me a ‘scale’ of about 250% – which seems to agree with the amount of clipping.

If I change the volume to more like ‘100’ to ‘103’ I just miss clipping when the system volume is taken into account and the reported scaling is below 100%.

Is this simply that my code is wrong, and an odd co-incidence? Or is it telling us that – despite what theory might tell is – the gain is well over 1.0 for some reason?

Asking because I’m not sure if this is just an odd co-incidence or somehow diagnoistic.

Jim

rin.r0=0; _kernel_swi(0×40180,&rin,&rout); printf(“Volume setting = %d\n”,rout.r0); v=((double)rout.r0)/16.0; v=pow(2.0,v); printf(“Nominal Volume scale = %6.3lf\n\n”,v);

As I said, the Textile parser is easily confused.

…oh, okay, it appears to work in a quote. There’s consistency for you!

Use:

[blank line]
<pre><code> ... your code ... </code></pre>
[blank line]

OK, textile, take this!

 
rin.r0=0;
 _kernel_swi(0×40180,&rin,&rout);
 printf(“Volume setting = %d\n”,rout.r0);
 v=((double)rout.r0)/16.0; v=pow(2.0,v);
 printf(“Nominal Volume scale = %6.3lf\n\n”,v);

Howzat?

Weird. I hope when SETI makes contact the aliens aren’t using their version of textile! We’ll be in deep trouble if they are… 8-]

Jim

Using this a *volume of ‘127’ gives me a ‘scale’ of about 250% – which seems to agree with the amount of clipping.

In that case, the PRM must be wrong, because that’s not what the OS source code says should happen!

bq. Using this a *volume of ‘127’ gives me a ‘scale’ of about 250% – which seems to agree with the amount of clipping.

In that case, the PRM must be wrong, because that’s not what the OS source code says should happen!

The problem in practice that is the scaling on the ARMiniX seems to agree with what I reported. i.e. gives a gain of about x2.5 if you have a *volume of 127. This is the key point I was trying to make.

It is fair enough to say that the ‘source code’ says that 127 (or bypass) will give x1.0. Alas, the behaviour is otherwise when measured. That’s what I’m reporting and hoping will be investigated and fixed!

Why the actual machine may not give x1.0 and gives more like x2.5 I have no idea. But that is what the measurements show. Nor do I have any idea at what stage along the ‘chain’ this extra factor may be being imposed. Although I think I can now rule out the ‘headphone’ control.

Afraid I can only report the behaviour, as I describe in the earlier postings. :-/

Am I the only person who has measured the actual output with a scope, etc?
Specifically for the ARminiX/PandaBoard which – given what Andre has reported – may behave differently to a RPC or other hardware.

Jim

I’ve skimmed through the copy of the PRMs that come with the tools CD and can’t find anything similar to the code you’ve listed. The most I can find is “A change of 16 in the
volume will halve or double the volume.” in the Sound_Volume and *Volume docs, and the following assembler snippet in the discussion about applying the channel volume to 8-bit data when writing your own voice generator (Ra = channel volume, Rs = sample):

; do this each time Voice Generator is entered
RSB Ra,Ra,#127 ; make attenuation factor
; do this inside loop, before each write to buffer
SUBS Rs,Rs,Ra,LSL #1 ; note shift to convert to VIDC format
MOVMI Rs,#0 ; correct for underflow

Although I guess it’s also worth pointing out that I don’t think the PRMs explicitly state that a volume of 127 is a gain of 0dB! You just have to work that out for yourself by looking at the above code snippet (where 127 would result in Rs being left unmodified)

A couple of questions:-

Are all the stand alone Sound Modules all 8bit – like used in !Rhapsody4?

If they can be 16bit – is there any flag in the module providing this info.

Can the ROOL ‘C’ compiler be made to generate code that uses the Hardware FP- ie by setting a flag. (for the Beagle/Panda/Pi)

Although I guess it’s also worth pointing out that I don’t think the PRMs explicitly state that a volume of 127 is a gain of 0dB! You just have to work that out for yourself by looking at the above code snippet (where 127 would result in Rs being left unmodified)

I think that may example the kinds of problems I have kept running into. The PRMs, etc leave a lot ‘unsaid’ and you have to be able to find, read, and understand some assembler to understand what actually happens. Given my lack of skills with ARM assembler, etc, it isn’t practical for me to do that, so I have to ask here for help. What I can do is measure the behaviour and then try by some kind of test process elminate stages that seem to be ‘before’ or ‘after’ whatever may be causing a measured effect.

The code snippet I put up is what I wrote to read the value for the scaling, based only on what I could find in the PRMs, etc. I raised it here because I could not tell if it was simply a co-incidence that it shows 127 as about a 250% boost – which seems in the same ballpark as the amount of clipping I get.

To summarise what I think may be the case at present.

1) I think we can assume that the clipping is occuring ‘after’ the stage which either applies the *volume gain or bypasses it. This assumption is based on various points that have been made. In particular, if I opt to bypass the setting I still get the clipping, but I can use a volume setting of around 100 to prevent clipping.

2) I think we can assume the clipping is occuring ‘before’ the headphone gain value is being applied. This is because the headphone value scales the size of the output preserving the amount of clipping. i.e. it is scaling a waveform (series of values) that have already been clipped.

I hope those assumptions now make sense.Given that they do…

I don’t know at what stage, or by what module the headphone scaling is done. Is it by the ‘SoundControl’ module? That isn’t on the ascii art diagram you drew. Where would it fit into the flowchart for 16bit?

I’d also welcome info on the following points to try and make sense of this area:

You say the ARMiniX main system slider has a range from -18dB to +24dB. Where does this kind of info come from? I don’t see any sign of being able to get gains anything like +24dB, but I’ve not yet checked this in any detail. And where are the ‘default’ values store, and how are they accessed? I don’t know what lies ‘behind’ the !Boot sound sliders…

I get the impression that this problem is ARMiniX/PandaBoard specific, so I’m trying to narrow down the areas in which it may reside.

I’ll look at the SoundControl doc you mentioned in your wiki/file on this, and see if that helps. But any further info you can give would be welcome. I’m afraid I’m not able to read assembler and understand it well enough to hunt for bugs like this. I might just understand the bug once someone more knowledgeable than myself pointed it out to me with a big pointer, but of course that isn’t much use… :-/

Jim

It also makes the sampling and reconstruction filtering easier to do whilst avoiding effects like filter pre-ringing.

Pre-ringing is simply a consequence of linear phase filters, which, in general, we hold to be good things. If the phase response is linear, the pre-ringing will be an exact mirror of the post-ringing.

What is your objection to pre-ringing?

What is your objection to pre-ringing?

Personally, I don’t have any particular objection to it. In general I’m quite happy with sinc-like time-symmetric impulse behaviour. Indeed, I suspect this is a boojum. But many audiophiles like to be able to choose other kinds of reconstruction. You can find plausible arguments for what they say. e.g. I did a set of articles for HFN some years ago, and the contents are at

http://www.audiomisc.co.uk/HFN/hearing/index.html

but I’m agnostic over if it actually matters.

That said: I did in the past have a habit of preferring to have an analogue low-pass filter after the DAC of my first CD player. However I think this was more a case of preferring the slight tonal change it produced, not the reduction of pre-ringing. Not felt any such need since I switched to Meridian DACs and now Cambridge Audio ones…

Jim

Slight update.

I’ll look at the SoundControl doc you mentioned in your wiki/file on this, and see if that helps.

I’ve now found the doc that simply lists the API for the SoundControl 1.03 SWIs. That at least gives me something to probe with. I assume the values Jeffrey gave for the ARMiniX come from using SoundControl_ExamineMixer.

But the values he gave don’t currently seem to me to match what I’ve been getting. May know more after some tests.

I don’t really know my way around CVS, so didn’t find the assembler for the module. Probably wouldn’t understand it if I did! :-/

Jim

didn’t find the assembler for the module

There doesn’t seem to be any under castle/RiscOS/Sources/Audio/SoundCtrl/.

One additional item of diagnostic evidence from a test I did this morning.

By default I now normally have the *volume value set to ‘100’ at bootup. This ensures that provided I use players like PlaySound and DigitalCD with them taking system volume into account then I won’t get clipping even with waveforms that reach 0dBFS (i.e. have samples values that cover the entire 16bit range).

This morning I tried setting the *volume to ‘127’ (which is the normal default) and proceeded as follows:

First I checked using PlaySound+PlayIt that a 0dBFS test file did now clip grossly. Yup.

I then played a series of test files with various waveform amplitiudes.

-10dBFS showed no sign of clipping.
-9dBFS showed obvious but slight clipping.
-9.5dBFS was – if anything – very slightly clipped. Hard to decide, but the distortion level was up from using a -10dBFS waveform.

So it looks like the degree of overscaling caused by either having a system volume of 127 or bypassing system volume is about 9.5dB. That corresponds to an amplitude factor of about x 2.98.

It seems that you need to have the *volume setting to scale down the samples by about a factor of x 0.335 to avoid whatever is doing the clipping. I’d been using about ‘100’ which – according to the values I get back from the swi I outlined before – means a scaledown of about 0.31 compared with ‘127’. That agrees with my finding earlier that you can set a *volume of about ‘102’ and just avoid clipping. But I find ‘100’ easier to remember and recommend to others as a round value. So far as I can tell, none of these values give unity gain or actually avoid the problem in the sense of not having the unwanted scaling performed.

No idea what significance the precise value may have. Hope someone can make sense of it in terms of diagnosing the cause of the clipping!

Jim

Jim – could you create a series of tests – to help determine – where the change happens?
ie:- to be able to run them on the various hardware options RPC/Iyonix/Beagle etc.

How are you determining the clipping – Ears – or something like !DigitalCD monitor option – external scope?

Is there a document somewhere that explains how the Boot sound config works? i.e. where does it get its ‘default’ values and how does it update values when you move a slider and tell it to accept the new settings? Are there some files inside !Boot somewhere, or a prog that interfaces with the relevant modules, etc?

Oh, and it suddenly strikes me that a gain of x3 could occur if something is unintentionally multiplying the sample values by (binary)‘11’ – e.g. by adding a double or shifted value to the input. So I’m wondering if there is an ‘oops’ somewhere that is doing something like that in between the ‘system volume’ and ‘headphone’ gain stages in the chain on the ARMiniX/PandaBoard.

I can’t check for myself as I don’t have the source for SoundControl. And almost certainly wouldn’t be able to understand that or the source for SharedSound anyway if I did!

Jim

Look at the G.711 tables for mu-law. 127 corresponds to a decision value of 8159; 100 to a decision value of 2527. The ratio of those numbers is 0.308 or 3.24 depending which way up.