How to do USB audio

They couldn’t be more different. The UMC202 is a full speed, USB1, Audio release 1 device.

OK correction accepted. :-) TBH I was talking about what the USBAudio Enumnerates, etc, list. Which of course hides such gory details from the programmer as intended.

Jim

FWIW As with the UCA202, the 2i2 occasionally needs a usb kick at first use if it was plugged in when your/Dave’s modules were loaded.

Dave’s module won’t affect this.

From what you say I take it it doesn’t always happen. Does it make any difference which hub you plug the devices into? The least number of hubs between your computer and the device may be better. Plugging into the board directly may be better still. Are you loading the modules or using the roms? If loading the modules are the devices always connected before loading the modules?

Erm… I did. For that part I was reading as a series of 4byte ints in the program I modified to do this

Ah I was refering to your posted listing which is printing bytes

   bsize=rout.r[2];
    printf(" %d bytes returned\n\n",bsize);
    i=0; j=0;
    do
    {
      printf(" %2X ",(int)rates[i]);
      i++; j++;
      if (j==8)
      {
        printf("\n");
        j=0;
      }
    } while (i<=bsize);

From what you say I take it it doesn’t always happen.

The Focusrite 2i2 usually works fine from the first, regardless of if it was plugged in when the modules were installed. However the UCA202 (note UCA not UMC) seems to almost always need a kick if it was plugged in when the modules were loaded.

This is the UCA202 which is the cheaper Behringer device. Not the more expensive UMC202. (It seems common for makers to have a name with a couple of ’2’s to mean 2-in 2-out, and so stereo.) Having decided the UMC202 isn’t as good as the 2i2 I haven’t used it so much.

Could the difference be that the UCA202 is ‘class 1’ / USB1 but the 2i2 is ‘class 2’ / USB2? Alternatively, maybe Focusrite simply make better kit?

Another difference has been that when my recorder program fails or tries to get the device to do something it can’t. Then the UCA202 may ‘lock up’ and not work unless unplugged and connected again. Whereas the 2i2 seems happy to work without this. So my impression is that the UCA202 is more easily upset. Why? Dunno. When it works, it works fine within its rate/samplesize limits.

I think I did try using different connections, etc, and it didn’t make any difference. But it was a while ago so I may be mis-remembering. Can re-visit it sometime if it is useful. However today I’m planning to scan some LP covers. :-)

Ah I was refering to your posted listing which is printing bytes

Understood. No, I’d been trying to sort out my USBProbe program and make it respond correctly when faced with the ‘continuous’ sample rate format. At first I tried to get it to print the max min step values as per API. That instantly showed me it was getting the rates not a max min step. So I then had it print out the values as 4byte ints. In effect what emerged was the rates to the returned limit buffer size, which gave me “44100 48000 88200”.

I then wondered, “Ah, so what comes next?” and let it also print the next 4bytes as another int … giving me ‘0’. Knew this was beyond the specified buffer limit, but was curious in case the limit was off.

So it looks like the actual output when the number of rates returned = 0 emerges as the list, not max min step. But then stops before the last expected value of 96000.

Jim

I’m totally confused now.

I hadn’t realised you had 3 devices and looked back in the thread for a 202 set of descriptors which turned out to be UCA202 so your UMC202 may well be similar to the scarlet 2i2 I can’t find descriptors for it.

Re different connections

If you’ve done it before doing it again won’t help :-)

At the moment I’ve got 15 devices plugged in to the beagleboard and there’s no problems starting up. However I have had occasions where I couldn’t get some device to start up but can’t remember which one and at the moment everything insists in starting up. I should add that I haven’t done anything to fix the device not starting up.

The only difference I can see between unplugging and reinserting and module initialisation is that at module initialisation all devices are initialised at the same time.

I hadn’t realised you had 3 devices and looked back in the thread for a 202 set of descriptors which turned out to be UCA202 so your UMC202 may well be similar to the scarlet 2i2 I can’t find descriptors for it.

I can understand the risk of confusion! The two Behringer devices have very similar names. However the ‘newer arrival’ only came a couple of days ago.

UCA202 = 25 quid device. Only 16k. Plays 32k 44.1k 48k. But records these rates and half those values and a quarter of them. So will record down to 8k rate. Will also record mono. So like an old-fashioned soundcard, but decent quality within the rate and sample size limits. Had this for some time and CJE now “have them in stock”. :-)

UMC202 = about 100 quid. 24bit. Will record and play 44.1k 48k 88.2k 96k. Has microphone and ‘instrument’ inputs as well as line in. Balanced inputs and outputs. Headphone and main line outputs with seperate volume controls. Gain controls for the inputs and switches for mic/line/instrument. Clearly aimed at ‘home studio’. Only got this a couple of days ago.

Plus the Focusrite 2i2 which I’ve had for a while now. Similar in terms of facilities to the UMC202 and also ‘home studio’. But looks to deliver better quality.

I’ll see if I can get some descriptor info, etc, on the UMC202.

Jim

Here
http://jcgl.orpheusweb.co.uk/temp/BehUMC202.zip
is some info returned on the UMC202 by Dave’s ModuleTest1 and !USBInfo.

I’d assumed the interface was much like that of the Focusrite 2i2. Different to the UCA202.

My impression is that from the USB Audio side it works much like the 2i2. Just that the one I have gives worse audio quality and it might be faulty. Has much the same features in terms of knobs and connections.

Jim

Please try with the USBAudio module 0.04, which I put on my web site a couple of minutes ago.

Please try with the USBAudio module 0.04, which I put on my web site a couple of minutes ago.

Yes! T’werks. :-))

Just made a couple of 96k/24 recordings with the 2i2 and my Probe program now returns the correct four rates (i.e. inc 96000).

Excellent. Cigar moment for those who may smoke. ;→

Although Grrr, why do these things happen just before I have to do something else – in this case start dinner? 8-]

Did a quick FFT of the recording and get a nice clean result, too.

I’ll do more tests tomorrow, but looks good. Did a quick 48k recording with the 2i2 and that also seemed fine.

Thanks Dave.

Jim

I’m glad to hear that it works. I can only apologise for my mistake in the first place.

I had used the wrong index into an array, which meant that I got the information correctly, but stored some of it in the wrong place.

The Focusrite 2i2 doesn’t seem to perform very well either. There’s a spectral peak at about 485 Hz, and there are peaks about 485 Hz either side of the 2 kHz main signal, which makes it look like amplitude modulation.

What is going on at that frequency in the 2i2? Is it something to do with driving the halo indicators? The AM suggests to me that the reference voltage is suffering noise injection.

The Focusrite 2i2 doesn’t seem to perform very well either. There’s a spectral peak at about 485 Hz, and there are peaks about 485 Hz either side of the 2 kHz main signal, which makes it look like amplitude modulation.

Your criterion for “very well” seems a little strict for a device that only costs about a hundred quid! You did notice those sidebands are about 110dB below ‘carrier’ did you? 8-] Also well below the LF intermod noise on the UMC202.

I thought you were the one who doubted the need for 24 bits per sample. ;→

I’m not yet sure if they are am or fm. They could be something like a dc-dc convertor ripple altering either the gain or the clock. However I was delaying looking at that until we had 96k working. At some point I want to check it using a different PSU (hub). Indeed, I may DIY a clean PSU as an experiment. At present it uses the USB 5v (sic).

As yet I’m not even clear that they don’t come from the test source. I’m using an rDAC driven by my ROXtone Linux app on my laptop. That computes a dithered 24bit sine tone and sends it out to the rDAC to play. Might be sidebands on that.

Anyway, I’m cooking dinner, so I’m not writing this… :-)

Jim

Hope that some time today I’ll do some 96k tests, inc. using the 2i2/202 on a Linux laptop supplied by a DAC on the ARMiniX to see if that gives results comparable with t’other way about.

I’ll also resume work on the ROSS Doc. So would like to check. Is the API for EnumerateSampleRates correct now wrt it giving max/min/step values when the device uses ‘continuous’ rate settings? Am I correct in assuming that the way the 2i2/202 returned this before was incorrect and the devices simply list the set rates for rec, but this was being garbled by the module to look as if ‘continuous’?

Jim

The EnumerateSampleRates API was and is correct. There was no problem with the way that the 2i2/202 devices returned their data. The USBAudio module had a bug that caused it to store the sampling rates of the second and subsequent interfaces of a Release 2 device as being continuous, regardless of what the device reported.

If anyone is having problems with devices not connecting when the modules are loaded would you like to play with these variables.

Various user setable VarVals with which to tune proceedings:

USB$PowerDownTime      default 200(ms)   Min power down time for a device to
                                         correctly reset device

USB$PortPowerUpDelay   default 300(ms)   Min time to wait whilst device powers
                                         up

USB$PortResetDelay     default 100(ms)   Min delay whilst a device is being
                                         reset
                                         
USB$PortResetrecovery  default 50(ms)   Min delay whilst a device is being
                                         unreset

USB$PortStartupDelay   default 100(ms)   Delay after port fully powered up, and
                                         after issuing port reset command

They set various delays in the startup sequence. If you set them before loading the modules they will be effective during the loading.

OK, thanks Dave. I guessed that was the case but wanted to check before writing about it, and also tidying up and releasing a new version of my recorder and probe programs.

Cheers,

Jim

If anyone is having problems with devices not connecting when the modules are loaded would you like to play with these variables.

Any thoughts on what changes might be most likely to sort out the problems I’ve reported?

FWIW for now I’m focussing on some 96k measurements, but I’ll experiment later on with this problem.

Jim

Don’t know really. I’m not confident they will make any difference because the defaults work ok if you unplug and plugin again – but you never know until you try. If pushed I’d increase the USB$PortPowerUpDelay.

OK, noted the comments on the USB$ values. I’ll experiment sometime and see if it makes a difference.

One other difference I have just found is wrt the 485 Hz tone and sidebands.

On the Linux recordings I just made these don’t show up. And the overall noise floor, particularly at LF is slightly lower. So they do look to be a PSU effect. The Linux tests use the 2i2 and umc202 with my Linux laptop on battery power via a direct port. Whereas my RO tests have been with my ARMiniX via an external 7-way hub that has its own mains power.

I’ll experiment with other usb connection/power arrangements. The problems are at the levels around -110dB so hardly fearfully bad. But look fixable. In some ways very convenient that I get good results with the laptop as that would make a convenient portable recorder.

Jim

Just to confirm the above:

I’ve now tried the 2i2 with a different hub and hub PSU. The 485Hz tone and sidebands vanish. So this looks like the effect of a PSU that switches at 485Hz and lets this out onto its ‘5V’ . The 2i2 probably does some rejection, but this can’t be infinite and -100dBFS is a fair way down. So I tick this as another example of why when I designed low noise amps in the past I often spent more time on the PSU than the amp! For my own use I’ll probably make one of my own favourite design low noise PSUs for 5V at some point when I want low noise capture.

Jim

I’ve now been very surprised by one outcome of experimenting with different externally powered hubs and their PSUs. One of these powered the ARMiniX even when the ARMiniX’s own dc power plug was pulled. This means the hub with that psu shoves 5Vdc back up into the main board via its USB socket (back of the box, so direct to the board).

I’m amazed that a hub should do this! Never occurred to me as it means that it will be easy for two different ‘5V’ supplies to argue about which one is setting the line voltage. Does this mean the hub in question is simply faulty?

Other hub+psu combinations (inc the psu in question) don’t show the behaviour.

Jim

A glance through the USB2 spec section 7.2.1 it says

No device shall supply (source) current on VBUS at its upstream facing port at any time.

so I guess the hub is non standard. Looking around the net there has been a lot of problems with using Raspberry pi’s with powered hubs which supply power on the pi → hub connection so they are not that uncommon.

This means the hub with that psu shoves 5Vdc back up into the main board via its USB socket (back of the box, so direct to the board).

The hub is broken. End of discussion.

Think about it – computers supply 5V on the USB port. They are not designed to receive it there; the power regulation and conditioning is for the input power (like the Beagle xM’s over-voltage).
What’s for USB power regulation? Nothing¹ – because it is supposed to be a source!

Now, there are three options:

1. Use the hub to power the ARM board. Hacky and nasty, wouldn’t recommend it unless the USB input is fed into the correct place (like the Pi’s method). This kind of implies either option #2 as well, or just using the hub as a power source with USB sockets.
2. Open the hub up and figure out where to solder in a 49p diode to stop power going out to the ports. If your hub is made is PRC on the cheap, you might even see a wire link or unbroken track where the diode is indicated on the circuit board!
3. Bin it (the recommended option, really).

¹ Not strictly true – some devices have overcurrent protection to stop devices consuming more power than the port can supply. The average ARM board may or may not do this; often you’ll see the 5V USB power being wired directly to the main system 5V rails. Smarter boards may stick a FET in the way in order that the board powers up with downstream USB devices disabled (helps balance out start-up power drain – get the SoC running and then worry about USB devices).
[ Examples:
My PVR – USB power connected to system 5V via a MOSFET controlled by USB_PWR signal – the MOSFET should block power, but if any is present, it will likely be the place where current differential occurs. (schematic, page 16)
Beagle xM – looks like system 5V feeds into a TPS2045 for overcurrent protection on USB, however the datasheet for the TPS2045 suggests that it is bi-directional? (schematic, page 83)
Pi – directly connects to system 5V (eek!). (schematic, bottom of page 3)
]

Many (In our experience almost all!) USB hubs do not follow the specs. During testing of 20+ hubs to use with Pi’s we’ve found that most wired the 5V supply to the hub, direct to all USB ports. Big brand named hubs are much more likely to conform to the specs and negotiate power.
Another aspect to consider on bundled systems like the ARMiniX, PandaRO & RaspberryRO is that the external USB ports may be direct to the onboard USB Hub or to the internal USB Hub that is plugged into onboard HUB¹. On Pandaboard based systems onboard USB ports are on the back. Only one other external USB Port can be direct to the onboard HUB. As one must be connected to the internal HUB.

¹ Most (All?) USB Hub chips only have four ports so when the internal HUB is a seven port unit, four of the ports are connected to a secondary HUB within the HUB

Beware of diodes in power supply rails. The forward voltage drop can mean that the supply voltage at the receiving end is substantially below specification.

If you’re going to put a diode in series with the rail, don’t use a junction diode (like the one Rick suggested) – use a Schottky, as it will have something like half the forward drop of a junction diode. With a Schottky, there is at least an outside chance that the receiving end’s supply rail will be within specification.

Best is a MOSFET – but you have to be very careful about the design of the circuit. MOSFETs have a body diode between source and drain. If you don’t know what you’re doing, you can still end up with the host system being powered from the hub, through the body diode, if the hub is powered but the host system is turned off.

Beware of diodes in power supply rails. The forward voltage drop can mean that the supply voltage at the receiving end is substantially below specification.

Agreed. I certainly wouldn’t use a diode. So far as I’m concerned the computer’s USB cable 5V simply shouldn’t be connected to either the external hub’s PSU or the 5V lines on its outputs. What amazed me is that the 5V ‘in’ from the computer is connected to anything in or via the hub. The only exception I could see make sense would be if it lit an LED completely independent of the hub to confirm connection to a powered computer. If the hub has its own PSU then its the job of that to power the hub outlets, and not connect to the 5V wire to the computer.

Having overcome my amazement I guess I should not have been surprised given how sloppy so much of the ‘computer biz’ is. But it seems such a basic point to me. How clever do they have to be to ensure one wire is not connected?!?

I suspect the hub in question does have a diode. It gives the problem with one ‘5V’ PSU but not another. Which also rather gives the game away about the PSUs as well… :-/

How hard is it to remove the 5V pin/tongue on a USB cable or snip the 5V wire? I’ll probably go for an isolator as that will probably help get best audio performance as well. But I can see that most people won’t be that fanatic.

Jim