Poor audio capture with kernel 3.10.25+

[redhawkuk]

I have a Soundblaster Live 24bit external which I'm using for Darkice audio streaming. With 3.6.11+ #474 audio capture was great although levels low due to inability to control Line-in mixer settings (is there a fix for this??). After updating to kernel 3.10+25 audio capture is very distorted and pitch artificially higher due to loss of sample data. For audio recording samples (good audio vs poor audio comparisons) please check - http://www.raspberrypi.org/forums/viewtopic.php?f=66&t=73063 On another related issue my FM radio application for the RTL2832U DVB-T dongle is also unable to capture audio without loss of data Both devices are directly connected to the Pi Model B i.e. without the use of external USB hub.

[popcornmix]

Have you tried: sudo BRANCH=next rpi-update See: http://www.raspberrypi.org/forums/viewtopic.php?f=28&t=70437

[redhawkuk]

Hi, the audio capture problem with my Soundblaster appears to be fixed, however the RTL dongle is still dropping data packets even after enabling the FIQ_FSM driver rewrite. I understand USB has always been problematic on the Pi but I don't understand why a kernel update would make things go from acceptable to really bad??

I also have a few issues with my Soundblaster Live 24bit the main one being the inability to access the Line-In mixer levels despite being able to capture from it. http://www.raspberrypi.org/forums/viewtopic.php?f=45&t=66138 This same problem exists in Linux x86 distros, clearly whoever wrote the driver support didn't do a good job nor did anyone bother to fix it.

Should I raise this as a separate issue here or to another github page?? I would be quite happy to fix this myself if I knew where to start.

[popcornmix]

If a bug also exists in Linux x86, then the problem needs to be reported to upstream linux. E.g. https://www.kernel.org/pub/linux/docs/lkml/reporting-bugs.html

If it is fixed there it will likely come through when we update.

[redhawkuk]

With regards to my Soundblaster problems I've joined the alsa-devel mailing list so hopefully I'll get some answers soon although I am sceptical a fix would be issued (it's quite an old bug).

As for the RTL2832U dongle is there anything I can do to fix the lost packets??

[popcornmix]

This is really a question for @P33M. I'm sure he'll want to know the output of lsusb -v so include that here.

[P33M]

Yes, please do post that.

In addition, can you point me at the source for the program that captures the FM? The realtek devices can be coaxed into raw I/Q sample output mode which produces a LOT of data.

[redhawkuk]

For the software install I followed this page: http://sdr.osmocom.org/trac/wiki/rtl-sdr As for the lsusb -v dump: http://pastebin.com/vmhrhHBP

Richard S.

[hexameron]

rtl-fm captures 1-2M samples/second => usually about 3M bytes, even when down sampling to narrowband, but it certainly seems to break with recent Alsa in a way that OpenMax does not.

[P33M]

I have one of these in my box of random bits.

How are you measuring the data loss from the RTL device?

I see high CPU usage with just using 2835's PCM output (55-60%). What playback route are you using?

[redhawkuk]

For FM playback I use the following command line which basically generates wav audio at 48k sample rate and pipes this to aplay with same playback rate of 48k: rtl_fm -f 88.3e6 -s 260k -r 48k -g 50 -o 1 - | aplay -r 48k -f S16_LE -c 1 -q -V mono -D sysdefault:CARD=ALSA

With the older kernel the audio worked perfectly but with the latest version I'm getting buffer underruns and choppy playback. As I understand buffer underruns can only occur if aplay is processing more audio data than it's receiving. Therefore I can only assume the RTL device is skipping or missing samples, just how much I can't tell but it's quite a lot.

[P33M]

If you write the data to a file, then play it back offline, does it exhibit the same behaviour?

[redhawkuk]

Okay I've tried playing from a saved file and it's much better although I can still hear the occasional glitch in the output (tested on Windows since aplay refused to accept my dump file).

[redhawkuk]

I did another experiment, this time I had Music on Console running in the background streaming a local internet radio station. Now when I capture data from the RTL dongle and save it to a file the result is total garbage and in fact worse than piping this directly to aplay. I guess there's something weird going on when the audio starts playing and even more so with higher network activity.

[P33M]

How long are the glitches in length (time wise)?

Can you post the first lines of output of the rtl_fm program when it's running?

[redhawkuk]

The glitches vary from small to very short there's no consistency to the error pattern. The shortest glitch I've measured was around 800 bytes (or 400 16bit values) while inspecting a 1kHz test tone broadcast. http://i53.photobucket.com/albums/g79/redhawk_000/rtl_1kHz.jpg

As for the rtl_output: root@raspberrypi:~# rtl_fm -f 87.0e6 -s 260k -r 48k -g 50 -o 1 - | aplay -r 48k -f S16_LE -c 1 -q -V mono -D sysdefault:CARD=ALSA Warning: -o is very buggy Found 1 device(s): 0: Realtek, RTL2838UHIDIR, SN: 00000013

Using device 0: Generic RTL2832U OEM Found Rafael Micro R820T tuner Tuner gain set to 49.60 dB. Tuned to 87260000 Hz. Oversampling input by: 4x. Oversampling output by: 1x. Buffer size: 7.88ms Exact sample rate is: 1040000.008265 Hz Sampling at 1040000 S/s. Output at 260000 Hz. ######################+ | 42%underrun!!! (at least 4.479 ms long) ##################### + | 43%underrun!!! (at least 6.971 ms long)

[w9ran]

For clarification, rtl_fm samples the USB dongle at a high rate, but internally decimates and as seen in the example above, resamples the output to 48K, which is what is being piped to aplay. I've evaluated a range of sample rates, but the aplay buffer underruns occur at the same rate regardless, from 48K all the way down to 4K. As noted previously, making the CPU busy (~100%) eliminates the underruns. When ever the CPU is idle, the underruns occur.

A different app (that does not use ALSA) streams raw packets from the RTL dongle at up to 2msps via TCP without a glitch. This seems to contraindicate a USB issue.

[P33M]

What happens if you run rtl_fm at realtime priority?

rtl_fm appears to use three posix threads to do the libusb reads, then the DSP, then the output. If any one of those got preempted for longer than an Alsa buffer time, then you would get underruns.

[redhawkuk]

How exactly do you start a process to run with realtime priority??

I tried renice and chrt but they didn't seem to make any difference.

[redhawkuk]

I've just updated to the latest kernel 3.12.17+ #672 and this has made a big improvement to rtl_fm. I still get the odd skip with background activities such as file access or using my USB keyboard in a program but it's liveable. I'll close this "issue" once I get some feedback from w9ran just in case he's still having trouble.

[w9ran]

Redhawkuk - been busy but just used rpi-update again today and was able to install kernel 3.12.18+ #679 and the buffer underrun problem is FIXED! Thanks to the team for the efforts.