How to do USB audio

re. audio pauses and quality problems: do you get the same symptoms when playing source material from RAM disc?

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

Ah yes, I remember now, I’ve already seen the rDAC’s device descriptor. That’s the one with two errors in it. (Expensive device, and they can’t even get the USB descriptors right.)

Here’s a hypothesis to test.

One of the errors is that the direction of the synchronising interface is wrong – the descriptors specify it as an output, although clearly it would have to be an input in order to work.

Colin: you parse the audio descriptors, don’t you? Is it possible that you have taken the descriptor at face value, and got the wrong direction for the synchronising endpoint?

Even worse, they are both endpoint 1. If the descriptors had been correct, or if you have corrected for their error, it’s OK because the streaming endpoint is 1 OUT and the real synchronising endpoint is 1 IN. Otherwise, both will be taken as 1 OUT.

Re the naming issue, Why not take the stance that Cambridge does on their website and call it USB Audio 1.0 and USB Audio 2.0 ? I suppose you could abbreviate it to Audio1 and Audio2 on a USB forum,
and it does show a clearer distinction from ‘USB 1.2 and 2.0’

EDIT: removed my remark about C code.

You have to laugh.

I wish I could. I spend more time with my head in my hands.

Different outlooks on the same basic premise.

As far as I’m concerned, life is an elaborate joke with me as the butt monkey.

You have to laugh…..

re. audio pauses and quality problems: do you get the same symptoms when playing source material from RAM disc?

Yes. Makes no difference. Perhaps worth reminding people that the ARMiniX main ‘hard disc’ is an SDFS SD card but is not connected via USB. I’m using quite a fast 64GB SanDisc card for my main ‘hard disc’. So I don’t think the problem is USB contention or the speed at which the files can be read.

Seems more like something strange that breaks up the USB 1 transfers or the mode the Halide Bridge uses.

Jim

Why not take the stance that Cambridge does on their website and call it USB Audio 1.0 and USB Audio 2.0

I’d be OK with that. The only drawback is it takes longer to type than ‘class 1’ and ‘class 2’. :-)

Jim

Ronald.

If it’s cambridge audio that you mean they are using class 1 and class 2 just like everyone in the audio world. That’s never going to change. The standard documentation for the audio world’s ‘class 1’ is the ‘USB class 1 release 1’ documents and similarly ‘class 2’ is the ‘USB class 1 release 2’ documents.

Generally it isn’t a problem you can work out what most people have – but Jim has that many devices many switchable between USB1 and USB2 which may or may not also switch between release 1 and release 2 at the same time.

I’m going to have to make a chart to work out what is working and what isn’t :-)

Colin: you parse the audio descriptors, don’t you? Is it possible that you have taken the descriptor at face value, and got the wrong direction for the synchronising endpoint?

Problems like this, once again, make me feel it would be a good idea to have provision for having a script file somewhere that the user could correct. This would let the modules have a place to check for ‘odd cases or user preferences’ when setting up the transfer details, etc.

All being well, next week I plan to get one of the cheap Behringer ADC+DAC boxes. (Probably the UCA202 if the 222 is out of stock.) I think these are ‘class 1’ and have both input and output. So will extend the challenge for me to understand and get them working! But that may mean I’ll also want to do things like use the Behringer for input whilst using the DAC Magic for output! i.e. two devices both connected and in use, having been able to specify my required ‘defaults’ without then having to edit programs to change those defaults when I want to do something else.

This, of course, assumes I can get the (48k/16) Behringer to work OK despite my struggles with the ‘class 1’ Halide and rDAC. 8-] If not, I may sigh and try their more expensive ‘class 2’ 96k/24 devices sooner than I planned.

Jim

Here’s a hypothesis to test.

Unfortunately not I’ve forced feedback endpoints to be the opposite direction to the main endpoint.

Even worse, they are both endpoint 1. If the descriptors had been correct, or if you have corrected for their error, it’s OK because the streaming endpoint is 1 OUT and the real synchronising endpoint is 1 IN. Otherwise, both will be taken as 1 OUT.

And you do the hokey cokey and you turn around – thats what its all about.

Blimey showing my age there – I remember hearing it when I was young honest.

I’m concentrating on USB2 at the moment – it won’t play on the Beagleboard and it should. I’ve been tracking the problem for days.

One problem seems to be interrupts dissappearing for up to 10 millisec – the controller continues to work during this period – I suspect this is something to do with disc transfers.

The other is the controller skipping 125 microsecond transfers. The controller is given a block of 8 transfers to do in a millisec. It does 1 transfer from the block every 125 microsec but occasionally some of the transfers don’t happen – this is all automatic by the controller. There’s no evidence of the transfer starting – they look like they are just skipped.

Problems like this, once again, make me feel it would be a good idea to have provision for having a script file somewhere that the user could correct.

You give up too easily :-) I’ll get your rDac working but I’ll do that after I sort out problems I have with the beagleboard. So I’ll put that on the back burner at the moment.

I’m concentrating on USB 2 at the moment. You have it working on your pandaboard How high a resolution can you play from a memory stick?

Dave.

I should add playing from RAM disc makes no difference.

I’m going to have to make a chart to work out what is working and what isn’t :-)

A 2D sheet of paper may not suffice. 8-]

Jim

How high a resolution can you play from a memory stick?

Suddenly occurred to me this morning that eventually someone would think of that! :-) I’ll find out and say.

Jim

This would let the modules have a place to check for ‘odd cases or user preferences’ when setting up the transfer details, etc.

There is a sort of precedent here – the USB quirks command. Fills you with hope, doesn’t it? ;-)

How high a resolution can you play from a memory stick?

Results:

Using the DM Plus (class 2) I can play anything up to and including 192k/32bit with no problems from a Fat formatted SD card. (Hama 16GB, claims to be class 10) [That is very promising as flac on Fat devices is likely to be a common preference for convenience in the future.]

Using the Halide Bridge I get the now-familiar behaviour with the same card. i.e. 44k/16 plays, but anything higher gives crackles and pauses/gaps.

I did initially start by tying to use an SDFS/ADFS formatted SD card. But there is something wrong when I try to use it. May have been corrupted, or is fibbing about being 64GB. So I’ll need to check that as a seperate issue.

FWIW In general I’m wary of Fat as I’ve had to move to an older version of Fat32Fs as I get problems with the newest version. But the above seemed to work fine.

Jim

So would you say that the USB2 devices always work correctly and the USB1 devices have problems over 44100/16?

When you say crackles/pauses, do the crackles/pauses change much with increasing resolution?

is it (crackles and pauses) or (crackles or pauses). ie do you get pauses where it seems to play ok between pauses?

So would you say that the USB2 devices always work correctly and the USB1 devices have problems over 44100/16?

I’m wary of the plurals here as I am only using three devices! However, yes, that’t my impression. The USB1 Halide Bridge works a ‘bit better’ on the Iyonix, but gives the same type of problems.

At say 88k/16bit I just get an occasional crackle. At higher byte rates there tend to be more frequent crackles and a number of pauses/gaps. The freqencies of these problems are at least at the one per second level, getting more frequent as the byte rate is increased. Hard to be more specific.

At present I’m trying to dodge trying my old DAC Magic (original) again as it means some furtling about with our AV system. But that is class 1 so may give a contrast.

One other caveat. The Halide Bridge can also be fairly picky when used with Linux. The last time I used it I found that it would play but doing something like pause replay or then play at a changed rate would confuse it unless I made adjustments. It may want something like a specific buffer size that isn’t standard or expected. But that last comment is a guess.

The Halide and the rDAC are both now ‘early’ devices which I have because I used to use them but then moved on. I keep them for occasional use and tests. So their behaviour may not be typical of more modern devices. That’s one of the reasons I’m getting one or two more devices to try out. But these probably won’t start to arrive until next week. I’m hoping to also blag a borrow of some fancy ones sometime, but no idea if that will happen, or when. I’d love to try a Benchmark ADC1 USB for recording, though. 8-] Only 1700 USD…

That said, knowing the way computer equipment makers work I feel depressingly confident that there will be many ‘weird’ devices out there. :-/

Jim

Don’t bother with your old dacmagic.

So leaving the rDac aside for the moment, as it doesn’t work, The halide bridge showing similar symptoms on an Iyonix suggest you are plugging into a USB 2 hub. Plugging directly into an Iyonix uses OHCI, ie USB1 directly. Does it work plugged directly into an Iyonix.

Does it work plugged directly into an Iyonix.

Alas, not a simple yes/no result.

I have the impression it is slightly better that way. However as I think I said a while ago, it works better with the Iyonix anyway.

If I use the Halide with the Iyonix I find that I can play 88k/16 files (which will be sent 3bytes/value anyway) OK. This is the case either connecting direct to a front-panel USB port or via the same external hub I use for the ARMiniX. Works both ways. Whereas the same 88k/16 file gives crackles on the ARMiniX (via external hub or direct to a front panel socket).

At 96k/24bit the Iyonix plays without the frequent pauses/breaks I get using the ARMiniX. And the crackles occur much less often. This all applies regardless of if I use a ‘direct’ or ‘via external’ hub route. However I think the direct connection produces less frequent crackles. But its comparing one relatively (compared to ARMiniX) low occurance with another low occurance. It might be if I cut out almost all other tasks, etc, both would be OK.

The Iyonix certainly does a much better job than the ARMiniX. But seems to do this even when I’m using an external HUB. However maybe that means the HUB will work as a ‘transparent’ device for USB1 when used with the Iyonix, but can’t with the ARMiniX?

FWIW I think 96k/24 is assumed to be pretty much the top end of what USB1 is expected to be able to cope with. So this may be a situation where the Iyonix hardware is fairly old and was never made to actually do this. A modern machine’s genuine USB hardware might be fine here. Maybe? But even if so, I have the feeling it gets close to being fine – external hub or not – because the 88k is OK.

Hope that makes sense.

Jim

I think 96k/24 is assumed to be pretty much the top end of what USB1 is expected to be able to cope with.

Yes it is. With my dacmagic XS in USB1 mode I can play perfectly 96/24 on my iyonix either with EHCI via a hub or OHCI directly connected to the iyonix. It doesn’t matter if I use the Iyonix HDD or a USB memory stick to play from.

So it looks like your halide plus is having some problems. Does it work ok on your linux box?

The beagleboard won’t play any resolution properly and all I’ve done is swap the hub with the memory stick and dac on it from the Iyonix to the beagleboard.

I can see why its failing on the beagleboard but I’m not sure at the moment that it isn’t a hardware bug.

I can see why its failing on the beagleboard but I’m not sure at the moment that it isn’t a hardware bug.

I’ve no doubt you’ve considered this already, but could you test under Linux to see if it’s genuinely a HW problem or not?

So it looks like your halide plus is having some problems. Does it work ok on your linux box?

When I get a chance I’ll check it tomorrow with my laptop. (Xubuntu)

I did use the Halide bridge along with an orginal DAC Magic for some time as part of the main hifi system (For those who don’t know, the Halide converts USB to spdif so you also need a DAC.) That used to work OK but it was displaced when I got the Cambridge 851C which is much better.

However the Halide can be fussy. When I used it for a short time with my general purpose Linux box a while ago it kept making nasty noises if I paused play and then un-paused with Audacious, for example. And I know someone who had to have the dCS DACs modified to make them work with it. I think it is very fussy about precise timing. So the problems I see with the ARMiniX may be due to that. FWIW I had to fiddle with the buffer size to get better behavour with Audacious. So there may be a ‘magic’ set of transfer timings and settings it wants.

Jim

I’m working on adding calls to permit other Feature Unit controls to be read and manipulated. May not be of interest to many people; but the iMic has tone controls, so I just have to add the ability to try them out.

There used to be a SetSampleRate SWI in USBAudio, but I didn’t publish the API. When sample rate setting got bundled into OpenOut and OpenIn, I could no longer see a case for its existence. The next version of the USBAudio module will not have it.

Then it will be time for me to fix the SWI numbers.

So it looks like your halide plus is having some problems. Does it work ok on your linux box?

I’ve now re-checked this. The Halide Bridge works almost perfectly with my Linux laptop. 44k – 88k24 play fine. 96k/24 gives an occasional ‘spit’. So slightly better than using one of the Iyonix front sockets direct.

I can’t now recall details, alas, but when I first started using the Halide with a Shuttle running Xubuntu I did have to tweak settings like the buffer sizes to get it working with no problems at 96k/24. Using Auadcious the laptop ALSA direct buffers are set to ‘500’ which I think may be the number of samples, but may be some other unit. I may be able to find the details in my notes, but I’m not very tidy with such things…

Jim

Did you plug directly in to the linux box? If you did it’s likely that it was used via OHCI the same as plugging directly into an Iyonix.

I’ll come back to the Halide bridge. Other than you need some care with setting up I feel its working correctly (ish) on an Iyonix.

I think I need to get linux on this beagleboard to see if that does any better. As far as I can see the controller doesn’t work properly when the top bit of the frame index counter is set.

Haven’t clue with linux or how to get it on a beagleboard. Anyone any ideas where to start?