> So, a command like "rtl_fm -f 652.75 -M wbfm -s 600k -r48k - | aplay > -Dplug:default -r 24000 -f S16_LE -c 2 -vv " worked well on my RPi.
This produces an audio signal at a sampling rate of 48kHz, then -D:default converts it to 24kHz, then aplay plays it at 24kHz. You should get the same effect if you change -r48k to -r24k, but with less CPU time spent resampling. Others here have suggested that performing a lot of CPU work while the audio is playing stops the underruns, so effectively what you're doing here is performing a lot of CPU work by asking ALSA to resample the signal from 48k to 24k. It's this "busy CPU" that is preventing the underruns. I think there are two things happening here. One is that something (like power saving or cpufreq control) is causing the processor to miss refilling the buffer in time. I would have expected that the aplay options related to this would help (--avail-min, --period-time, --buffer-time, --period-size, --buffer-size) because power saving isn't really the problem, the problem is that the system doesn't wake up soon enough to avoid underruns (--avail-min seems pretty relevant here.) The second is that no oscillator is perfect, and the RTL stick is using a separate oscillator to the sound card. So while you might be sampling at 48k and playing back at 48k, in reality those two rates don't match up perfectly and sooner or later you are going to either have a buffer underrun, or have to drop samples if you've picked up too many. There would however be a much longer delay between audio glitches caused by this problem. I'd focus on the aplay buffer options as they seem to be the most likely way of avoiding the underruns. Cheers, Adam.
