Like I suspect others, I joined this list in hopes of getting some advice with a problem that has thus far eluded me. I'm not an ALSA expert by any means, nor a programmer, but I consider myself a decent troubleshooter, and thought that by sharing what I've done it may trigger some ideas from those who have more knowledge and experience on how to isolate the root cause. The platform is a Raspberry Pi, and I'm aware it has limitations, However, this problem has only popped up after a recent upgrade/update, so I suspect it's due to something that has been changed in the OS or kernel. I'm a ham radio operator, and use aplay to play audio from a simple software defined radio app called rtl_fm that uses a cheap DVB-T dongle as a wide band radio receiver. (If we can get this figured out, I'll be happy to explain lots of cool things that can be done with it) Previously, audio would play smoothly using a command line like the following: $> rtl_fm -f 89.1M -M wbfm | aplay -r 32k -t raw -c 1 -f S16_LE (this tunes the radio to 89.1 Mhz, selected wideband FM mode, and pipes the 32k bps mono audio to aplay) For the last year or more, the above worked perfectly, but after a recent upgrade/update of the Pi, audio is now being interrupted at a once-per-second rate, no matter what parameters are selected. Since the radio app works fine on another Xubuntu machine, I first set out to determine if aplay was working correctly. I'm learning as I go about ALSA, using this explanation for how frames and buffers work: http://www.alsa-project.org/main/index.php/FramesPeriods Changing these parameters does affect the time between underruns, for example making the buffer really big produces several seconds worth of audio before the underrun occurs, but it still happens - just on a different schedule. Here's another example that I used to verify that aplay is working right: Sampling was set to 8K, mono, which equals a frame size of 2 bytes For continuous play, rtl_fm thus has to deliver 8000 frames per second = 16,000 bytes per second. (which seems trivial since the dongle can stream 2 mbps of raw data) Using the verbose mode of aplay, with default settings: Buffer size is set to 4000. According to man: Buffer duration is # frames If no buffer time and no buffer size is given then the maximal allowed buffer time but not more than 500ms is set) 4000 = 1/2 sec of audio Period size is set to 1000. According to man: Distance between interrupts is # frames If no period size and no period time is given then a quarter of the buffer size is set) My understanding of this is that will interrupt every 1000 frames. Period time is set to 125000. According to man: Distance between interrupts is # microseconds. If no period time and no period size is given then a quarter of the buffer time is set.) Just another way of saying it will interrupt 8 times per second. Given this -- I'm doubting that this issue is related to aplay at all. Aplay seems to be working exactly like it's supposed to. Yet the audio is interrupted on a one second interval. If I change the sample rate in rtl_fm from 8K to 32K, the buffer and period size increase by a factor of 4 but the period time remains at 125000 us. In other words, rtl_fm has to deliver 4 times as much data in the same 1/8 second, and yet the rate at which the audio is being interrupted remains the same. Based on the above, the audio interruptions are unrelated to aplay and rtl_fm, in my opinion. If rtl_fm just wasn't able to deliver enough data to keep the buffer full, one would expect the problem to get worse at higher sample rates, right? And here's the kicker: running the radio app with aplay typically requires only 15-20% of the Raspberry Pi's CPU, and the 1/sec audio interruptions consistently occur. But if I run another task at the same time that ties up the CPU most of the time, the audio streams perfectly without interruption. It's only when the CPU doesn't have as much to do that the audio becomes choppy. This might suggest some kind of shift to a low-power mode or something that messes up the buffer, but that doesn't happen when the CPU is busy. I'm probably back to something in the hardware or OS, but it would be very much appreciated if my thinking were verified by someone with more knowledge of ALSA, so that I keep focused on the right area to find the root cause. And any ideas about the relationship with CPU utilization would be really great. Thanks in advance, Bob W9RAN ------------------------------------------------------------------------------ _______________________________________________ Alsa-user mailing list Alsa-user@xxxxxxxxxxxxxxxxxxxxx https://lists.sourceforge.net/lists/listinfo/alsa-user
