How to do USB audio

Says device not found.

You can look at the descriptors here

There is nothing you can do that is better in any way than hacking off the bottom 8 bits. You can do worse; dithering is one example. All it does is add noise.

Sorry Dave, afraid what you say is wrong. It doesn’t just “add noise” it prevents the systematic quantisation from generating signal-related distortion. I’m surprised you don’t know this. Do you have a copy of, say, Watkinson’s “The Art of Digital Audio”? That should explain this and also how noise-shaping helps.

In fact I think I’ve already done a webpage to demonstrate this. At least one editor of a certain hifi mag doesn’t seem to understand the point, so you may be illustrious company. :-)

This stems from the same formal Information Theory requirement that means that when doing an ADC we have to use sufficient bits per sample to resolve down into the noise level. Othrwise we fail to make a complete record and the result is systematically distorted.

Jim

To follow up my comments on dither I can add a couple of URLs that show the effect of failing to employ it.

http://www.audiomisc.co.uk/ddd/DirtyDigitalDelusions.html

The above page was written because one magazine keeps using undithered signals and giving the impression that the quantisation distortion which then arises is ‘inevitable’ for Audio CD. ’Tain’t so. Dither applied correctly fixes the problem.

http://www.audiomisc.co.uk/inadither/Page1.html

The above is the first of a set of four pages more generally on the topic.

What perhaps people don’t realise is that dither can allow a digital system to convey signals that are below the noise level. No dither, and these components are lost.

Jim

If you can run the app from http://davehigton.me.uk/Audio/ModuleTest1.zip in a TaskWindow and send me the result, that should do the job.

Would I need to do that on the Iyonix, or can it be done on my ARMiniX?

That asked, at present I’ve not switched my ‘Plus’ DAC to Class 2 as I’m awaiting you/Colin commenting on what I wrote about that earlier.

Jim

Theres no need to switch it to class 2 for me. I only asked about the descriptors on your device out of interest. I can manage with my own device to test with.

Jim: we’re talking about audio here, aren’t we? There is no real-life audio signal with a sufficiently high signal to noise ratio that it is not already dithered. Therefore further dithering will only add noise.

And if you think you can hear an artifact at -108 dBfs (which is about a quarter of an LS bit for 16 bit converters), in the presence of a -60 dBfs tone, in any realistic circumstances, well…

FYI I am very well aware of dithering. My experience of A-D and D-A conversion, decimation, interpolation etc. was gained in the context of the design of a digital instrumentation recorder, where spectral purity is paramount, and there is normally no question of auditory masking. What you measure is what you get.

BTW I was at University with John Watkinson.

Jim: we’re talking about audio here, aren’t we? There is no real-life audio signal with a sufficiently high signal to noise ratio that it is not already dithered. Therefore further dithering will only add noise.

I’m afraid that I don’t know it to be the case that all 24 bit audio recordings are already noise dithered up to above -95dBFs. Given the real-world dynamic range of orchestral playing I doubt all meet such a high requirement that 24bit recordings are already effectively dithered to above -95dBFS. I certainly doubt all future recordings will do so given the prevalence now of 24 bit recording and better kit, etc. The full range of an orchestra going full belt is well bigger than 100dB above background noise in a quiet studio.

And if you think you can hear an artifact at -108 dBfs (which is about a quarter of an LS bit for 16 bit converters), in the presence of a -60 dBfs tone, in any realistic circumstances, well…

Again, you’d have to show me no-one can hear the effects. But the reality still remains that at least some 24bit inputs may need dithering to avoid the needless creation of unwanted distortion products.

Erm, the unwanted alias remains at this level even when the signal is smaller. And people do find even -40 to -50dB levels of anharmonic distortion audible. Bear in mind that’s talking about the 1% to 0.3% anharmonic distortion range. So please think again about this. This may not matter much on continuously loud heavily compressed pop music. But for other kinds of music it can matter. In some ways its akin to the old Class-B ‘crossover distortion’ problem that some designers initially assumed couldn’t matter… but did.

FWIW My background in this isn’t just WRT audio. But also from running a research group specialising in measurement instrumentation, supplied to people like the NPL. So like yourself I understand the need to avoid adding systematic special components. Random noise can be averaged away. Added systematic tones can’t. Similarly, dither is needed to preserve any real persistent components below the quantisation level.

Jim

Dave: Just to add to the above for the sake if clarity.

I assume that you agree that dither does not “simply add noise” and that it does in fact remove systematic aliasing caused by undithered quantisation. It was the assertion that “All it can do is add noise” I am pointing out is simply wrong. Hope you agree with this.

On that basis the only questions are if it practice is is worth doing in a given situation. There I’d say “depends on the circumstances” and again I hope you agree. So…

If someone has a 16bit DAC and if implimenting dither and/or noise shaping in a module is awkward then I’d agree it makes sense in practice not to do them there when cutting 24bit down to 16bit. This is for various reasons which I think have already been discussed, but I’ll repeat for clarity.

Firstly someone using a 16bit DAC is essentially accepting they won’t get the same level of performance when playing 24bit material as they’d get with a 24bit DAC. So may not notice or be concerned. If they were, they’d look for a 24bit DAC.

Secondly, we can always look to the playing application ‘above’ the module layer to provide its own processes like dither or noise shaping if desired. So if someone has 24bit material to play they can hope to use a playing application that will do the 24 → 16 conversion with dither and/or shaping if they have a 16bit DAC. That said, they’d be better advised anyway to get a 24bit DAC – but of course that may cost them more than using an application that does this.

That said, to me the primary point really hinges on how difficult it would be to use dither and/or shaping in a module. If they are difficult, fair enough, leave it to an application. If simple then using dither and noise shaping can give a lower percieved noise floor as well as avoid the anharmonic distortions, so desirable. Of course if the source material is lousy none of this matters. But if it is good, it may make a difference. So it comes down to if it is sensible in a module, or best left to an application.

Hope that makes sense.

Jim

Did we agree that we’re talking about audio?

What’s the signal-to-noise ratio of a violin plus violinist? How spectrally pure is a flute?

Musicians breathe. They wear clothes that rustle. The instruments themselves have a surprisingly limited signal to noise ratio. You might also get a surprise if you look at the signal to noise ratio of microphones with real sound sources.

There isn’t a real audio source in the world that isn’t already dithered. So if you dither it again, all you achieve is to add noise. (Although the noise is also likely to be inaudible because it’s so low in level.)

One of the graphs you linked to shows a -60 dBfs wanted signal with a -108 dBfs artifact. That looks to me like 0.4% of distortion content. But have you any feeling for what -108 dBfs really means in terms of audibility? And what on earth are you doing trying to listen to the output of a signal generator quantised at -60 dBfs and complain of an artifact of a quarter of an LSB in magnitude? The wanted signal may be audible, but it isn’t audio in any meaningful sense.

What’s the signal to noise ratio of your listening environment?

Did we agree that we’re talking about audio?

Yes. In the context of well recorded 24bit high rate recorded audio.

I am sorry if you’ve become irritated about this as the tone of your response seems to indicate. But do you really feel that dither simply is never needed for any digital audio recordings or processes? If so it is fairly easy to show that isn’t correct.

You haven’t dealt with my most basic question. Do you agree that dither allows us to remove the anharmonic aliases that otherwise arise due to (re)quantisation? If so, then you can see that the flat assertion that dither “will only add noise” is simply incorrect.

Yes, I do have some idea what a 100dB – like range sounds like. I used to routinely go to live orchestral concerts. Various venues from RFH/RAH though St John’s and Maida Vale. I also have over the years recorded and analysed recordings and had various conversations with those involved, at the BBC and elsewhere. I’ve also been an AES member for decades. I’ve also spent more hours than I’d care to count looking at scope / analyser screens displaying musical signals.

Yes, musicians breath, and move. I’ve also heard Barbirolli ‘sing along’ and Gould. That’s all part of what was recorded and can be heard.

And some people do indeed use headphones or play a good hifi to get sound pressures at their ears which come close to the levels of listening to an orchestra live. So we can’t assume that -60BFs will be too quiet to hear clearly.

However to get any further I think I really need to ask you again to reply to the basic question above. If you won’t accept that dither also lets you avoid systematic aliasing anharmonic production then I can’t explain the other things it can support like giving an audible SNR greater than 95dB for 16bit audio. Or why in practice low-level signals wrt 0dBFS may be more common than you seem to realise.

I can understand/agree that it may not be practical to include dithering in an audio module. But that doesn’t make it a bad idea more generally. Nor does it only “add noise”.

Jim

So we can’t assume that -60BFs will be too quiet to hear clearly.

My suggestion is that -108 dBfs will be too quiet to hear clearly, not -60 dBfs.

Re. dithering: if you’re dealing in audio programme material, then dither won’t help you because:

a) real programme material contains its own dither. In spades. This means that the systematic products simply don’t appear in the first place;

b) even if you managed to contrive a systematic wanted signal with no noise, the unwanted products are at such a low level as to be inaudible in a 16 bit system.

Those are my grounds for saying that dither won’t help. It solves a non-problem.

If you’re exiting the real world of audio, and generating signals with no noise (e.g. by direct digital synthesis), and you’re using spectral analysis equipment rather than the Mark 1 Earhole, then dither can help. But it’s outside the real world of audio, i.e. the world containing stuff you’d want to listen to.

My suggestion is that -108 dBfs will be too quiet to hear clearly, not -60 dBfs.

I wish it were that simple. :-)

Firstly, the risk is that the low level component may change the perception of the high level one. I used a sinewave to show the quantisation simply and clearly on a graphic but the effect is more complex for real music with many components as it creates complex intermod. So real music signals can be more problematic, but less easy to show on a simple spectrum demo.

Secondly, some users may be having to do something like apply a volume (gain) control early in the chain. Thus they may well be cutting down the signals by a fair amount before you truncate. The unwanted component won’t get smaller in proportion, so the levels of anharmonic distortion as a relative amount will then rise. That means we may be dealing with intermod distortions of levels up to a percent or more.

There are also some other reasons, but I won’t bother to list them as I’ll accept that you’re not convinced. :-)

FWIW I’d done an analysis of a real commercial recording to try and show some of the reasons I think as I do. However I’m quite happy to agree that this often simply won’t matter or be noticed. Particularly by those who aren’t used to both live acoustic music and very very good reproduction. But it may do for some people in some cases.

Anyway, to hell with what I think about that. :-) If anyone really wants dither/shaping they can always add it at the app level if they wish.

Colin now has a version of his modules, etc, that work OK on my ARMiniX, albeit with some snaglets at present. :-] Uses Class 2. So I’m hoping that might also make it possible for your program and USBAudio module to make use of that?

Jim

Colin now has a version of his modules, etc, that work OK on my ARMiniX, albeit with some snaglets at present.

I’d like to try that on my BBxM. Is it at the same address as the previous version? What are the snaglets?

So I’m hoping that might also make it possible for your program and USBAudio module to make use of that?

I’ve been looking at Release 2 over the last few days. I’m going to need some remote testing help again, because those lovely people who came up with release 2 made it substantially more difficult to get the information we want. In particular, in Release 1, the device descriptor was all that was necessary to determine all the available sample rates. Now with release 2 it’s necessary to interrogate the Clock Source entity by means of a separate command. If there are any Clock Multiplier entities, they need to be similarly interrogated, and the resulting sample rates computed…

I don’t recall seeing a Clock Multiplier entity in any of the sets of descriptors either of you has sent me, which is a mercy.

As for “my program”: I’ve always said that it was just a test bed for calls to the USBAudio module, for my use, and would not be a supported application. I would like to see someone with more experience than myself set about extending an existing application or creating a new one that will do the job better and more comprehensively.

I’d like to make another public statement: my vision for the USBAudio module is for control only. I don’t envisage the USBAudio module handling the media streams, as that’s a generalised process, not at all specific to USB, which therefore belongs elsewhere.

Anyway, to work on some software for some Release 2 experiments…

There really isn’t a low cost USB audio device that conforms to Release 2, is there? The only reason I would like one is to support work on the USBAudio module.

Jim’s using the version you tried and said froze the machine. I’m using it on an Iyonix playing hires from a USB memory stick as I type this :-). The snaglet is that it breaks EtherUSB so no internet. I think its pretty picky to want both :-)

This is the cheapest class 2 device I found. Very nice too.

I would like to see someone with more experience than myself set about extending an existing application or creating a new one that will do the job better and more comprehensively.

Understood. FWIW a while ago I hacked a copy of PlaySound so it would auto-switch the system rate to ‘match’ being either the source file rate or x2 that, file by file.¹ So I’ve been wondering if I could do something similar to send the output to USB. However to release something like that I’d need the approval/permission of Chris Martin as I know he doesn’t want ‘different’ versions about as it will create confusion. May be OK if I can do it and give the result a totally different name, though.

FWIW2 the code in !PlaySound is in BASIC, so I also suspect Colin or yourself could use it as a basis more easily than myself! But I appreciate you’d probably prefer to point out you’ve already done the ‘hard bits’ and leave something like this as an ‘exercise for the student’. i.e. me or someone else who can make use of the modules/API you generate.

Jim

¹ Useful on the ARMiniX/PandaRO when it no longer provides 44.1k/48k support to get the best results from the internal hardware. Avoids the system linearly interpolating awkward rate ratios and generating hash in the process.

FWIW I’m hoping soon to be able to start documenting the behaviour and maybe writing a simple demo ‘player’ of my own in ‘C’. Partly as another example for others, and also because I only really understand something by trying to do it myself. Good way to find out what I didn’t understand. 8-] So even if another demo prog from me isn’t useful for anyone else, it helps me to understand and document without mistakes.

Jim

I’m slowly adding Release 2 support. There’s an interesting issue: while Release 1 devices have class 0 in the device descriptor (which means look at the interface level), Release 2 devices are class 0xEF, subclass 0×02 and protocol 0×01, which is a generic thing (i.e. not necessarily audio at all) and says that Interface Association Descriptor aware enumeration software must be loaded. The IAD-aware enumeration software has to… look at the interface level.

The difference that’s affecting me at the moment is that RISC OS sees class 0 devices, scans their interface descriptors and creates system variables with class-subclass/protocol values read from the interface descriptors; but it doesn’t do the same for EF/02/01 devices. Thus the method I use for enumerating Release 1 audio devices simply doesn’t see Release 2 devices.

I’m thinking that IAD-aware enumeration software should be part of the OS, since it appears to be generic. But that’s about all I know at the moment.

What does anybody else think?

My USBModules will now softload on an ARMiniX and leave EtherUSB working.

Would anyone like to try running !USBModule on a different machine – its tested on an Iyonix and ARMinix so far. It should be run from a RAM disc.

After running !USBModule there may be long pauses in the taskwindow display while the new modules are installed and usb devices are found again.

When complete the internet should work as before.

Would anyone like to try running !USBModule on a different machine

It stiffed my BBxM completely, asking for me to insert HardDisc4, which is a USB spinning rust drive, even though I ran the app from RAM disc. At that point the mouse and keyboard were dead.

The problem seems to be that so many things require HardDrive 4, so, when it goes away, there is a deadlock: an error box, but USB is dead so the mouse won’t work so I can’t dismiss it. I can’t see the solution.

@Colin
I am posting this from my RasPi after running !USBModule, so, I guess it’s OK on the Pi.

I guess the only way it would work on any hardware is if the Boot drive is not usb. Iyonix is ok, being ADFS. RPi usually has a ‘combination’ SD card so the boot drive is SDFS. Conventional BB/ARMIni as I have has the Boot drive as a usb pen drive.

Both the BB and the PB/ARMiniX can be fitted with one of these combination SD cards so SDFS is used for the boot drive. I actually tried on my ARMini to use such a card which I produced myself, but on both occasions it got corrupted after a few days and no longer booted (possibly after an OS update). I went back to using a separate Boot drive and the main storage is a Fat32 SSD. My PB has a combination SD card which so far has been fine, but I still use a SSD (Fat32) for the main storage which is a lot faster than the SDFS class 10 SD card.

I was going to give the new USBdriver a whirl on the BB, but if Dave has found this problem, then maybe I will hold off.

Thanks Ronald – one step nearer

Dave. I’m able to load the modules even if I rmkill ADFS

Does rmreinit scsisoftusb cause problems – it will take time for your usb disc to reinitialise.

Just to eliminate the obvious you are not trying to run !USBModules from the zip file are you?

Just to eliminate the obvious you are not trying to run !USBModules from the zip file are you?

No, it’s the unpacked version, in RAMFS on the BBxM.

Does rmreinit scsisoftusb cause problems – it will take time for your usb disc to reinitialise.

No problem. I ran it from a TaskWindow. The drive was back in a couple of seconds or so, and appears to be readable afterwards. No protests along the way.

I’d forgotten that USBReplaceModulesTest in the distribution doesn’t work for you.

If you are inclined could you try to establish which module is causing problems.

If you look at USBReplaceModulesTest there is the line | Restart modules near the end.

Not all the modules are relevant – thats why there is an x in front of them – if the module is not in rom their rmreinit error is ignored.

USBReplaceModulesTest will fail if a module that it kills is not in the rom. ie if the module is softloaded rmreinit won’t work.

You will notice in USBReplaceModulesTest that the modules are all killed and then all rmreinited. So if you comment them all out and then uncomment from the top and bottom a module at a time so that modules that are rmkilled are also rmreinited maybe then we can find which module fails.

I’ve just had another thought that the problem may be the editor that you are using so try changing USBReplaceModulesTest to an obey file so that it doesn’t use a taskwindow.

I’m thinking that IAD-aware enumeration software should be part of the OS, since it appears to be generic. But that’s about all I know at the moment.

Can that. It already works. (I know a bit more now; thanks again to Colin for some help.)

Problem solved. Release 2 devices are already listed in the way I need.