Linux: USB audio giving back silence on capture

[rogersv]

We have found the development boards (primarily XS1-L1) to be very temperamental when recording audio on Linux.  In general they like to return only silence (ie all zeroes in the PCM data).  The longer they have been in use, the worse the problem gets.  Plugging the exact same board same cable same audio source into a nearby Mac and it works fine for recording.  We also tried a newer dev board and got the same problem.

Under what circumstances would the board return silence even when there is a signal? We are using the various versions of snd_usb_audio in kernels over the last few years.  Note that playback is always fine. The second green led does come on during recording, and USB meter does show 5V/0.18A as expected.  It happens on various ARM boards, as well as regular x86 workstations.  I've even connected the line out straight back into line in while playing audio to the board, just to eliminate more possibilities.

There is considerably more investigation we have done, but cannot find any common factor.  I'm more than happy to give many paragraphs of everything we've tried (power, hubs, disabling usb suspend, USB 2 vs 3 ports, usb bus resets, cpu governors, and the list goes on an on).

Here is an example of how we see silence.  Non xmos devices give lots of non-zero bytes of output.

Code: Select all

$ arecord -L
....
hw:CARD=X20,DEV=0
    XMOS USB Audio 2.0, USB Audio
    Direct hardware device without any conversions
....
$ arecord --device hw:CARD=X20,DEV=0 --duration 10 --channels 2 --rate 44100 -t raw --format S32_LE | hexdump
Recording raw data 'stdin' : Signed 32 bit Little Endian, Rate 44100 Hz, Stereo
0000000 0000 0000 0000 0000 0000 0000 0000 0000
*
035d540

Update: We just got the latest XMOS device, and this pattern still happens.  What makes XMOS pathologically return silence instead of the actual audio on Linux?  We don't have this problem with non-XMOS devices.

Code: Select all

  idVendor           0x20b1 XMOS Ltd
  idProduct          0x000a
  bcdDevice            6.50
  iManufacturer           1
  iProduct                3
  iSerial                 0  

Update 2: Using Debian jessie on Raspberry Pi 2 does work fine. Moving the device over to a AMD64 system running latest Ubuntu, and silence comes back. Going back the Pi worked fine. And then a reboot later, and silence no matter what. Something in the XMOS is extremely temperamental!

[Ross]

What version of the xmos code are you running on the devices? Any USB traces of the issues?

[rogersv]

What version of the xmos code are you running on the devices?

No idea. Generally whatever you shipped them with. We are doing an audio appliance and intend to support any USB Audio Compliant ADC/DAC, in addition to having one inside the box. All other USB audio hardware has been fine.

Any USB traces of the issues?

I just made a capture using wireshark, and have attached it. It doesn't decode the USB audio protocol, but you do see lots of zeroes in the payloads. I started the capture, then inserted the device (17 seconds in), then did a 10 second audio record (31 seconds in), then disconnected (49 seconds in).

This one was brand new just arrived from Digi-key model XK-USB-AUDIO-U8-2C-AB.

BTW this exact same board worked just fine on the exact same computer yesterday. Well the first time I tried it yesterday. Later on in the afternoon it started giving the silent treatment again, with one brief intermission of real data.

It also isn't a hardware failure, as I can move the USB cable over to a mac where it does show the audio capture working fine, and then back to the Linux box and silent treatment. We have found no pattern at all to when the board decides to give silence versus not with Linux across a variety of kernel versions, systems (x86, ARM), power (not relevant for this board), hubs vs direct, USB 2 vs 3 ports etc. Very frustrating.

[rogersv]

Any updates on this issue?