3.10.12 USB Audio Pops

[lnicola]

Even with fiq_split_enable=0, I'm getting pops and cracks when using an USB DAC. Strangely, these seem to happen even when the playback is paused. The noise gets much worse when the SD card is in use and the volume does not change when I change the PCM playback volume.

These seem to have started in Hexxeh/rpi-firmware@cc44f66 .

[P33M]

Can you do a git-bisect on the firmware commits to confirm this? I.e. which specific version broke things.

[lnicola]

I'm afraid not: I can't compile my own kernel, so I have to resort to the pre-compiled binaries.

[P33M]

If you do it on the hexxeh firmware repository, you can do sudo rpi-update commit where commit is the full git hash.

[lnicola]

The commit I gave is the first one where I encountered that problem; the one before (Hexxeh/rpi-firmware@59964e0) works, but I suppose a lot of stuff changed between 3.9.11 and 3.10.12.

[P33M]

Can you post a full lsusb -v and dmesg of boot?

[lnicola]

Sure. This is with the working version: dmesg (http://pastebin.com/JX4SH2yk) and lsusb (http://pastebin.com/D3TgD0ap).

Should I also post them for the kernel where I'm having issues?

[lnicola]

A note: the issue manifests quite clearly when running at the last stage of rpi-update, when the files are copied from the git repository clone to the proper place on the fs.

Reading files from the card is less likely to cause it, as is writing to a single file (possibly due to buffering?) and running find /. I didn't try to create a lot of folders or move files around, but I suppose changing metadata leads to a lot of SD card writes.

[P33M]

Audio pops are a known issue when using USB audio DACs. SD card access and ethernet activity are known causal factors for increasing the amount of dropout. See #351.

Is the performance of your audio DAC significantly worse with no other system activity under 3.10 compared with 3.6? I would suggest running from command line only as xwindows has a non-trivial amount of useage.

[lnicola]

I encountered the issue with the kernel on the master branch on a lightly loaded system (running headless). When this happened, I turned off everything except sshd and it stayed the same.

What I can say is that on my light load, the behavior is much worse on 3.10 compared to 3.6. On 3.6 with fiq_split_enable=0 I never encountered this issue, while on 3.10 I'm sometimes getting these noise bursts once a few seconds.

Am I wrong to assume that when playback is paused no data is sent to the DAC? Changing the ALSA volume doesn't have any effect and these are more like interference than dropouts.

EDIT: I suspect that the volume is actually changed in software, so my point about that is probably meaningless.

[P33M]

If you are paused, then the ALSA stream is usually still open. In theory, zero-value samples are still being sent to the DAC.

If the DAC subsequently gets garbled or missing packets, then the behaviour is undefined. Normally the output will go to negative full scale.

I've actually got one of these

Bus 001 Device 008: ID 08bb:2902 Texas Instruments Japan PCM2902 Audio Codec
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               1.10
  bDeviceClass            0 (Defined at Interface level)
  bDeviceSubClass         0
  bDeviceProtocol         0
  bMaxPacketSize0         8
  idVendor           0x08bb Texas Instruments Japan
  idProduct          0x2902 PCM2902 Audio Codec
  bcdDevice            1.00
  iManufacturer           1
  iProduct                2
  iSerial                 0

but I can't reproduce the issue. It's a Behringer badged codec though.

[lnicola]

Mine is a Behringer UCA-202. I have an app that opens the ALSA device, then I make it pause it; I suppose you can test with aplay and a file on the SD card. While it's playing, try to run rpi-update and wait for the files to be copied to disk.

[lnicola]

It seems that this is no longer happening in Hexxeh/rpi-firmware@2ef601a .