I originally posted this question on VLC forum:
Playing RTL-SDR radio through VLC - The VideoLAN Forums
Hopefully this diyAudio forum will be more helpful.
I'm trying to add support for RTL-SDR radio to the Peppy player and facing the issue with playing the FM radio stream through VLC player.
The idea is to connect three different programs through anonymous pipes. The first program (rtl_fm) will send output to STDOUT. The second program (redsea) will recieve that stream at STDIN, will make some processing and send the result of processing to the STDERR and echo the input to STDOUT. And finally the third program (vlc) will get stream from STDIN and send it to ALSA for playback.
The flow (without program options) will look like this:
rtl_fm | redsea | cvlc
rtl_fm - decodes FM radio signal recieved by RTL-SDR USB dongle
redsea - fetches RDS messages (e.g. artist name, song name etc) from FM signal
cvlc - command line version of VLC used for audio playback
VLC has option "-" which allows the program to read audio/video stream from STDIN
The problem is that there is no sound if I use it like this: 'cvlc -'
The whole syntax looks like this:
rtl_fm -M fm -l 0 -A std -p 0 -s 171k -g 20 -F 9 -f 97.3M | redsea -e | cvlc -
But if I use 'aplay' instead of 'vlc' it works fine:
rtl_fm -M fm -l 0 -A std -p 0 -s 171k -g 20 -F 9 -f 97.3M | redsea -e | aplay -r 171000 -f S16_LE
It looks like VLC cannot automatically detect the format of the input stream. But 'aplay' works because I define the signal sample rate and format manually. In case of VLC there are the following error messages in the console:
[mp3 @ 0x73836cf0] Header missing
....
I couldn't find a way to specify signal format for VLC input stream. There are only settings for output stream.
I highly appreciate any help.
Playing RTL-SDR radio through VLC - The VideoLAN Forums
Hopefully this diyAudio forum will be more helpful.
I'm trying to add support for RTL-SDR radio to the Peppy player and facing the issue with playing the FM radio stream through VLC player.
The idea is to connect three different programs through anonymous pipes. The first program (rtl_fm) will send output to STDOUT. The second program (redsea) will recieve that stream at STDIN, will make some processing and send the result of processing to the STDERR and echo the input to STDOUT. And finally the third program (vlc) will get stream from STDIN and send it to ALSA for playback.
The flow (without program options) will look like this:
rtl_fm | redsea | cvlc
rtl_fm - decodes FM radio signal recieved by RTL-SDR USB dongle
redsea - fetches RDS messages (e.g. artist name, song name etc) from FM signal
cvlc - command line version of VLC used for audio playback
VLC has option "-" which allows the program to read audio/video stream from STDIN
The problem is that there is no sound if I use it like this: 'cvlc -'
The whole syntax looks like this:
rtl_fm -M fm -l 0 -A std -p 0 -s 171k -g 20 -F 9 -f 97.3M | redsea -e | cvlc -
But if I use 'aplay' instead of 'vlc' it works fine:
rtl_fm -M fm -l 0 -A std -p 0 -s 171k -g 20 -F 9 -f 97.3M | redsea -e | aplay -r 171000 -f S16_LE
It looks like VLC cannot automatically detect the format of the input stream. But 'aplay' works because I define the signal sample rate and format manually. In case of VLC there are the following error messages in the console:
[mp3 @ 0x73836cf0] Header missing
....
I couldn't find a way to specify signal format for VLC input stream. There are only settings for output stream.
I highly appreciate any help.
IMO the problem is redsea does not output any audio format, just raw stream. Whereas aplay can work with it (I would suggest specifying the remaining params (-c 1 -t raw) so that defaults are not relied on), cvlc assumes some real audio format which it does not detect - Header missing.
Why do you need cvlc? E.g. aplay, sox can pass the incoming raw stream to alsa devices correctly. VLC is a huge software, rather complicated to configure in detail.
Why do you need cvlc? E.g. aplay, sox can pass the incoming raw stream to alsa devices correctly. VLC is a huge software, rather complicated to configure in detail.
I use vlc as the default audio player in Peppy. You can also choose mpd or mplayer just defining that in the config file if you want. Therefore it would be better to stay with vlc for all use cases rather than switching between players and implementing a wrapper for a new player. Why vlc? Mostly because it can play everything (has all required codecs) and has the most efficient way to control it - Python bindings and has support for video which I probably will be using in the future 
You are right, the stream is the raw stream. Maybe there is a way to define that for vlc (?)
You are right, the stream is the raw stream. Maybe there is a way to define that for vlc (?)
One alternative might be to use RTP+SDP. VLC and ffmpeg can transcode/receive RTP streams. There is the same problem, that RTP needs additional info about what is being streamed, and this is where SDP comes in. It's just a small file (text only) that contains a couple of fields about the stream. The RTP RX app must "know" about it, and typically you can specify where that info is located.
The idea is that you stream the RTP to a port on the localhost. I suggest using the port number 16384, which is reserved for UDP/TCP already, and the next few port numbers above that if you need alternatives. Then the RX app is pointed at the local port. Since it is local, there is no transmission delay or packet loss. This is something that I might try myself to send audio data between Windows and the Windows Subsystem for Linux, since the latter has no audio capability (yet).
In the past I tried streaming over my LAN using ffmpeg and VLC, and I knew ahead of time the filepath to which I would write the SDP file. I could then point the stream RX app to it. Worked great. You might give it a try instead of pipes, which have inherent latency issues in my experience. Yes, I tried that too, to send audio from one application to another on the same machine. It's not good.
P.S.
I found a couple of files containing notes I wrote myself a couple of years ago on the above concepts. I was streaming from one machine to a Raspberry Pi. They might be helpful if you want to try it out.
The idea is that you stream the RTP to a port on the localhost. I suggest using the port number 16384, which is reserved for UDP/TCP already, and the next few port numbers above that if you need alternatives. Then the RX app is pointed at the local port. Since it is local, there is no transmission delay or packet loss. This is something that I might try myself to send audio data between Windows and the Windows Subsystem for Linux, since the latter has no audio capability (yet).
In the past I tried streaming over my LAN using ffmpeg and VLC, and I knew ahead of time the filepath to which I would write the SDP file. I could then point the stream RX app to it. Worked great. You might give it a try instead of pipes, which have inherent latency issues in my experience. Yes, I tried that too, to send audio from one application to another on the same machine. It's not good.
P.S.
I found a couple of files containing notes I wrote myself a couple of years ago on the above concepts. I was streaming from one machine to a Raspberry Pi. They might be helpful if you want to try it out.
Last edited:
Charlie, I think rpi wants to listen to FM radio while displaying RDS info (hence the redsea decoder)
rpi: Raw - VideoLAN Wiki , first line of code in VLC package with mp3 encoding support - Raspberry Pi Forums , VLC command-line help - VideoLAN Wiki - section Raw Audio Demuxer
rpi: Raw - VideoLAN Wiki , first line of code in VLC package with mp3 encoding support - Raspberry Pi Forums , VLC command-line help - VideoLAN Wiki - section Raw Audio Demuxer
CharlieLaub, you are right saying that pipes add some latency. Streaming in general adds some lag to the system. I think adding more links to the chain like transcoding and streaming to the port (even on localhost) overcomplicates the system. Anyway, thank you for another twist/solution
phofman, yes the idea is to get local FM radio stream, fetch artist name and song name from that stream using the 'redsea' then display the album art and lyrics for that song in Peppy player. I'm doing that right now for the Internet radio and want to do the same for FM radio. Thanks a lot for the links! I hope that's exactly what I need. I will verify that in the evening (PST) and let you know.
phofman, yes the idea is to get local FM radio stream, fetch artist name and song name from that stream using the 'redsea' then display the album art and lyrics for that song in Peppy player. I'm doing that right now for the Internet radio and want to do the same for FM radio. Thanks a lot for the links! I hope that's exactly what I need. I will verify that in the evening (PST) and let you know.
Last edited:
Here are the cvlc parameters which make it working with raw input stream:
rtl_fm -M fm -l 0 -A std -p 0 -s 171k -g 20 -F 9 -f 97.3M | redsea -e | cvlc --demux=rawaud --rawaud-channels=1 --rawaud-samplerate=171000 --rawaud-fourcc=s16l -
The dash in the end can be replaced either by stream:///dev/stdin or fd://0
Thank you phofman!
rtl_fm -M fm -l 0 -A std -p 0 -s 171k -g 20 -F 9 -f 97.3M | redsea -e | cvlc --demux=rawaud --rawaud-channels=1 --rawaud-samplerate=171000 --rawaud-fourcc=s16l -
The dash in the end can be replaced either by stream:///dev/stdin or fd://0
Thank you phofman!
phofman, the idea to use RTL-SDR with Raspberry Pi is relatively old. For example here is the tutorial from Adafruit dated by 2014:
Overview | Freq Show: Raspberry Pi RTL-SDR Scanner | Adafruit Learning System
But almost everyone was focused on a spectrum analyzer UI related to RTL-SDR. That's understandable - it looks almost like rocket science
Just remember that the usage of the RTL-SDR is not legal in some countries because besides FM radio range it can receive the signal almost in the whole radio spectrum: police, emergency/weather channels, TV etc
Radio spectrum - Wikipedia
The signal strength mostly depends on the quality of your antenna. The quality of the FM radio signal is definitely not high quality. As far as I remember for FM stations 14KHz is the high limit. Also you should expect noise if the signal is weak. Another problem which I experienced - the USB dongle becomes really hot. Despite of all these drawbacks it can be still usable in autonomous systems (without Internet access) or for lovers of the vintage systems
Stereo is the other area to investigate. I didn't try gnu radio myself but read somewhere that it's very resource (memory/CPU) hungry system. rtl_fm which I'm using takes about 20% of CPU on RPi 3, redsea takes another 11% and aplay about 20%.
Overview | Freq Show: Raspberry Pi RTL-SDR Scanner | Adafruit Learning System
But almost everyone was focused on a spectrum analyzer UI related to RTL-SDR. That's understandable - it looks almost like rocket science
Just remember that the usage of the RTL-SDR is not legal in some countries because besides FM radio range it can receive the signal almost in the whole radio spectrum: police, emergency/weather channels, TV etc
Radio spectrum - Wikipedia
The signal strength mostly depends on the quality of your antenna. The quality of the FM radio signal is definitely not high quality. As far as I remember for FM stations 14KHz is the high limit. Also you should expect noise if the signal is weak. Another problem which I experienced - the USB dongle becomes really hot. Despite of all these drawbacks it can be still usable in autonomous systems (without Internet access) or for lovers of the vintage systems
Stereo is the other area to investigate. I didn't try gnu radio myself but read somewhere that it's very resource (memory/CPU) hungry system. rtl_fm which I'm using takes about 20% of CPU on RPi 3, redsea takes another 11% and aplay about 20%.
Another alternative option for FM radio can be this kind of modules:
https://www.amazon.com/gp/product/B071F3ZFSC/
You can set the frequency using I2C interface. But that's the only thing which you can do with such modules. You cannot get the output signal as these modules have on-board amplifier. That makes it difficult to use for existing system which has already DAC or Amp as you need separate speakers and volume control. But for the small dedicated system it's pretty good.
https://www.amazon.com/gp/product/B071F3ZFSC/
You can set the frequency using I2C interface. But that's the only thing which you can do with such modules. You cannot get the output signal as these modules have on-board amplifier. That makes it difficult to use for existing system which has already DAC or Amp as you need separate speakers and volume control. But for the small dedicated system it's pretty good.
- Status
- This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.