audio puzzles, etc

Hi,

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 assume you mean ultrasonics generated as ‘distortion’ or ‘aliasing’ byproducts. If so…

Yes, ALSA (Linux) allows the user to alter how oversampling/resampling is carried out. However I suspect most people just use the default which tends to be pretty good at avoiding problems if the high-quality method is used.
FWIW I think it uses the same ‘Secret Rabbit Code’ used by sox. I’ve tested sox on this and was very impressed. Good work!

In brief; In Linux if you use the ALSA ‘hw:’ then the source material goes to the hardware with no resampling, and it will either be played or rejected If you use ‘plughw:’ it goes though a resampling mixer which will resample any input that comes in at a rate, etc, the hardware can’t natively handle.

How much this matters depends entirely on the circumstances, etc.

Above said, many current Linux distros also use PulseAudio which takes for granted that everything in sight has to be resampled and messed about. I avoid that personally as I find it a PITA. YMMV. :-)

No idea what windows/macs do. Don’t use them, so never checked.

FWIW I’m also very sceptical of a lot of what appears in audio magazines. I’m also a long-standing member of the IEEE and AES and take a more injuneering approach to these things than many. 8-] N.B. I don’t ever write ‘reviews’ of audio kit. Most of what I use is old, and tweaked by me. That said, there are some superb bits of new kit about. I wish RO was able to use some of them like the new asynch/isochronous USB DACs. Both by measurement and listening, these can work superbly well and can provide great results – when fed decent material.

Jim

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.

OK, URL? I’ll have a look when I can.

But FWIW when I want to resample material in ‘userland’ I just use sox. I’ve recently been experimenting with the RO port. Seems OK, but teeth-grindingly sloooow even on ARMiniX. I guess that is the ‘no fp hardware’ effect. :-/

If someone wants to compare playing the same ‘source’ material at different sample rates with good interpolation, I’d suggest the easiest first port of call is to use sox to generate versions at other rates.

i.e. If you start with a 44.1k (CD) file and use sox to create an 88.2k version, when you play that on an ARminiX/Pandaboard using an 88.2k system rate you won’t get the ultrasonic aliases you get when letting the RO interpolate playing the 44.1k file to a system rate of 88.2k.

Note though that the result depends on circumstances. e.g. some amplifiers (and tweeters) may respond nonlinearly to ultrasonic garbage. So this isn’t just a matter of ‘can a human hear such high frequencies’. It may be ‘do they alter how some kit behaves in some other audible manner’?

Cheers,

Jim

There’s an explanation of the OMAP4 audio HAL interface in the source code here.

More detail is available in the OMAP4 TRM
. The section on the McPDM starts at page 4985.

A non RISC OS sepecific summary can be found here.

All these should hopefully lead to the conclusion that the PandaBoard ES only supports 88.2 kHz and 96 kHz sample rates.

With Linux running on the “Raspbury Pi” is it able to understand “Real Audio” input?

ie: If so – is there a decoder that could be made to run on RISC OS?

But FWIW when I want to resample material in ‘userland’ I just use sox. I’ve recently been experimenting with the RO port. Seems OK, but teeth-grindingly sloooow even on ARMiniX. I guess that is the ‘no fp hardware’ effect. :-/

Sox has dithering turned on by default which is the fp intensive part. Use ‘sox -D’ to turn it off.

You can also play files in real time using sox on RISC OS. Just copy the ‘sox’ command to ‘play’ in the !Sox folder. Then add something like ‘Set Alias$play Wimpslot -min 16653k |M Run <Sox$Dir>.play -D %%*0 rate -v 88200’ to the !Sox !Boot file.

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.

Every other OS on the planet has a system-wide volume setting. I don’t see why RISC OS should be encumbered by its absence.

My vote is to fix it so it works, without distortion at the “100%” (and there’s no sense in it going beyond 100%).

For resampling, I understand that “Shibatch” aka SSRC is a good choice. There is a port on Stefan Bellon’s homepage: http://www.sbellon.de/sw-ports.html. Not ARMv7 I guess…

I assume you mean ultrasonics generated as ‘distortion’ or ‘aliasing’ byproducts.

Apologies, I’m well out of my depth – the water must be at least a foot deep here now ;-)

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

There is a doc I put together for Jim which shows how the different volume controls in each part of the sound system work (or, how they’re meant to work, assuming sound generators follow the rules properly). I’ll put it up on the wiki when I get home tonight.

One of the problems with 16bit sound handlers paying attention to *Volume is that *Volume is actually an encoded value which is subtracted directly from 8-bit audio samples. This means that (unless I’m mistaken) there’s actually no way to correctly convert it to a simple scalar which can be used with linear sample data.

All these should hopefully lead to the conclusion that the PandaBoard ES only supports 88.2 kHz and 96 kHz sample rates.

I certainly would not “hope” for that!. The point being that I’d expect a decent DAC chip like the IT one to actually do a good job of resampling without leaving it as a problem for the host OS, etc.

I have had a read in recent months of the relevant docs for the OMAP, etc. And I can’t be sure, but I continue to think the hardware can handle 44.1k and 48k. The output looks to me also like its is doing what I take from the TI documents. i.e. that it upsamples using delta-sigma. Given which I can’t see why TI would choose to exclude the most common rates for source material.

Slainte,

Jim

Sox has dithering turned on by default which is the fp intensive part. Use ‘sox -D’ to turn it off.

I may test that purely out of curiosity. But to me not dithering when resampling cripples the result. So not something I’d bother to use.

I did wonder about the play command. The help didn’t list it. But it didn’t list r, either, which seemed to work! :)

Jim

Every other OS on the planet has a system-wide volume setting. I don’t see why RISC OS should be encumbered by its absence.

Erm… if you note what Jeffrey said (and other docs indicate) the *volume value is not supposed to affect ‘well written’ 16bit. Your player has a volume control.

The problems with *volume are as Jeffrey and I have pointed out. It works oddly on 16bit can tends to cause problems. We presumably need it for ‘legacy’ reasons. But decent 16-bit players should bypass it by default. If you are using it, it is likely to be degrading the results.

Jim

BTW I’ve just generated this in response to a query. May be of some interest to some.

http://jcgl.orpheusweb.co.uk/temp/interpolate/over.html

Written on the “We don’t want it good, we want it now!” principle so not as neat and tidy and considered as I’d like. But hope it may be of use to some who are puzzled by the basics of resampling. There’s more on my old St Andrews Uni website for those who want details and loads of ‘hard sums’. 8-]

jim

bq. Every other OS on the planet has a system-wide volume setting. I don’t see why RISC OS should be encumbered by its absence.

Erm… if you note what Jeffrey said (and other docs indicate) the *volume value is not supposed to affect ‘well written’ 16bit. Your player has a volume control

Perhaps worth adding a reminder that we now have *MixVolume.

That AIUI it intended for 16bit so is designed for the task, and should be more flexible as well if someone wants a ‘system level’ control over replay gains. Whereas the old *volume value was intended for 8bit and may behave badly.

That said, I’ve not yet experimented at all with *MixVolume as I seem to have other matters on my ‘to do’ list! :-)

At some point I’ll get to finish and publish the details of the output filter and volume control I’m sorting out. That may work rather better than *volume as things stand.

Jim

*MixVolume covers all sounds produced by the system, since it operates on the final 16bit data stream that SoundDMA sends to the hardware (remember that 8bit audio gets converted to 16bit by the OS).

One problem with *MixVolume is that it’s entirely dependent on the capabilities of the hardware, unlike the software volume controls. And on some machines (e.g. RiscPC) it’s not available altogether.

Please excuse me if this sounds like a rant.

I do not care if one thing is for eight bit and one for sixteen bit. I just want a command to perform the obvious function.

*Help Volume
*Volume sets the audio channel loudness; range 1-127.
Syntax: *Volume <n>
*Help MixVolume
*MixVolume sets the contribution of an audio source to an audio mixer,
or the contribution of an audio mixer to a sound output channel.
Syntax: *MixVolume <mixer> <category> <index> <mute> [<gain>]

WTF? “Contribution”? That’s like the most politically correct description of a *command I have ever seen. Category? Index? Dammit, that stuff is complicated. I just wanna turn the volume down (or up) !!!!!

Furthermore, what if I don’t want to set the contribution of anything, but the global volume? You know, like in Windows where the Line In is such and such, the CD audio is this and that, the WAV audio is blahblah and on the system tray is this speaker control thingy that can adjust (or mute) everything. Do we have this? If we do, why is it not *Volume, what I might be tempted to call the obvious choice.

You know, like in Windows where the Line In is such and such, the CD audio is this and that, the WAV audio is blahblah and on the system tray is this speaker control thingy that can adjust (or mute) everything. Do we have this?

Sorry, I not understand all of this thread but for me it looks like you should use !Mixer or you take your question to the programmer of it ;-)

Doc now on the wiki:

https://www.riscosopen.org/wiki/documentation/show/Sound%20system%20volume%20controls

Furthermore, what if I don’t want to set the contribution of anything, but the global volume?

You do have the *volume setting. However there are clearly problems with it, and these do need sorting out.

The presumption (as indicated by Jeffrey’s document) is that *volume won’t affect 16bit. But in reality it can and does.

But it already depends on what settings and driver, etc, you’re using! So at present we have confusions like:

1) Some people using the same software (e.g. PlaySound + PlayIt) may find that *volume is giving them an overall volume control, whilst others find it isn’t.

2) Some who use two different players (e.g. PlaySound and DigitalCD) find one is affected by *volume and the other isn’t. (And which one can also vary from person to person).

3) That people get clipping without realising and just assume “that’s what this music sounds like” or “the sound on this machine is rubbish” or whatever.

All the above depends on the settings of the individual players, which will vary. But it means that we don’t actually have what you want now!

As things stand you can’t be certain in advance that either *volume will adjust all sources or that it will adjust none of them! You have to check every case and maybe experiment with settings, read help files and try and work out what they mean. They often don’t make this plain.

Indeed, in some cases (for some other aspects of this as well) I suspect some assumptions, flags, etc, may have become ‘inverted’ in their meanings and interpretations.

Below all that is the problem that *volume is a nonlinear mechanism really aimed at 8-bit ‘logarithmic’ samples and voice generators. So heaven knows what it is doing when given 16bit LPCM. My guess at present is that this isn’t too bad because I can get output with, say, low levels of intermodulation distortion. But for all I know this does cause problems I haven’t picked up.

I’m happy with the idea of a global ‘volume’ setting. But if so, it needs to sort out the above and every player, etc, follows the same rules in a clear manner.

We also need to ponder the following conundrum.

At present *volume apparently provides no setting for ‘unity gain’, and its (default, mind you) setting of ‘127’ amplifies 16bit material into gross clipping. So to avoid that you then need your player to scale down the values before it duly scales them up again. That’s a waste of effort, and does damage to the performance.

If we change *volume we’d need to take care not to break how it operates with existing players (inc, I guess 8bit). For all I know, some of them rely on ‘127’ scaling up!

So I suspect the best we could do would be to:

A) Tweak the 16bit behaviour of *volume so that a setting of ‘100’ was the default and meant ‘unity gain’. People could then wind it up or down as they chose if they set their player to use it.

B) Check carefully what on Earth it is doing to 16-bit and ensure that unity gain meant ‘pass the parcel’

C) Make sure players and their users know what the settings for the players mean and so can make an informed choice. I doubt most people have had any idea. This all came as real surprise to me and only emerged when I started testing and fell over the really weird behaviour!

Personally the above seem a fair way to me. It means I and others like me could easily bypass or set unity gain. Others could use volume as I think you prefer.

We can then get on the the next area of muddle and puzzles… mixing. That’s probably even more puzzling than this one! 8-]

BTW Is there a way to be able to use ‘*’ as a prefix to type something like ‘*volume’ WITHOUT this idiotic interface assuming it means bold if I dare use another asterisk in the same para? It makes talking about star commands a real pest!

Jim

Doc now on the wiki:

https://www.riscosopen.org/wiki/documentation/show/Sound%20system%20volume%20controls
 

Thanks for putting up that page. I’ve been meaning to do a better diagram, etc, for you, but I’ve delayed in the hope that we could first resolve what is actually happening in areas like 16bit application of *volume. I also have some puzzles wrt mixing… I’ve left them so far in the hope we can clarify the gain situation and interpolations, first, as they probably matter rather more. Have a more general impact.

Jim

WITHOUT this idiotic interface assuming it means bold

Stupid things Textile does when parsing are the stuff of legend.
My preferred option is to wrap commands in @ symbols – turns it to “code” and also means you can use angle brackets without using glyphs, like *Volume <amount, 1-127>.

At present *volume apparently provides no setting for ‘unity gain’, and its (default, mind you) setting of ‘127’ amplifies 16bit material into gross clipping.

A value of 127 should be unity: the “well behaved” 8 bit voices use (127 – volume) as a log attenuation factor, hence 127 is 0dB attenuation. Pages 32 and 33 of the VIDC datasheet (0460,020 from 1986) explain the background why this would be so from an electrical point of view.

It shouldn’t affect 16 bit material at all since the command is decoded by Sound1 and generates an 8 bit log volume lookup table in VIDC’s weird sound sample format.

A value of 127 should be unity: the “well behaved” 8 bit voices use (127 – volume) as a log attenuation factor, hence 127 is 0dB attenuation. Pages 32 and 33 of the VIDC datasheet (0460,020 from 1986) explain the background why this would be so from an electrical point of view.

The snag being that it does affect 16bit material :-/

and in practice:

A) 127 applies a gain that causes gross clipping. What I measure seems to agree with the value returned if you ask for the gain. About a factor of x 2.5.

B) there seems to be no value that actually gives unity gain.

So we either have to play ‘hunt the thimble’ when using 16bit players to make sure that the volume setting is not tampering, or make some other change to deal with this. Its likely to occur whenever someone tries to play things like mp3 / wave / flac / etc. I’ve only checked PlaySound and DigitalCD using PlayIt, etc. But I’d assume other players will be affected.

Hence the comment I made some time ago about the maxim very familiar to engineers.

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

I’d be quite happy if the fix was to make ‘127’ actually give ‘pass the parcel’ unit gain. But at present that’s not what happens.

Personally, I’d be quite happy if the fix meant that the volume setting was ensured to be disregarded when playing 16-bit material using any application or driver. But I take Colin’s point: That some people do want a ‘system’ global volume/gain control. That seems fair enough to me.

So it looks like what is required and people will agree with is that the relevant (module?) code needs to be fixed so that ‘127’ will then actually provide ‘pass the parcel’ unity gain.

What about DigitalRender and *nix ports? Do they come into this? (In practice rather than theory.) I’m used to the “Chipmunks problem”. But I’ve not tested for similar gain problems as I’ve focussed on ‘native’ apps, etc, thus far.

Jim

Stupid things Textile does when parsing are the stuff of legend.
My preferred option is to wrap commands in @ symbols – turns it to “code” and also means you can use angle brackets without using glyphs, like *Volume <amount, 1-127>.

Ah! Thanks. I’ll try to remember that. Makes sense also as a way to highlight commands, etc.

Jim

The question I’d now like to ask is:

Should I raise some of what we’ve discussed – e.g. the *volume behaviour with 16bit sound as a ‘bug’ or an item to be sorted on one of the other subforums?

Or has raising it here meant it will now be looked at? Afraid I’m not yet sure of the mechanisms for getting code like this dealt with. How do we go from discussion to a resolution like having *volume 127 give unity gain for 16bit?

Jim