USB Audio Dropouts

[lnicola]

Since the new FIQ work, (31a8f3f12c, actually), the audio on my USB DAC is full of crackles.

dmesg: http://pastebin.com/DVjm57k0
lsusb -v: http://pastebin.com/VPQa17hE
vmstat 2 a while before and during playback: http://pastebin.com/5SqwfwR9
/proc/asound/card0/stream0: http://pastebin.com/r0hQijyD

The stream I'm playing is 16-bit at 44.1 kHz. I've also unbound the HID endpoint of the DAC because it made things better at some point. This issue still occurs even if I keep it.

[ghollingworth]

Have you tried rpi-update since last night (the new fiq_fsm was pushed to the head branch), this should have been fixed already

[lnicola]

Yes, it's the version from the master branch.

[kursusHC]

I have the same issue, both with the recent Master branch and the recent Next.
I'm running Arch up to date with a Hifimediy Sabre USB DAC ES9023 (CMA options disabled).

When I revert to an old Next commit (April 15th), the problem disappears.

[P33M]

I have 3 DACs using different manufacturers of ASIC that do not exhibit this problem.

It would be good to get a minimal set of conditions that cause this to happen. Does this happen with a simple "aplay test.wav" - it would be good to use a sinewave test file or similar:

http://www.audiocheck.net/audiofrequencysignalgenerator_sinetone.php

That webpage will let you generate a sinewave test tone up to 10 seconds long.

Also, is this DAC widely available for purchase in the EU? It would be easier if I just got my hands on one.

[lnicola]

Yes, it happens to me with a raw file (aplay -f cd foo.raw). Do you think it would help if I tried with a sine wave and perhaps send you a recording?

I do have some specific settings: snd-usb-audio.nrpacks=1 and

pcm.!default {
        type hw
        card 0
}

in asound.conf to prevent the sample rate defaulting to 48000 Hz (I don't remember exactly, but I think it's using plug:hw without it).

My DAC is the one from http://www.amazon.co.uk/Behringer-UCA202-U-Control-low-latency-Interface/dp/B000KW2YEI/ , but note that it's a bit finicky: both Windows and the Raspberry Pi tend to hang when I connect it -- or at least they did when I got it. If I keep it connected during boot it's fine, though.

[P33M]

snd_usb_audio.nrpacks now has no effect in 3.12: the URB allocation is now completely automatic.

I have that device (or at least something with the same badge) on my desk. It works fine. It may well be that yours has a different codec inside: I will compare the device I have to see if there are any differences.

Please do send a recording of a sinewave test.

[andrea-iob]

I've the same problem. My DAC is a HRT Music Streamer II+. I've the first version of the DAC (http://www.headfonia.com/hrt-music-streamer-ii-2496-usb-dac) the one they are selling now should have just a different case and a different PCB layout (http://www.hirestech.com/product/?pid=128).

I've the latest revision of the DAC firmware. I've also tried with a firmware version specifically designed for use with NAS and similar lower processing power hosts, but the problem remains.

I hear the noise on all the files I play, also with a sinewave test file.

[lnicola]

Are you sure that change was in 3.12? I thought the argument was actually removed in 3.13: http://www.raspberrypi.org/forums/viewtopic.php?p=541704#p541704 .

It's too bad that the revision in which this issue appeared contained two changes; I suppose one thing to try would be to see which of those is actually causing it.

Regarding the recording, I don't think I have an audio cable to be able to record it properly. Would using a microphone suffice?

[P33M]

My mistake: yes the patch was in the 3.13 release. Even so, altering nrpacks should have no effect since the glitches appear to happen more frequently than the ~10ms URB interval.

If you can get any sort of recording (of a sine test) that is of reasonable quality then it would help.

[andrea-iob]

Looking at the 3.12.18 kernel sources I still see the nrpacks parameter being used (see line 82 of https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tree/sound/usb/card.c?id=refs/tags/v3.12.18).

However I've tried the "ALSA: improve buffer size computations for USB PCM audio" patch, but I didn't notice any improvements.

[lnicola]

It seems that I can't get a decent recording with my laptop microphone :(.

[andrea-iob]

I connected the line out of my hi-fi to the mic in of my notebook. Here is the results: "https://www.dropbox.com/s/mz4wkilqj9xtyur/HRT_Music_streamer_Pi_Noise.wav".

Could it be useful to you?

[lnicola]

Mine sounds about the same. I noticed, however, that the noise is much more audible with a 20 Hz tone. Perhaps andrea-iob could repeat the test using that?

[andrea-iob]

Here is a 20Hz sinewave: "https://www.dropbox.com/s/d6zv4m4jsq9e0mt/HRT_Music_streamer_Pi_Noise_20Hz.wav".

[lnicola]

Of course I have a cable, from my DAC to the amplifier. Sorry for the high volume, I can't seem to figure out how to reduce it.

Oh, my: http://i.imgur.com/EGYSFQz.png . Download link: https://www.wetransfer.com/downloads/a1d630b523384d2181aabfdf536afbaa20140429204918/2176f0f73803024943fe56222cd6cd1b20140429204918/e97241

[P33M]

(ಠ_ಠ)

Well that puts paid to any theories I have about what's causing this.

If it were reads off the end of the bounce buffers, I would expect there to be a constant value transmitted (the buffers are rewritten with 0x6B on transaction completion). This isn't happening - in fact it appears that random corruption is happening at random times.

[lnicola]

Sorry, please consider the file above invalid. I had a "monitor" switch on, which supposedly mixes together the analog and the USB input; weird thing is, recording didn't work without the analog input, even with the switch on.

Anyway, that takes care of the clipping issue. I've also switched to mono recording to take that out of the picture. The waveform still looks bad, though.

Here is a new set: http://i.imgur.com/eckeYK5.png https://www.dropbox.com/s/qt6wlm34uafu9gu/quux.flac .

[ski522]

I just upgraded my Pi and my USB PCM2704 is exhibiting similar symptons. To temporarily resolve the issue I lowered my USB ports speed down by adding the "dwc_otg.speed=1" Not ideal as I use my Pi as a NAS, but works for now. My post about the problem is at the Pi Forum http://www.raspberrypi.org/forums/viewtopic.php?f=63&t=76026&p=543139#p543139

[lnicola]

You mention a constant value being transmitted on overruns. However, my source is 16-bit. Is the transfer size a multiple of the sample size? I wonder if the corruption could happen in the middle of a frame or sample.

Now this sounds fun..

- /* Bugette: for some reason, memcpy corrupts the data in the bounce buffers. May be a
-  * cache coherency issue */

[kursusHC]

The device is lost after a few minutes of playback/forward/volume change (just like it was before the huge work on FIQ drivers). But unlike @GrayShade it runs perfectly on all my linux desktops.

I've tried "dwc_otg.speed=1" but it prevents ALSA from detecting my DAC.

Can we provide something to help ?

[giddyhup]

I am also running into this and probably related problems. I updated about twelve hours ago. USB sound is crackling, transferring data via WIFI (samba) times out. I get NYET messages related to my bluetooth dongle.

I updated because I hoped my SDR solution (based on a DVB-T USB stick) would improve, but everything has become worse. I will revert to my backup I created before the update.

lsusb -v http://pastebin.com/LRcq8xva
dmesg (up until WIFI related samba errors) http://pastebin.com/y21Skth5

[P33M]

dwc_otg.speed=1 should not be required.

It should be sufficient to disable the FSM: put dwc_otg.fiq_fsm_enable=0 into /boot/cmdline.txt

@ALL:
How many of you are running overclocked?

[lnicola]

I recently overclocked my Pi, however the issue also occurs when running at the normal clock rate.

[giddyhup]

I run overclocked. I now disabled the FSM. Sound is back to normal and samba/WIFI throughput is better/without errors. I don't need to revert to my old image after all.

[ski522]

Yes dwc_otg.fiq_fsm_enable=0 seemed to fix the problem as well for me.

I am overclocking my Pi at 900MHz.

[P33M]

I can replicate this with an overclock.

Edit: I can also replicate this without an overclock.

[andrea-iob]

My Pi is not overclocked.

Disabling the FSM does not fix the problem: with some files I still hear some random pops, with other files I hear only noise. The files that with FSM disabled are completely broken are 16/44 files that, for some reasons I don't understand, are played as S24_3LE.

As reported in the FIQ_FSM forum thread, before the kernel upgrade the files played as S24_3LE were working good whereas the files played as S16_LE where distorted (there were NYET errors). After the kernel upgrade I hear noise on all the files I play.

[P33M]

You will get unreliable playback with the FSM disabled. Interrupt latency will mess up audio transfers from time to time. 24-bit audio is particularly vulnerable as you may get what is effectively an endian swap (and thus everything turns into noise) if you lose a frame of data.

[amtssp]

Hi I have the same problem (using 3.14.1 kernel) constant crackling noise in my USB audio out.
But If I add dwc_otg.fiq_fsm_mask=0x1 to the cmdline file - the USB-audio is playing without problems.

If I add dwc_otg.fiq_fsm_mask=0x3 ....... I get the crackling noise
If I add dwc_otg.fiq_fsm_mask=0x7 ........I get the crackling noise

My USB adapter is:
[ 4.746893] usb 1-1.2: new full-speed USB device number 4 using dwc_otg
[ 4.849367] usb 1-1.2: New USB device found, idVendor=0d8c, idProduct=000c
[ 4.849403] usb 1-1.2: New USB device strings: Mfr=0, Product=1, SerialNumber=0
[ 4.849421] usb 1-1.2: Product: C-Media USB Headphone Set
[ 4.862167] input: C-Media USB Headphone Set as /devices/platform/bcm2708_usb/usb1/1-1/1-1.2/1-1.2:1.3/0003:0D8C:000C.0001/input/input0
[ 4.862840] hid-generic 0003:0D8C:000C.0001: input,hidraw0: USB HID v1.00 Device [C-Media USB Headphone Set ] on usb-bcm2708_usb-1.2/input3

And the new fiq-fsm is enabled:
[ 3.522091] OTG VER PARAM: 0, OTG VER FLAG: 0
[ 3.522109] Dedicated Tx FIFOs mode
[ 3.522357] WARN::dwc_otg_hcd_init:1040: FIQ DMA bounce buffers: virt = 0xdcc27000 dma = 0x5ab94000 len=9024
[ 3.522391] FIQ FSM acceleration enabled for :
[ 3.522391] Non-periodic Split Transactions
[ 3.522411] dwc_otg: Microframe scheduler enabled
[ 3.522452] WARN::hcd_init:473: FIQ at 0xc03329d0
[ 3.522469] WARN::hcd_init:474: FIQ ASM at 0xc0332c4c length 36
...
[ 3.524484] dwc_otg: FIQ enabled
[ 3.524502] dwc_otg: NAK holdoff enabled
[ 3.524512] dwc_otg: FIQ split-transaction FSM enabled

Hope this info is helpfull

[popcornmix]

@P33M Does this reduce usable memory to linux by 16M?
Have you tried:
CONFIG_CMA_SIZE_MBYTES=8
(or 4 or 2 or 1?)

[lnicola]

Did anything related to CMA change in 3.12? I had to remove my CMA options from config.txt to be able to boot.

I'll test it when the new binaries come out.

[popcornmix]

CONFIG_DMA_CMA=y seems to enable other disabled CMA config options, so it's possible adding this will make CMA work.

[P33M]

CMA is already enabled (or at least the reservation happens) - therefore 16M is reserved on boot anyway.

Edit: by changing cma=xM in /boot/cmdline.txt, the minimum to boot is 5M.

[lnicola]

20 Hz wave looks good. I'll try listening to something a bit later, but I think I'll leave this issue open until @andrea-iob or someone else gets to test it. Any ideas on why some people never had this issue?

Anyway, thanks for your work!

EDIT: Streaming over the network seems to work fine too.

I suppose the memory fragmentation problem reported by milhouse at the beginning of the FIQ_FSM rewrite testing thread will remain, right?

[P33M]

Memory fragmentation is orthogonal to this issue. It will always happen with a buddy allocator, and is only a "Problem" because the ARM has to do a relatively large amount of work if it wants to shift pages around to reclaim a contiguous area of memory. The net effect is lowered throughput and higher CPU load with some workloads that particularly fragment memory.

The coherency issue disappears if you get sufficient cache activity such that in the 125uS between a transaction being queued, and the hardware executing it, that all the affected cache lines are written out into main memory. You can make the issue go away by having the Pi do "other stuff" at the same time as playback.

[andrea-iob]

No more noise, pops or clicks. The issue seems fixed for me.

Thanks a lot! I really appreciate your hard work!

[amtssp]

Also fixed for me after building a new kernel 3.14.1 and update firmware. USB audio is good now.

Thank you..

[kursusHC]

Same here after a simple rpi-update. Thanks a lot, I can finally enjoy my Pi !!

[lnicola]

Seems fixed, then.

[ski522]

Yup...PCM2704 USB DAC is back to normal...thank you for the prompt fix!!

[giddyhup]

The recent update from May 1 initially looked like an improvement. Even my USB connected DPF became stable. Yet, with my USB sound dongle some sounds sounded odd or wouldn't play at all. dmesg showed some NYET messages related to the sound card, I had to disable the driver again.

[  141.005422] Transfer to device 7 endpoint 0x1 frame 1150 failed - FIQ reported NYET. Data may have been lost.
[  141.325427] Transfer to device 7 endpoint 0x1 frame 1470 failed - FIQ reported NYET. Data may have been lost.