USB Audio setting sample rate broken

[naxxfish]

At some point between the firmware shipped with 2013-05-25-wheezy-raspbian and the current head (i.e. after running rpi-update), something is preventing the successful setting of the sample-rate of my PCM2902 based USB audio device.

lsusb snippet

 Bus 001 Device 005: ID 08bb:2902 Texas Instruments Japan PCM2902 Audio Codec

lsusb -v https://gist.github.com/naxxfish/6062180

Using gstreamer as a client, running this:

gst-launch-0.10 alsasrc device="hw:1" ! 'audio/x-raw-int, channels=2, rate=44100' !  alsasink device="hw:1"

Results in:

pi@festinode ~ $ cat /proc/asound/card1/pcm0c/sub0/hw_params
access: RW_INTERLEAVED
format: S16_LE
subformat: STD
channels: 2
rate: 44100 (44100/1)
period_size: 441
buffer_size: 8820

However, the audio is actually only being sampled at 32kHz (verified by looking at a recorded wav file created using filesink) - therefore further processing of the audio is causing it to be pitched up and distorted with frequent gapping, due to the misrepresentation of the sample rate.

Running

gst-launch-0.10 alsasrc device="hw:1" ! 'audio/x-raw-int, channels=2, rate=32000' !  alsasink device="hw:1"

Produces correct audio.

The older firmware version as in the stock wheezy image does not exhibit this issue.

Forum topic:
http://www.raspberrypi.org/phpBB3/viewtopic.php?f=28&t=50589&sid=c528ca3d4420e5fca78143f94c06113a

[popcornmix]

It's hard to imagine this being caused by anything in firmware or kernel.

P33M, could this be a usb issue?

[naxxfish]

I also find it hard to imagine... but it's totally reproducible and as far as I can tell the only change is the firmware (or, at least, something updated by rpi-update).

Config:
Model B
Have the sound card plugged in to USB.
Put some tone or something into the inputs to test the recording

Verify
arecord -D hw:1 -d 5 -c 2 -r 44100 > 44ktest.wav
arecord -D hw:1 -d 5 -c 2 -r 48000 > 48ktest.wav
arecord -D hw:1 -d 5 -c 2 -r 32000 > 32ktest.wav

Works:
Clean image a SD card with 2013-05-25-wheezy-raspbian, defaults for everything. There are still clicks and pops, but that's probably related to the USB issue.

Break:
Run rpi-update and reboot, repeat the verification above - find that the wav files are now at the wrong pitch.

[popcornmix]

If you look here:
https://github.com/Hexxeh/rpi-firmware/commits/master

you should see all the firmware updates.

You shoud be able to run:
sudo rpi-update

where hash is fcc46f1c9aad95e28fd254f5153764fb47d68cf7 for "linux: rebuild with sdcard timeout increased" on July 11th.

to get back to an older firmware. If you can track down the commit that broke sampling rate, then we'd have a better idea of the cause.

[naxxfish]

Ok, I'll start at that commit and work forwards/backwards until it breaks.

There's quite a few commits between now and 25th May, I really hope I don't have to go in that direction!

[asb]

Chris, you want to perform a rough binary search:
http://en.wikipedia.org/wiki/Binary_search_algorithm

[naxxfish]

I thought a bogo-search might have been better ;)

I don't have anything to feed the inputs just now (trains are not known for their availability of line level sources and RCA cables, not even the high speed ones) - so will have to continue the quest to find the commit later.

However I have noticed that going back to fcc46f1c9aad95e28fd254f5153764fb47d68cf7 did cause my USB device to emit lots of stuff to dmesg on capture

fcc46f1c9aad95e28fd254f5153764fb47d68cf7
[  341.684023] delay: estimated 0, actual 89
[  341.694026] delay: estimated 0, actual 89
[  341.704025] delay: estimated 0, actual 89
[  341.714028] delay: estimated 0, actual 89
[  341.724027] delay: estimated 0, actual 89
[  341.734030] delay: estimated 0, actual 89
[  341.744032] delay: estimated 0, actual 89
[  341.754036] delay: estimated 0, actual 89
[  341.764039] delay: estimated 0, actual 89
[  341.774415] delay: estimated 0, actual 89
[  341.784054] delay: estimated 0, actual 89
[  341.794043] delay: estimated 0, actual 89
[  341.804042] delay: estimated 0, actual 89
[  341.814045] delay: estimated 0, actual 89
[  341.824045] delay: estimated 0, actual 89
[  341.834043] delay: estimated 0, actual 89
[  341.844046] delay: estimated 0, actual 89
[  341.854045] delay: estimated 0, actual 89
[  341.864050] delay: estimated 0, actual 89
[  341.874046] delay: estimated 0, actual 89
[  341.884427] delay: estimated 0, actual 89
[  341.894045] delay: estimated 0, actual 89
[  341.904052] delay: estimated 0, actual 89
[  341.914058] delay: estimated 0, actual 89
[  341.924058] delay: estimated 0, actual 89
[  341.934057] delay: estimated 0, actual 89
[  342.434999] retire_capture_urb: 5000 callbacks suppressed

[naxxfish]

I think I've tracked it down.

The first revision to cause issues is 44dc4f093c9ec075e6704965665311a94f6371aa . All the ones before this have the clicking, but at least the sample rate is right.

[P33M]

To be clear, is the only time you are seeing the distorted sample rate when you are recording audio?

[naxxfish]

That is correct - it's just capture that has this issue.

If you're playing back and capturing at the same time, it gets considerably weirder sounding. For example:

gst-launch-0.10 -v alsasrc ! 'audio/x-raw-int, channels=2, rate=48000, depth=16' ! alsasink

Playback works fine, regardless of the samplerate of the source file - no clicks or pops either.

[P33M]

I've reproduced this issue with playback at least, not tested record yet.. It's with the way fiq_split now uses exclusive access to each TT. Before fiq_split, the driver used to do both start and completes of split transactions out of order, especially in the case of a missed complete, which caused problems with repeated keypresses etc. Fiq_split now enforces that these are done one at a time to prevent packet loss, which is critical for keyboard interaction.

If you are sourcing audio from the device then a split-isoc IN can take up to 5 microframes to complete. If we did a 3-microframe interrupt IN transfer in the same frame (due to the HID endpoint) then we will run out of time to complete the transaction which means we never ask for data from the audio device.

What this and other usb audio devices tend to do here is one of two things

• let buffers underflow/overflow which gives crackles in audio
• switch down to a lower sample rate on detecting under/overflow for sink/source.

The reason the audio then works fine at 32kHz is because you drop down to a single split-complete of <188 bytes which then takes just 3 microframes. This and the occasional HID endpoint will fit with the current allocation requirement.

A workaround could be to clobber the HID endpoint or blacklist the device ID so that usbhid doesn't pick it up.

It is still possible to get glitches in playback if you have high interrupt loading from elsewhere (ethernet or mass storage) - we miss scheduling isoc OUTs in a timely fashion which causes hubs to drop packets.

Duplex audio is probably never going to work - unless you use sample rates <32kHz for both in and out.

[naxxfish]

Okay - that makes sense. It also explains why the pitch in the sound
wobbles over time rather than always being pitched up by the same amount.

Can I blacklist the device myself, and if so, what method would be
recommended?

Also, given for my current project I have no keyboards attached, can I
disable this functionality? Will it cause issues for other devices?
On Jul 23, 2013 11:46 PM, "P33M" notifications@github.com wrote:

I've reproduced this issue with playback at least, not tested record yet..
It's with the way fiq_split now uses exclusive access to each TT. Before
fiq_split, the driver used to do both start and completes of split
transactions out of order, especially in the case of a missed complete,
which caused problems with repeated keypresses etc. Fiq_split now enforces
that these are done one at a time to prevent packet loss, which is critical
for keyboard interaction.

If you are sourcing audio from the device then a split-isoc IN can take up
to 5 microframes to complete. If we did a 3-microframe interrupt IN
transfer (due to the HID endpoint) then we will run out of time to complete
the transaction which means we never ask for data from the audio device.

What this and other usb audio devices tend to do here is one of two things

• let buffers underflow/overflow which gives crackles in audio
• switch down to a lower sample rate on detecting under/overflow for
  sink/source.

The reason the audio then works fine at 32kHz is because you drop down to
a single split-complete of <188 bytes which then takes just 3 microframes.
This and the occasional HID endpoint will fit with the current allocation
requirement.

A workaround could be to clobber the HID endpoint or blacklist the device
ID so that usbhid doesn't pick it up.

It is still possible to get glitches in playback if you have high
interrupt loading from elsewhere (ethernet or mass storage) - we miss
scheduling isoc OUTs in a timely fashion which causes hubs to drop packets.

Duplex audio is probably never going to work - unless you use sample rates
<32kHz for both in and out.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/197#issuecomment-21451900
.

[P33M]

I've just put the analyzer on the very same device and there is a bug with the fiq_split for multi-complete INs.

We currently can only do a single-packet isoc IN transaction which in theory would limit us to 44.1k 16-bit but in practice the hub will only return 172 of the the 176 bytes (because we are so close to the actual end of the data, the hub will keep some bytes behind to ensure it doesn't accidentally munge the full-speed CRC at the end of the packet into the high-speed data).

32k 16bit record is all we can manage for now.

To test with disabling the HID endpoint, which may help with crackling playback, you can do

# dmesg | grep input
[    5.405276] input: Dell Dell Multimedia Pro Keyboard as /devices/platform/bcm2708_usb/usb1/1-1/1-1.3/1-1.3.1/1-1.3.1:1.0/input/input2
[    5.436712] hid-generic 0003:413C:2011.0003: input,hidraw2: USB HID v1.10 Keyboard [Dell Dell Multimedia Pro Keyboard] on usb-bcm2708_usb-1.3.1/input0
[    5.495064] input: Dell Dell Multimedia Pro Keyboard as /devices/platform/bcm2708_usb/usb1/1-1/1-1.3/1-1.3.1/1-1.3.1:1.1/input/input3
[    5.537529] hid-generic 0003:413C:2011.0004: input,hidraw3: USB HID v1.10 Device [Dell Dell Multimedia Pro Keyboard] on usb-bcm2708_usb-1.3.1/input1
[ 1626.411656] input: Burr-Brown from TI               USB Audio CODEC  as /devices/platform/bcm2708_usb/usb1/1-1/1-1.5/1-1.5:1.3/input/input4
[ 1626.417893] hid-generic 0003:08BB:2902.0005: input,hidraw1: USB HID v1.00 Device [Burr-Brown from TI               USB Audio CODEC ] on usb-bcm2708_usb-1.5/input3
# cd /sys/bus/usb/drivers/usbhid
echo -n "1-1.5:1.3" > unbind

This is a one-time-only unbind - reboot or replug will cause USBhid to rebind to it. I tried with remove_id which should dynamically remove the audio device's id from the support table, but I think usbhid is just the default for any HID device and thus doesn't have the ID.

The kernel from rpi-update is built with usbhid integrated so you can't disable it via /etc/modprobe.d/*. You could rebuild it yourself from source with hid as a module.

[popcornmix]

Can you test with
sudo BRANCH=next rpi-update
firmware?
See here for info:
http://www.raspberrypi.org/forum/viewtopic.php?f=28&t=70437

[es314159]

I think I am having the same problem described in this thread. I recently installed a usb sound card with C-Media chipset (Audio-Technica ATR2USB). Playback is fine, but recording seems to record at a lower sampling rate than the specified 48K or 44.1K or whatever I specify. Play back is higher freq and distorted. Is there a fix for this?
-Thanks

[P33M]

This issue is no longer present in the fiq_fsm rewrite.

Stereo capture at up to 48kHz should work fine, even in duplex with playback to the same device.