audio puzzles, etc

Hi Rick,

Yes, I’d agree that many commercial ‘high end’ audio items are insanely expensive. Also that even modest costs can be a bar for many who have a budget they have to devote to other things. However there are cheaper ways. Indeed, for me one of the points of better audio from PandaBoard/RPi/etc is to provide an alternative that would be cheaper than many commercial offerrings. But in the end, people have to decide what they want and how much they can devote to it.

FWIW One of the things I’ve been working on is a cheap DIY circuit which makes the ARminiX a better source for headphone listening as well as for connecting to the line input of a hifi setup. Works OK, based on a kit from CPC that costs less than ten quid. I’ll be publishing the circuits, etc, in due course. It also kills the aliasing for x2 and the delta-sigma hash if you wish. I suspect more people can risk ten quid for better headphone sound than can spend loads on superb speakers. :-)

Jim

Hi Jeffrey,

I want to write a detailed response to what you wrote (which I largely accept) but my problems with formatting quotes make this hard. I’ll save the entire text of what you posted and write a reply using an editor. Then seen if I can post the result here, hoping the format will make it more readable.

Jim

Hi Jeffrey,

For me at present the simplest method is to put quotes in, erm, quote marks. Apologies if the result is a mess! But I don’t seem to know how to do the quoting you and others do with NetSurf.I can’t select sections with the mouse that I want to copy. :-/

“It’s my understanding that *volume should only affect 8-bit material. But it’s possible that I’ve missed something when checking the code. Or maybe some music players/sound generators aren’t following the rules properly and are using the wrong volume controls for things.”

Yes, that’s what I’d thought. However I find that with both PlaySound and DigitalCD the *volume can scale the output, depending on the settings. You have to tick ‘scaled volume’ or not. Which can easily confuse or be missed by users. The result with the default *volume value of 127 is gross clipping as that scales up to about x2.5 the size and the waveforms go over the 16-bit range. Similar problem for DigitalCD. So far as I can see, you need to be able to check the output with a scope and meter to test diagnose this. Otherwise the user may simply assume the distortion is ‘normal’.

It seems weird in a 16/24 bit world that there also seems to be no value of *volume that gives a scaling of unity! Back when the only interest was beeps and bangs, fine. But nowdays that seems really odd, and implies if you aren’t really careful you willl have unwanted scalings.

It also makes me wonder how the volume is being scaled, and if that reduces the accuracy if it being run though some kind of ‘8-bit process’ on the way…

I also suspect that the way mixing/blocking is not being handled and reported consistently between the various apps/drivers/etc. Get things like system beeps when I thought I’d specified no mixing.

“I suspect the easiest way of getting to the bottom of problems like this would be to add some debugging features to the OS to allow the output of the various sound systems to be captured. E.g. capture the raw 8-bit sound data, capture the output of each SharedSound client, capture the final data that SoundDMA sends to the hardware, capture all the different volume level settings, etc. Then it will be easy to see if each component is applying volume settings correctly and where any clipping is being performed.”

That may be so. As things stand I can report what I find, and from that may be able to suggest a diagnostic process. But I am unlikely to be able to do any of the programming for the above. What I can do is make tests and provide results that may show symptoms and performance.

[ There is more to it, but I’m having to type this into a tiny window that makes it hard for me to explain. But the basic question is: What settings will ensure (either taking *volume into account or bypassing it) that full level 16-bit values in an LPCMsource get those values to the DACand give full range output with no scaling factors? ]

“At the moment I’d say the only way to ensure that’s the case is to:

1. Stop or kill any 8-bit sound generators
2. Kill SharedSound
3. Use Sound_LinearHandler to install your own 16-bit handler to replace the one SharedSound installed
4. Use *MixVolume to set all the mixers to 0dB"

I can expriment with some of that, although I have no real idea about how to do (3).

“The first three steps should ensure that the sound data you generate in your linear handler doesn’t get modified by the OS (although, the first two are technically unnecessary since your handler could just overwrite any 8-bit sounds if it wanted, and installing your handler in step three would remove the handler SharedSound had installed). The fourth step should ensure the hardware isn’t applying any amplification/attenuation to the sound (and if it is, then it’s probably a bug in the HALwhich should be fixed).”

For me, I think step 1 is to be able to define what allows the user to bypass having *volume affect the audio. The next step seems to me to be better interpolation than linear. Is that a handler issue? I can explain/define the kind of process involved, but have no idea how to program it into a driver!

“As far as any future major update to the RISCOS sound system goes, I expect we’d want to aim for a system which supports the following:

• Support for >16bit data (i.e. 24bit). I suspect most/all 24bit audio hardware will actually except 24bit data in a 32bit container, so making RISCOS internally generate everything in 32bit would probably be the easiest solution to keep everything word/register sized.
• Support for surround sound output
• Better, more flexible sample rate conversion. E.g. the 8-bit sound system could be left running a a VIDC-compatible sample rate and then resampled to 44.1kHz/48kHz/96kHz/etc. for mixing with 16/24bit sounds. Make sure the sample rate conversion routines can be used by any sound generators so people aren’t tempted to write their own simple linear interpolators.
• An official APIfor audio input
• Support for multiple audio input/output devices being active at once (e.g. on-board audio plus USBaudio)

That should put us on part with most other modern OS’s. But it is a pretty big job, and will need someone like Jim to verify that everything is working as intended :) (At the moment the best I can offer is to pipe the output into my PC and record it through that. Not very high tech!)"

Agreed. My feeling on most of that at present is to see if we can define or lay out an extended API, etc, so that people can agree and co-ordinate what then may take place.

That said, it would be nice if we could find a way to, relatively soon, get a driver to be able to pass 96k/24 to the HAL/hardware fairly directly. For that no interpolations would be required. Just pass the parcel. It would immediately make RO + PandaBoard/similar competitive for those who want to play 96k/24 ’high resolution’ material – which is becoming the common standard already for many serious audio users. Make it far easier to attract new users! At present I can play 96k, but it has to be 16bit and I’m far from sure that the values aren’t being twiddled about on the way.

Apologies again if the formatting of this comes out as a shambles. Sorry, just don’t yet know how to copy material into the reply letterbox.

Cheers,

Jim

Hi Jeffrey,

Just an apology/footnote to the previous posting. Afraid in some places it goes ‘non sequiter’ (spelling!) as I was too busy trying to second-guess how the result would end up being formatted! :-/

Jim

Jim: You can edit your posts at any time. There should be an ‘Edit post’ link under your name.

As for quotes, just use ‘bq. ’ before the copied section (without the quotes). So, to quote the text ’Quote’, you’d enter:

bq. Quote

As someone else pointed out, there is a ‘Test’ section in the forum for trying stuff out, if you’re unsure.

BTW if anyone is curious about the cheap headphone circuit, have a look at

http://www.audiomisc.co.uk/HFN/HeadDAC2/HeadDAC2.html

where I used the same cheap kit. You get the PCB and most of the components. In fact the main modification is to not bother to use all of the supplied components. At present for the ARMiniX I’m just adding a low-pass filter to kill above 23kHz when playing 44.1k material. But this filter will become largely redundant if we can fix the aliasing problem so 44.1/48k playing works correctly. Better circuits are available, but may cost more. 8-]

Cheers,

Jim

Hi Chris,

The difficulty I have is that the “edit posts” lets me alter my own postings. But I can’t find any way of selecting a chunk of someone else’s postings to drop it into the letter box. I can add the quote header, but have trouble inserting the blocks of text I want to quote! :-/

I’ll look at the “tests” part of the forum to see if that shows me what I’m not understanding.

Thanks,

Jim

The difficulty I have is that the “edit posts” lets me alter my own postings. But I can’t find any way of selecting a chunk of someone else’s postings to drop it into the letter box. I can add the quote header, but have trouble inserting the blocks of text I want to quote! :-/

So you can’t select an area of text in netsurf, press control C, click in the reply box, press control V. Then where you would put quotation marks put < blockquote> at one end and < /blockquote> at the other?

You’ve been spoilt expecting it to be all done for you by the email client :-)

Note < blockquote> and < /blockquote> is what you actually type except for the space after the < its not a formatting error

ps I did exactly as I described in netsurf 3.0 for this post.

It occurs to me…

This doesn’t directly follow on from what we’ve been discussing. However it is in some ways a precursor and part of the experiences that lead me to raise the issues. It may also be siginficant info for those using PandaBoards.

When I first started testing my ARMiniX I discovered that when I played 44.1k files (as you would get from a CD or mp3) the result was MONO, not stereo. The tests showed this was accompanied by a LOT of ultrasonic hash around 44.1k.

Now you probably won’t hear this ultrasonic hash, but I would not be happy feeding it to a decent amp and speakers. Could cause problems. And I do wonder what effect it might have on someone younger than my ancient self who used headphones that actually were able to output so much ultrasonic signal.

The solution at present is to ensure you set the system sample rate to 88.2k when playing 44.1k material and enable interpolation. You then get stereo and most of the hash vanishes. (but not all.)

I can explain in detail why this is happening if someone wishes. But in brief it it because at present the OS+HAL+etc doesn’t deliver 44.1k as 44.1k. It converts it by a method that causes this behaviour. Even if you are happy with mono sound, I would advise avoiding letting this happen. I hope this problem will be fixed and 44.1k system rate can then work. This is because I suspect the TI chip actually can do its own – high quality – resampling anyway. I may be wrong about that, though. I can’t test it until the 44.1k system rate behaves more sensibly.

But in the absence of that we come back to the wish for improved interpolation, etc. So that is what led me into this area.

And although I can’t do much in the way of programming, I can – and will be happy to – perform tests on the performance. Can then report the results and see if any symptoms help diagnose any remaining problems.

That said, if you have a PandaBoard or similar then some progs I have put into a zip at http://jcgl.orpheusweb.co.uk/temp/PandaAudio.zip
may be of interest. Please note I have only tried them on my ARMiniX, though, and they may not work or give odd results on other hardware, etc.
Cheers,

Jim

Hi Chris,

Yes, I can’t use the mouse to select an area of text from any of the previous postings I can see which others have made. Not being able to select anything I guess it is logical that ctrl V/C then do nothing as their is no selected set of text.

Is this NetSurf, or me?

When I get a chance (probably tomorrow) I’ll try FF

Jim

Using NetSurf 3.1.

Select first line of Jim’s text by dragging with Select. Press CTRL C. Click in reply box. Type bq.[space]CTRL V.

Yes, I can’t use the mouse to select an area of text from any of the previous postings I can see which others have made.

Insert a blank line (required). Reply, “It seems to work here!”

[edit post] The same method works for using an external editor except if it’s Zap then CTRL Y instead of CTRL V.

Ah! A possible penny drops. Just checked and – despite my using an ARMiniX I only bought recently the version of NetSurf says it is V2.9 (27th Feb 2012). Maybe the problem is because it is too old. I’ll try a newer version.

I’m a bit surprised/puzzled by the above as I’d though it would be newer than that! However…

Cheers,

Jim

Now have NetSurf 3.0

A possible penny drops.

ta-daa! Yes, I can now copy and past with ctrl V/C

But then when I try typing the text becomes invisible untile I press

return at the end of the line! So now I can copy and paste,
but keep losing the ability to se what I’m typing.
Oh bother. :-/

Anyone know what’s wrong now?

Jim

decided to use ’edit post but my typiing remains invisible until
I press return at gheend of ach line. So things are now worse
than befoire! :-??

Just experimented on the test subgroup. Looks like the text shows if I keep to 100% scale. But if I go to 140% scaling of the NetSurf window the text keeps becoming invisible on the line I’m typing!

This is a pest because 100% scale is so small I find it hard to read.

Is 120% ok? seems so.
But 130% percent vanished so I’ve gone back to 120%
to see if that seems Ok for some time.

Anyone recognise this problem? It seems like the line isn’t being redrawn
as I type if I scale up to more than about 120%. Which is still a bit
hard for me to see as it is so small.

Jim

More expriments make me think that the problem is that NetSurf seems to decide I’m typing ‘outside the letterbox’ and doesn’t bother to redraw the line as it is typed. This seems to happen above some magic font size/settings. I can only use 100% scaling and see what I type if I make the minimum/default font sizes for netsurf bigger than default. Reduce the defaults and I can scale up to a limited extent, but there seems
to be an absolute limit to the on-screen size I can see.

Didn’t have this problem with the previous version, so I assume it is a NetSurf bug. Can anyone comment please?

I’ll leave it there. I can just about read what I’m typing. :-//

Jim

But if I go to 140% scaling of the NetSurf window the text keeps becoming invisible on the line I’m typing!

Just tried 140%. Ugh! That’s ugly but it’s worki
or maybe not. Netsurf

[edit] Had to switch to the Mac to complete. Looks like a NetSurf bug.

With ref to Sound converters – like Playit – it would be handy to remove the 26bit code – and have some more docs explaining how things worked.

So more converters could perhaps be written.

In !MP3Radio which now runs in 32bit mode – there is a option to use ‘DMPA’ (26bit) convertor instead of the AMPlayer convertor.

‘DMPA’ ‘C’ Code runs in taskwindow – so if Jim wanted to write a converter in ‘C’ in app space – this might be a option.

For some unserstanding of digital audio/video, there are some very interesting introduction stuff made by Monty one of the main contributor to Vorbis, Theora and other codecs. Look at http://xiphmont.livejournal.com/

Another interesting article there is “Why 24-bit/192kHz music downloads make no sense”. To sum up:
- more than 44.1/48kHz is useless as it cannot be heard. Most speakers cannot render the extra hig frequencies anyway and if they don’t filter the signal there is even a chance of them generating interferences in the lower spectrum.
- 16-bit is enough for listening but more is interesting for studios. They don’t have to be to strict with the recording levels, and post recording manipulations (filters, …) can be made without the precision loss making it in the audible range. For listening it can also be usefull for avoiding precision loss when listening at low volumes.

The *Volume command:

This command is an 8-bit stuff that was designed to control the global volume of the machine. It updates a volume table which is used to translate each 8-bit sample playing through the voice handlers.

Of course most sound modules bypassed these this by taking direct control of the SoundDMA handler and the global volume control effect was lost. And thus when 16-bit sound was introduced it no effort was made to support it either.

This was a pity, because at some point I had speakers which amplified a bit to much and I had either to reduce the speakers volume so much that its behaviour was non-linear or I had to reduce volume to +- 10% on the RISC OS side which was not always possible (games and demos). That is why, when designing DigitalCD, I made it take the *Volume setting into account so that the “global volume” behaviour was restored.

Regarding PlayIt, DigitalCD always sets bit 2 of PlayIt_Config,0 to 0, because otherwise it takes the *Volume setting into account but into a weird way which I have never managed to understand.

Thanks for your input.

Would it be feasible for the *VOLUME command to updated to take into account the 16bit (24bit) sound output?

Pity *VOLUME command doen’t give the set value.

Have you worked out the ‘chain of command’ of the sound path from File to the hitting of the hardware?

Hi,

Colin:

you’d need to explain

In !MP3Radio which now runs in 32bit mode – there is a option to use ‘DMPA’ (26bit) convertor instead of the AMPlayer convertor.‘DMPA’ ‘C’ Code runs in taskwindow – so if Jim wanted to write a converter in ‘C’ in app space – this might be a option.

before I could comment. Afraid I have no contact with mp3 players, etc.

Jim

Hi Andre,

Another interesting article there is “Why 24-bit/192kHz music downloads make no sense”. To sum up:- more than 44.1/48kHz is useless as it cannot be heard. Most speakers cannot render the extra hig frequencies anyway and if they don’t filter the signal there is even a chance of them generating interferences in the lower spectrum.- 16-bit is enough for listening…

Alas, it isn’t that simple for various reasons of which:

but more is interesting for studios. They don’t have to be to strict with the recording levels, and post recording manipulations (filters, …) can be made without the precision loss making it in the audible range. For listening it can also be usefull for avoiding precision loss when listening at low volumes.

is just a part.

The reasons why 88.2/96k source can sometimes sound better depend on a number of factors that in practice can return either true or false.

As soon as you start to apply processes to the data it helps to have a wider range of values. That includes both things like digital volume or mixing in a player and the processes a DAC or rate convertor employ. That on the face of it seems like an argument for 24bit, not 16bit, but things aren’t that simple.

The point of 88.2/96k material isn’t to allow your pet bat or dog to enjoy the details above 20kHz. :-)

It is more likely to be to let the DAC and other processes function more effectively to reduce any unwanted artifacts in the audible part of the spectrum. The high information bandwidth matters.

e.g. Are people familiar with noise-shaping? This lets you shift the quantisation ‘noise’ away from being ‘white’ (uniform power spectral density) and shove it up to frequencies we can’t hear. The result is higher resolution for components in the audible range. The best known example of this is DSD (SACD) but ADCs and DACs do it all the time. In fact if you look at the measurements I put up of the ARminiX output you can see an example, there used for upsampling as part of the delta-sigma process. It gives the ‘hill’ of noise up above about 50kHz.

So 96k/88.2k source material allows for a wider dynamic range in the audible region. It also makes the sampling and reconstruction filtering easier to do whilst avoiding effects like filter pre-ringing.

Lot more to it which I guess most people don’t know. But it can matter. And a big part of this is the old engineering maxim:

“In theory, theory and practice agree. In practice, they don’t” :-)

In this case Info Theory tells us that about 48k/20bit is essentially ‘perfect’ for home audio replay in almost all cases. But that hinges on every part in the chain behaving ‘perfectly’. However measurements routinely show they don’t.

So just as pros use 192k/24 or even 32 or floating point for recording to give them ‘elbow room’, so there can be advantages for the end user in using 96k/24 and a system that can handle it. But the devil is in the detail, and depend on the case. (Plus other assorted familiar phrases. :-) )

WRT *Volume the practical vs theory maxim also crops up. For the user, when you use a decent playing app like PlaySound or DigitalCD you may actually be allowing *volume to rescale even when playing 16bit material. And since the default *volume value (127) scales up by about x 2.5. the result can often be clipping distortion. You can fix this is you know what settings to check/make. but if you don’t it may be happening. The result may then sound worse than it should and you may not know why.

And if you wind down the volume with the control the player provides you may be losing dynamic range on the way because 16bit values are giving up using the top bits and dropping the LSB info before being scaled up again by *volume along the chain.

To me the ideal solution is: Ensure volume is *out of the path! So far as I can see it never should have been in the 16bit path anyway, so I’ve no idea why it is present. Maybe it is an accident, or a decision to ‘match’ the levels with some 8bit material. Whatever, to me it seems an anomaly to be excised from 16bit.

BTW I’ve mentioned to Andre seperately that on my ARMiniX if I set the volume to “100%” (with *volume out of the path), save settings, quit, and restart DigitalCD, it shows up as having gone to “99%” and the output is slightly lower in level. I think he doesn’t encounter this. So I’d be curious to know if anyone else gets the behaviour as I’m puzzled by why it happens here.

That’s enough typing though a letterbox for now! :-)

Slainte,

Jim

Sorry format muddle! One phrase should have said

To me the ideal solution is: Ensure *volume is OUT of the path!

i.e. when using PlaySound or DigitalCD find the settings that mean that when you alter the *volume value it has no effect on the actual loudness of what you hear.

Dump it. Don’t fix it.

If you wish to change the volume, given the 16bit limit at present an after-the-DAC volume control would be best. But using the volume control provided by DigitalCD or PlaySound and bypassing *volume works OK and means you are in control and avoiding a pitfall.

Jim

Jim

I do have access to TI’s Code Composer Studio, but that’s no use unless we can find out how to get code into the DSP and data and out of it.

Is TI’s Programming Guide for DSP/BIOS Bridge of any help, or is that too specific to the Linux implementation?

“Why 24-bit/192kHz music downloads make no sense”.

Alas, it isn’t that simple …

Some of the arguments presented by that author can probably be accepted by some audiophiles.¹

If there’s a real possibility of the introduction of ultrasonic intermodulation distortion, then do other OSes/implementations include an option for users to control whether or not they want ultrasonics to be reproduced?

¹ I guess I’m probably a poor (in terms of wealth) former audiophile. I was a regular reader of a couple of hi-fi magazines myself many years ago, and was healthily sceptical of the more outlandish points of view back then. Nowadays, I still appreciate audiophile advice, but my general level of scepticism has increased rather than decreased.

Jim – Ref DMPA – it is a FF8 prog written in ‘C’- like your other programs.

By running in TaskWindow as a non Wimp prog – it is relative simple to write – and runs in the background.