How to do USB audio

I assume you want the test run with the rDAC connected?

Run the test with anything connected that doesn’t work correctly. It will cope with multiple audio devices being connected.

That test will only help with things that the USBAudio module doesn’t get right; it won’t help with streaming.

OK, here are the results.

*ram:ModuleTest1
USB12
Devices: 1
USB12
Lang ID: 0409
Manufacturer: ARCAM
Device name: ARCAM DAC
Descriptor length: 121
09 02 79 00 02 01 00 40 0A 09 04 00 00 00 01 01
00 00 09 24 01 00 01 2E 00 01 01 0C 24 02 01 01
01 00 02 03 00 00 00 09 24 03 02 01 03 00 01 00
09 04 01 00 00 01 02 00 00 09 04 01 01 02 01 02
00 00 07 24 01 01 01 01 00 17 24 02 01 02 03 18
05 00 7D 00 44 AC 00 80 BB 00 88 58 01 00 77 01
09 05 01 05 49 02 01 00 01 07 25 01 01 00 00 00
09 05 81 01 03 00 01 07 00
Unknown descriptor type at line 290
*

I’d loaded Colin’s modules and yours and had the rDAC plugged into one of the front-panel USB sockets on my ARMiniX.

Jim

Jim, I think the ARCAM DAC’s configuration descriptor is broken.

Let’s analyse the top part of it in very abbreviated form:

09 02 79 00 02 01 00 40 0A
Standard Configuration Descriptor
 Total length: 121

09 04 00 00 00 01 01 00 00
Standard audio control interface descriptor

09 24 01 00 01 2E 00 01 01
Class-specific audio control interface descriptor
 HEADER
 Audio dev class release: 1.00
 Total length:            46

0C 24 02 01 01 01 00 02 03 00 00 00
 Input terminal descriptor

09 24 03 02 01 03 00 01 00
 Output terminal descriptor

09 04 01 00 00 01 02 00 00
 Standard audio streaming interface descriptor

You see the total length of the class-specific audio control interface descriptor? It should include the length of itself (9), the input terminal descriptor (12) and the output terminal descriptor (9), but no more. Therefore it should be 30 (0×1E), not 46 (0×2E). The error causes the following parts of the descriptor to be decoded incorrectly.

Colin, can you please confirm whether my analysis is correct?

Jim, I think the ARCAM DAC’s configuration descriptor is broken.

OK. I’m trying to recall. Didn’t it work a long while ago with my Iyonix? I’m unsure because I now have so many versions of the software/modules and have done so many tests! Easily confused. :-/

Jim

Sorry for the delay Dave the dreaded flu has hit these parts. You are correct it should be 0×1e. I’m wondering if it is a power problem. Jim if you run Dave’s ModuleTest1 program a few times unpluging and inserting the USB plug between tries does the faulty byte stay as 0×2e

Mainly Jim you’ve been using my player and I don’t use these sizes to parse the descriptors. You’ve got that many devices it’s no wonder you are confused. You have used Dave’s player successfully with a USB1 device but which one who knows :-)

As far as I understand it the original DACMagic is only USB1 all of your other devices are switchable to either USB1 OR USB 2. In USB 2 mode your devices don’t work with Dave’s player because the bit resolution is 32bit and Dave isn’t upscaling the resolution. All of your devices should work in USB1 mode with Dave’s player if you feed it a wav file compatible with the device – ie it doesn’t do any modifications to the file to get it to play. I should add at this point that Dave is interested in detecting the device not playing music in case anyone was wondering why.

If you had all of your devices in USB1 mode on an Iyonix Dave’s player should work.

If you had all of your devices in USB2 mode on an Iyonix Dave’s player will fail because it is trying to find an exact match to the wav file.

On the ArminiX the USB 2 situation is the same as the Iyonix.

In USB 1 mode on the Arminix it should work with Dave’s player but now the problem is with my USBModules working intermittantly but if it gets to the playing stage then Dave’s job is done and it’s my problem.

I’d be interested to know if one of your devices worked in USB1 mode through a USB2 hub to your linux box.

I’d be interested to know if one of your devices worked in USB1 mode through a USB2 hub to your linux box.

I’ll do some more tests and report back when I can. (Going shopping this afternoon, though.)

However the answer to the above is, yes. Until recently I was using the DAC Magic Plus in ‘Class 1’ mode via an external USB hub.

I’m now using the same arrangement with the Plus in ‘Class 2’ with both the linux box and my ARMiniX. Lets me ‘share’ the DAC and other items as I also have a switch which lets me choose which machine is the host for the hub.

However until I switched the Plus to ‘Class 2’ I think I always used a ‘direct to computer socket’ connection for tests using the ARMiniX or Iyonix as I wanted to avoid the risk of complications due to the hub or switch.

Jim

OK, just done a quick check.

Tried the rDAC with my ARMiniX via a front socket, a rear socket, and via a hub. Each time I switched the DAC off and on again when changing the connection.

ModuleTest1 shows that the USB device number changes, but otherwise the response was always the same. Didn’t work. Using Colin’s player and modules the taskwindow seems to think it is playing. But no sound from the DAC.

I’ll check with my Iyonix later on. Maybe the rDAC has broken. I noticed a day or two ago that the its input selector button doesn’t always now toggle the input. Assumed this was a duff switch, but maybe something else is wrong with it. That said the USB LED switches from red to green when it connects.

Jim

Duplicated

I don’t think it’s broken – other than the data stored on it to produce the Configuration descriptor is incorrect. I’ve seen a lot worse than that. I’ve just sent back a webcam whose descriptors claimed it had a mono mic when it actually had a stereo mic. Making it impossible to use the mic generically – didn’t even work on my windows laptop with their own drivers.

Duplicated

Curious to know what you did.

FWIW I’ve now just tried the rDAC with the Iyonix. Didn’t work. So either it is broken, or something else has changed, or I was simply wrong to think it had worked before. Colin: On the Iyonix I used the last version of your modules that were Ok on that along with your BASIC player app which had to have the filename given in a PROC rather than by filter running. But didn’t work with the rDAC. It did give an error rather than thinking it was playing, though.

Jim

Curious to know what you did.

Posted the same post twice.

Presumably it works on linux so isn’t broke. If you say something doesn’t work I need to know:

1. Machine: iyonix – good
2. used my player: yes – good
3. Audio device mode: Class 2, Class 1 ?
4. Plugged directly into machine: ?
5. Plugged into hub: ?
6. If plugged into hub is the hub USB 1 or USB 2: ?
7. If you get an error what error: ?
8. Do you have multiple audio devices plugged in: ? – don’t. The wrong one may be selected.

The only error I’ve seen is if the file has been left open have you tried resetting your iyonix?

Presumably it works on linux so isn’t broke. If you say something doesn’t work I need to know:
1. Machine: iyonix – good
2. used my player: yes – good
3. Audio device mode: Class 2, Class 1 ?
4. Plugged directly into machine: ?
5. Plugged into hub: ?
6. If plugged into hub is the hub USB 1 or USB 2: ?
7. If you get an error what error: ?
8. Do you have multiple audio devices plugged in: ? – don’t. The wrong one may be selected.

Forgot to check it with Linux! Will do that tomorrow all being well.

1. Yes, tried now with Iyonix and ARMiniX.
2. Yes.
3. So far as I know the rDAC is solely Class 1. Always used it that way with Linux.
4/5. Both for ARMiniX. Tried direct for the Iyonix. The messages I get from Dave’s ModuleTest1 don’t change if I more from direct to via hub (except the USB device number rises as it has been switched off, moved, and switched on again.)
6. So far as I know the hub is USB2 Seems to work fine now when I run the DAC Magic Plus via it set to Class 2. And passes the 192k/24bit fine which I think rules out USB1.
7. The error on the Iyonix comes from the ‘frequency get’. The two previous ‘set’ commands seem OK – at least no error shown. On the ARMiniX the get also seems to fail, but then lets your player continue. Maybe this is a difference in versions as on the Iyonix I use your earlier BASIC prog than requires me to edit the program to put the file name into a PROC call. On the ARMiniX I’m using the later !IsocPlayer app via a double click on the wave file.
8. Have the DAC Magic Plus physically plugged in. But switched off and unpowered from before powering up the ARMiniX/Iyonix. So I’m assuming that means it doesn’t exist so far as the computer’s are aware at this point.

I’ll check with Linux tomorrow.

Jim

Have the DAC Magic Plus physically plugged in. But switched off and unpowered from before powering up the ARMiniX/Iyonix. So I’m assuming that means it doesn’t exist so far as the computer’s are aware at this point.

Never assume anything :-) does *usbdevices show the DAC Magic plus with it switched off? It may be that the interface is being powered by USB so it looks as if it is on.

The ‘frequency get’ error is normal not all devices support reading of the frequency in USB1

There’s another error further down the descriptors. The endpoint descriptor for the audio streaming endpoint is:

09 05 01 05 49 02 01 00 01

That last byte is “the address of the endpoint used to communicate synchronization information if required by this endpoint.” (That’s a quotation from the USB Device Class Definition for Audio Devices, Release 1.0, March 18, 1998.) Note carefully that it’s the address, NOT the endpoint number. The synchronisation endpoint is 1 IN, which therefore has an address of 0×81, not 0×01.

I think that DAC should go back to ARCAM and you should get them to correct the descriptors.

Now had a chance to try the rDAC again with Linux. Did this with my laptop as that’s what it has usually been used with. Works OK with that. I did lsusb -vv and saved the results. These are odd because the way the device responds isn’t what I’d expected. Put the relevant part here

http://jcgl.orpheusweb.co.uk/temp/rdaclsusb.zip

Also just checked and my DAC Magic Pro Plus does vanish from being listed by *usbdevices if unpowered.

Jim

I did lsusb -vv and saved the results.

They confirm that the two errors in the descriptors are read out consistently. The error is ARCAM’s.

The error is ARCAM’s.

I’m happy to accept that. And I’m not personally concerned too much as I have other DACs that are OK. However I suspect there will be other cases like this where both users and- I fear – makers will say “Well it works OK with Windows and Macs…”. I wish it were otherwise. Fortunately it works nicely with Linux and I find it useful with my laptop as it is small.

That said, after Xmas/Hogmanay I may have a chat with Arcam about DACs to see what their current models are like. However TBH I may simply ask someone else as I’ve been meaning to nudge Quad and Meridian. Quad owe me a favour so I may try them first… :-)

I’m also thinking of buying a handful of cheap ‘USB soundcards’ to check out. Preferrable from CPC as I find them easy to deal with. So I may get into this (for ADCs as well) then.

Jim

If the problem was the direction missing in the synch address USBModule.zip will fix it.

If the problem was the direction missing in the synch address USBModule.zip will fix it.

Yes I get audio from the rDAC using that. :-) With some caveats…

It plays 44.1k/16 fine. But seems to have problems with 24bit. And with higher rates for 16bit. 48k/16 plays OK, but it then seems to be hit and miss for an escape to be noticed. Trying 88.2k/16 I had to repeatedly hit escape before this was noticed. For 96k/16 the audio clicked and broke up, and I struggled to get it to notice an escape. Much key pounding needed to attract its attention. 8-]

My guess is that this is because the USB1 is simply too slow with the ARMiniX? FWIW This was all tested directly connected to a front port.

So it looks to me like it was as you say. But that as things stand the USB1 route isn’t up to the higher rates (or 24 bit). However I wonder if it would be better if the program was in ‘C’ and that the BASIC interpretation is tipping it over the edge? It seems close to being OK.

I then checked and the same modules played via my Class 2 Magic Plus with no problems at all the rates and depths.

Dave’s program gave an error. IIRC at line 1580.

If it works plugged directly onto an Iyonix I should be able to get it to work with the ArminiX

Does this version of USBModule.zip fare any better.

The new version is ‘better’. It will now play a 96k/24 file. And the behaviour has changed/improved.

44.1k/16 plays fine. And it seems to be more easily able to detect an escape, so that I can halt playing that – and higher-rates files – without having to repeatedly press the key. So for files from 44.1k/16 up to 96k/24 a single escape press gets detected and halts playback OK.

However above 44.1k the replay has ‘pauses’. These occur more often for the higher rates. The more bytes/sec, the more frequent the pauses. In general no clicking, though. Just that it keeps pausing. With 96k/24 it seems to be a couple of seconds of music, then a similar pause, then play the next second or two, then pause for a similar time, and so on. I don’t think any music is missed out, just keeps being delayed before it continues from where it left off.

All with the rDAC connected to a front socket on the ARMiniX. I can also switch off one dac and turn on the other (DAC Magic Plus) and the playback simply uses whichever DAC is available. But the DAC Magic Plus plays fine with no ‘added pauses’ for the higher rates.

Jim

the slow escape detect with higher resolutions may be down to the buffer emptying. If you press escape once and wait does it escape after a second or so.

Can you try plugging the DAC into a hub on it’s own so that the DAC is the only thing plugged into the hub. Then plug the hub directly into the ArminiX.

Can you try plugging the DAC into a hub on it’s own so that the DAC is the only thing plugged into the hub. Then plug the hub directly into the ArminiX.

OK, now tried that. If I connect the hub which only connects the rDAC to the front ARMiniX port it behaves exactly as if the DAC were directly connected. i.e. pauses as described before.

If I connect the hub to a rear socket I get the kinds of problems I described in the pasts. Added clicks when nothing is playing, but otherwise the same pausing behaviour.

Only marked difference was when I then unplugged the hub+rDAC from the rear socket the HDMI connection was lost to my monitor. Blank screen requiring a reboot.

Note, though, that I get that ‘blank screen’ problem if I have my keyboard and mouse connected to a rear socket. Can’t even bootup past it! Its a problem I’ve had since I upgraded to the R-Comp ‘RO5.19’ release. My monitor seems to require a mode that is near the edge of the timing which the machine can drive. I don’t get this problem with the DAC Magic, though. Despite that being via a hub on a rear socket. (But not switched on during these tests.)

Hence so far as I can see, going via the hub didn’t make any difference when using – as before – a front socket for the rDAC connection.

I’m not sure why the added external hub would have helped, though. The front sockets already come via an added internal hub physically distinct from the PandaBoard in the ARMiniX. (The rear sockets are on the PandaBoard.) And the rDAC is mains powered.

BTW It generally now reacts to an escape within a second. Haven’t timed it better than that.

Jim

I’m not sure why the added external hub would have helped, though. The front sockets already come via an added internal hub physically distinct

When using USB 1 over USB 2 I have to spread the USB 1 millisecond workload over 8 USB 2 0.125 millisec time slots for interrupt and isochronous devices (keyboard, mouse and audio) for each transaction translator.

A transaction translator is a hub device which converts up to 1 USB1 bandwidth of data to USB 2.

There are 2 types of hub most have a single transaction translator shared between all devices plugged into the hub but there is another type which has multiple transaction translators one for each port on the hub. The internal hub in your ArminiX has a single transaction translator.

Conversion to USB2 is done in the hub and once the data leaves the hub it is USB2 so by plugging in to a hub on it’s own the device gets a transaction translator to itself. So my load spreading only has to cope with the data from one device.

As you got the same result from a separate hub it doesn’t look like that was the problem.

Conversion to USB2 is done in the hub and once the data leaves the hub it is USB2 so by plugging in to a hub on it’s own the device gets a transaction translator to itself. So my load spreading only has to cope with the data from one device.

I think I follow the general argument, but probably not the details. It does prompt me to point out the following as it may be relevant.

The main external hub I always have connected is plugged into one of the front sockets of the ARMiniX. That external hub then has my keyboard, etc, all, plugged into it. Do this because I need to switch everything between three machines and I can’t get the ARMiniX to bootup reliably now if the keyboard is connected via one of the rear sockets (via an external hub or not).

The keyboard/bootup problem is since I’ve upgraded OS.

But that all means that any internal hub for the front sockets is already always handling the keyboard, etc, via the other socket. Would that give a problem for what you had in mind to test? The keyboard and its PS2 adaptor are very old, so almost sure to be USB1 I guess.

FWIW If I could find a modern ‘left handed’ keyboard as good as the one I’ve been using for years, I’d try it. I could briefly test with a ‘normal’ keyboard and everything connected via a rear socket. But I still quickly get RSI if not very careful, so I’ve not bothered thus far.

Jim