How to do USB audio

Consider it done. The API is revised accordingly.

Thanks. :-) I now have my test/demo player using it OK.

At present I can play 16 and 24 bit files, and either stop them with a keypress or when the file ends. However I need to undo some of the settings I’ve ‘hard-coded’ and arrange so it will work in a wider range of circumstances, etc. Once that’s done I’ll make a copy available so others can have a look/play if they wish.

Works for rates up to and inc. 192k because that’s the range my DMPLus handles. Although I know some DACs now do 32bit 384k. Worry about that in the future. :-)

For widening the range of devices it would work with I’ll need to experiment with or learn about some of the devices that only work with a lower spec than my DMPlus. So once I’ve done the above I’ll try a Release/Class 1 device and look for some cheaper ones. One question, though:

Do the Release/Class 1 devices generally use 3 bytes per value for transfers, or 2, or does this vary unpredictably? I’m wondering about the range of ‘promotions and demotions’ I need to cover for getting wave files of one resolution to play on DACs in general. For the DMPlus in practice I can ignore demotion at present as I expect wave files to be 2, 3, or (rarely!) 4 bytes per value in the file so I only need to deal with adding zero bytes when needed, not cutting down the resolution of the input.

Jim

Do the Release/Class 1 devices generally use 3 bytes per value for transfers, or 2, or does this vary unpredictably?

It varies predictably in my experience. All the devices I have use 1 byte per channel for 8 bit resolution, 2 bytes per channel for 16 bit resolution, and 3 bytes per channel for 20 bit resolution.

Do you have any playing devices with more then 1 bit resolution?

It varies predictably in my experience. All the devices I have use 1 byte per channel for 8 bit resolution, 2 bytes per channel for 16 bit resolution, and 3 bytes per channel for 20 bit resolution.

Does that mean that an individual DAC will have a number of different resolutions, covering each depth? Or do you mean that a DACs typically has just one transfer resolution and it matches the number of bytes per sample for transfers?

If the latter, presumably it means I can assume a DAC that says it is 16bit will be 2 bytes/sample for transfer and one that says it is 24 bit will be 3 bytes. ?

Jim

Do you have any playing devices with more then 1 bit resolution?

Just to clarify. The word “bit” in that question makes me unsure what is meant. Do you mean “more than one resolution”?

I’m not sure what the best terms here may be given that we have situations where the DAC ‘resolution’ can differ from the size of what has to be transferred.

Jim

If the latter, presumably it means I can assume a DAC that says it is 16bit will be 2 bytes/sample for transfer and one that says it is 24 bit will be 3 bytes. ?

You can’t assume that – otherwise there would be no point in having 2 values. As to the terms used I’m using the terms used in the USB Audio Class specification ie ‘bit resolution’ is the number of significant bits in a ‘sub frame’ and a sub frame is the number of bytes in a channel. Data is sent in clusters of subframes called a frame. So for a stereo stream each frame has 2 subframes. I used ‘samplerate’ and ‘samplesize’ for values to pass when opening an isochronous stream – wish I’d used framerate and framesize now.

I have try a device like this . It working fine with the !IsocRecorder. I have also try SampleED . So I can save any rare Tapes.

Does that mean that an individual DAC will have a number of different resolutions, covering each depth?

It can (it doesn’t mean that all will). The most versatile device I have, the iMic, offers resolutions of 8, 16 and 20 bits, at subframe sizes of 1, 2 and 3 bytes respectively.

If the latter, presumably it means I can assume a DAC that says it is 16bit will be 2 bytes/sample for transfer and one that says it is 24 bit will be 3 bytes. ?

Manifestly, your DAC offers 24 bit resolution, at a subframe size not of 3 bytes (which would be efficient and easy) but 4, so the answer is No.

I was asking about having multiple rates/depths because I wasn’t clear if this was a Release/Class 1 issue. As yet all my experiments with doing playout are with the DMPlus which uses 4 bytes per value for transfer, regardless.

To clarify: I assume that the EnumerateResolutions will tell me the list of resolutions and depths OK. However once I have that info, how do I specify to the DAC which one I’m wanting to use? Is this set simply by my choosing the values I want and giving them with the OpenOut call?

e.g. If a DAC as three resolutions/depths (1byte for 8bit, 2bytes for 16, 3 from 24) and I want to use 2bytes per sample for transfer for 16bit audio resolution. Do I call just USBAudio_OpenOut with the R1 set with the Sample Rate, Resolution, and bytes per sample values I want?

Must admit this is bringing back my feeling that we need an equivalent to the Linux ‘ALSA’ so the user can have a settings file which may then be used to alter behaviour if the ‘default’ isn’t to their liking. I’m also wondering about that for situations where someone may have a number of USB audio divices larger than ‘one’! At present my experimental software assumes there is just one device. But at some point I’d want to experiment with having added items.

Jim

how do I specify to the DAC which one I’m wanting to use? Is this set simply by my choosing the values I want and giving them with the OpenOut call?

Yes, Jim, it really is as simple as that.

e.g. If a DAC as three resolutions/depths (1byte for 8bit, 2bytes for 16, 3 from 24) and I want to use 2bytes per sample for transfer for 16bit audio resolution. Do I call just USBAudio_OpenOut with the R1 set with the Sample Rate, Resolution, and bytes per sample values I want?

In the block pointed to by R1, yes.

I really don’t understand where these complications are that you’re looking for.

I really don’t understand where these complications are that you’re looking for.

You may recall the story of W. C. Fields who was found on his deathbed studying the bible. Surprised, they said “We didn’t know you were religeous!”

He said “I’m looking for loop-holes!” :-)

I’m just trying to make sure I have things clear to cut down on the errors I make – both when trying to make a program work and when I write documents or articles later on to explain. Want to minimise the number of times my ‘explanations’ might be wrong because what I assumed was incorrect.

Jim

The experiment/demo player I’m working on now plays 16/24/32 bit stereo wave files using my DMPlus OK. I’m now trying to see if it will work with the earlier rDAC and Halide Bridge. So far no luck. But then neither currently work with Dave’s player, and the rDAC won’t work with Colin’s, either. So I’m not sure if I can get them both working.

Once I’ve done some more experiments to see if I can get at least one of the above working (or not!) I’ll write some !Help and notes, tidy the prog, and put a version up in case anyone else wants to check it out and comment. I think it might now work for most standard ‘Release/Class/USB 2’ DACs, but not for the earlier ones. However as yet I only have a few test devices at present, and the Halide Bridge is a bit odd, and the rDAC might be faulty as previously discussed. So I’ve no real idea how anyone else might fare.

Jim

So far no luck. But then neither currently work with Dave’s player

What happens when you use my player? Does it give an error window and then exit? If so, what is the message in the window?

What happens when you use my player? Does it give an error window and then exit? If so, what is the message in the window?

Ok, now had time to do a more systematic set of tests using the rDAC and Halide Bridge. Results as follows:

Halide Bridge
=============

16bit file
==========

IsocPlayer
==========

SDFS::ARMiniX.$.CD_tracks.wav_in.Yello/wav
     44100         2         2        16
USB10              1         1         1         3        24         5         1
usb_control: bmRType=0x22 bRequest=0x1 wValue=0x100 wIndex=0x1 wLength=0x3 buf=0xA7F48
usb_control: bmRType=0xA2 bRequest=0x81 wValue=0x100 wIndex=0x1 wLength=0x3 buf=0xA7F48
usb_control failed: Bad request
Sample Frequency get: 44100

USB10#nopad;noblock;size264600;samplerate44100;samplesize6;interface1;alternate1;endpoint1:

Started

Press escape to abort

Escape (66)


UAPlayer
========
no matching parameter set at line 1580


24bit file
==========

IsocPlayer
==========

SDFS::ARMiniX.$.CD_tracks.wav_out.SL300Hz-12dBd24bit44k/wav
     44100         2         3        24
USB10              1         1         1         3        24         5         1
usb_control: bmRType=0x22 bRequest=0x1 wValue=0x100 wIndex=0x1 wLength=0x3 buf=0xA7F48
usb_control: bmRType=0xA2 bRequest=0x81 wValue=0x100 wIndex=0x1 wLength=0x3 buf=0xA7F48
usb_control failed: Bad request
Sample Frequency get: 44100

USB10#nopad;noblock;size264600;samplerate44100;samplesize6;interface1;alternate1;endpoint1:

Started

Press escape to abort

Escape (67)

UAPlayer
========

Plays OK

Apart from the 16bit UAPlayer case I hear the output OK.

N.B. The Halide Bridge converts USB into coax spdif. I had it connected to the spdif input of the rDAC. So the rDAC is working OK via its coax spdif input. I assume the above is saying that the Halide bridge works with Colin and Dave’s players, but that Dave’s won’t play 16bit because the DAC requires 3 bytes per sample.

Now the rDAC’s own USB input:

rDAC
====

16bit
=====

IsocPlayer
==========

SDFS::ARMiniX.$.CD_tracks.wav_in.Yello/wav
     44100         2         2        16
USB13              1         1         1         3        24         1         1
usb_control: bmRType=0x22 bRequest=0x1 wValue=0x100 wIndex=0x1 wLength=0x3 buf=0xA7F48
usb_control: bmRType=0xA2 bRequest=0x81 wValue=0x100 wIndex=0x1 wLength=0x3 buf=0xA7F48
usb_control failed: Bad request
Sample Frequency get: 44100

USB13#nopad;noblock;size264600;samplerate44100;samplesize6;interface1;alternate1;endpoint1:

Started

Press escape to abort

Escape (56)
Escape

UAPlayer
========

Error as for Halide Bridge.


24bit
=====

SDFS::ARMiniX.$.CD_tracks.wav_out.SL300Hz-12dBd24bit44k/wav
     44100         2         3        24
USB13              1         1         1         3        24         1         1
usb_control: bmRType=0x22 bRequest=0x1 wValue=0x100 wIndex=0x1 wLength=0x3 buf=0xA7F48
usb_control: bmRType=0xA2 bRequest=0x81 wValue=0x100 wIndex=0x1 wLength=0x3 buf=0xA7F48
usb_control failed: Bad request
Sample Frequency get: 44100

USB13#nopad;noblock;size264600;samplerate44100;samplesize6;interface1;alternate1;endpoint1:

Started

Press escape to abort

Time: 34.99
Finished (78)


UAPlayer
========
 Thinks it is playing OK. But...
 

In *none* the above does the audio appear at the DAC output.
Although for the IsocPlayer I get occasional crackling noises. 
IsocPlayer thinks things are OK, but the expected audio doesn't 
appear at the rDAC output.

Looks very much like the rDACs USB input is weird. I think we found this before. It does, however work with my Linux boxes.

For now I’l leave the puzzle of the rDAC to one side and see if I can find out what I need to do to my own playing program to get it to work with the Halide bridge.

Jim

Ok so Daves player is working as expected and the rDAC not working is my problem.

Could you try USBModuleDebug.zip.

Everything can now be run directly from the zip file – even with the zip file on a USB disc. You do need a Ram disc available.

So after downloading the above and having your rDAC plugged in could you run !USBModuleDebug then the included !IsocPlayer then play a wav file and send me RAM:IsocPlayerDebugLog – you can send it by email.

Thanks

log emailed.

Its possible something has gone wrong with the rDAC. The top-button seems to work now. (It cycles input around USB – COAX – Optical – Wireless.) But a few days ago it was erratic. So if the problem isn’t easy to fix, probably simpler to sideline it.

Jim

The TI-BurrBrown pcm2902 seems to be used in diy projects quite a bit. December EPE has an analyser project. I think the performance is pretty good for a $10 part, but noticeably, it has a full range of recording formats from 8000 mono to 48000 stereo.
It also has s/pdif in and out, so seems like it has pretty comprehensive connectivity for something in the lower price bracket. Behringer UCA202 is one.
Has anyone had a device with this chipset family connected?
Sounds like the all in one chips /are/ limited in quality when compared to the items in the much dearer bracket. It seems their mightn’t be much to be gained by buying a mid priced 24bit unit though.

It also has s/pdif in and out, so seems like it has pretty comprehensive connectivity for something in the lower price bracket. Behringer UCA202 is one.

I was looking at the Behringer site yesterday. Been looking for an ADC that will do at least 96k/24bit. However although they had some, the only ones I could find were clearly aimed at ‘musos’ who want ‘studio’ input connectors and signal levels. Would like something like their ‘downmarket’ ADC/DACs with phono/RCA sockets, but do 96k/24 with a line level reasonably compatible with modern home hifi kit. Failing what I want the UCA202 (or 222?) may do for experiments.

Jim

Now have the Halide Bridge playing using my test program. As I’d suspected the problem was that I’d left some ‘hard wired’ values in what I’d written, set assuming 4bytes per transferred sample. Changed these to pick up the results from the Enumerate swis.

Dave: At present both EnumerateResolutions and EmunerateRates return the resolution (bits) and subframe size (bytes per channel). That is nominally redundant I guess. But it suits me if you leave things that way now. If you decide to remove any of those returns please let me know and I’ll twek my program to follow what you’ve decided.

As predictable, I still get silence from the rDAC although the program finds that the buffer it is feeding is being emptied. So the player is happy but no cigar! :-) That may also explain something else I’ll need to check. More later… but progress has been made.

Jim

I still get silence from the rDAC

There may be more to do in order to get it to work. Release 2 introduced much more complication to clock sources, though I don’t know whether that is an issue for your rDAC – for example, if the clock is disabled, would the device still accept data? (I don’t know.)

Mute may be an issue. Release 2 completely changed bit field allocations for feature units, which reminds me that I haven’t added code to deal with Release 2 for mute and volume.

Release 1 was so much easier…

There may be more to do in order to get it to work. Release 2 introduced much more complication to clock sources, though I don’t know whether that is an issue for your rDAC – for example, if the clock is disabled, would the device still accept data? (I don’t know.)

I’m not sure as the Arcam userguide, very unheplfully, doesn’t say if it is ‘Release’ 1 or 2. I think it is 1 as I got it back in 2011, but it is rated up to 96k/24. Is there a way to check with the RO modules? If not, I’ll probe it with my Linux laptop.

Jim

Recording/input devices:

What devices do people have at present? I’m currently looking at getting one or two to check out and use for tests. The obvious choice from CPC seems to be the Behringer UCA202, but that is limited to 48k/16bit. So I may also get something cheaper from CPC and see if I can blag a loan fancy one from someone else. If anyone has a Behringer contact please let me know, otherwise I’ll try a general guess at an email address for them.

Jim

Been doing some more tests with the Halide Bridge. I’m not certain, but suspect this is giving problems due to the USB1 bandwidth, etc.

I tried increasing my standard buffer size for transfers to 0.2 sec. (Until then I’d used 0.1 sec.) This made no difference. The Halide Bridge continued to work fine for 44.1k/16bit, but higher rates or depths gave a mix of crackles and pauses/breaks in transfer. My test/demo prog also showed signs of having a problem detecting a keyboard hit (e.g. when I hit ‘q’ the playing should tidy up and quit).

IsocPlayer also gave crackles and gaps.

So I tried the same files/modules/player on my Iyonix. This worked a bit better. Could now play, say, a 88.2k/16bit file with no crackles or gaps. But again signs that the player wasn’t really noticing the keyboard all the time. However rates/depths like 96k/24 gave gaps and crackles, and on a couple of occasions generated a sudden hourglass and no sound.

The Halide Bridge is Release/Class 1 I think. So the above makes me suspect that the systems can’t run the data fast enough in USB/Class 1. The only alternative I can think of at present is that I know the Halide is very fussy about timing. However I’ve tried it with both the rDAC and DMPlus to convert its coax spdif output with much the same results.

Whereas the (Release/Class/USB 2) Dac Magic Plus works fine with my ARMiniX right up to 192k/24bit which is its spec limit.

Still get no sound from the rDACs own USB input. So I guess that still sits in Colin’s area. :-)

Jim

Jim: please don’t conflate USB Audio Device Class Releases 1 and 2 with USB1 and USB2. They are entirely different things.

Some settings of audio devices require High Speed USB, which is clearly present in USB2 but not USB1.

Jim: please don’t conflate USB Audio Device Class Releases 1 and 2 with USB1 and USB2. They are entirely different things.

I’ve been trying to take into account your preference for the term ‘Release’. :-) However it is certainly simpler for me to go back to using the same terms as various USB Audio device manufacturers use in their user handbooks, etc – ‘Class 1’ and ‘Class 2’.

Jim