My experience was that several commands / examples I've seen gave me stutters here on a pretty beefy computer. It took playing around and I didn't document everything, but so far what I've got that 'works' stutter-free, although maybe is not so great... but it does work anyways. I know it isn't a rasbpi but it showed me that a lot of times it isn't the hardware causing the stutters.
ron@tripel:~$ rtl_fm -W -f 96.9e6 -W -s 200000 -r 48000 - | aplay -r 48k -f S16_LE -t raw -c 1 Found 1 device(s): 0: Generic, RTL2832U, SN: 77771111153705700
Using device 0: Generic RTL2832U (e.g. hama nano) Found Rafael Micro R820T tuner Oversampling input by: 2x. Oversampling output by: 4x. Buffer size: 5.12ms Tuned to 97315000 Hz. Sampling at 1600000 Hz. Output at 48000 Hz. Tuner gain set to automatic. Playing raw data 'stdin' : Signed 16 bit Little Endian, Rate 48000 Hz, Mono
On Thu, Nov 29, 2012 at 1:28 PM, keenerd keenerd@gmail.com wrote:
On 11/29/12, Pete Zaitcev zaitcev@kotori.zaitcev.us wrote:
But another thing is that rtl_fm just won't work until the signal is strong enough.
Maybe you should try increasing the gain.
Final command line was this: rtl_fm -l 0 -f 99.5e6 -N -s 170e3 -o 4 -A -r 24e3 - | \ aplay -r 24k -f S16_LE -t raw -c 1
Really, much smarter to use -W instead. You are losing a moderate amount of the signal. First, wbfm is slightly off center pushing 10% of the signal out of range. Second, it carries audio information up to 16kHz and resampling at 24ks/s discards another 25%.
rtl_fm -W -f 99.5e6 -g 49 | aplay -r 32k -f S16_LE -t raw -c 1
will work better. No reason to spell it out the long way.
-Kyle