PlutoWeb
PlutoWeb copied to clipboard
unixpunk
Implement a streaming option for in-browser listening
This would mostly be for WBFM but could be used with anything that plays audio. WBFM is the biggest use-case since its not supported by OpenWebRx.
Current idea = Icecast + ices2 This would allow the output from rx_fm or rx_sdr to be piped into ices2 and then played via the web browser through Icecast.
Its a bit heavy-handed, but not finding any other real solutions to be able present an audio "file" to the browser for easy playback. (I say "file" because it can't be a real file, there's no space, it has to act solely as a stream when fetched.)
Figured out how to do WBFM in OpenWebRx but its not practical on the Pluto directly because you can only see the one station you're trying to listen to, it can't handle seeing much more of the spectrum than that. I will publish wbfm in OpenWebRx in a fork once I iron out the kinks, but that wouldn't be related to PlutoWeb.
I think rx_fm -> ices2 -> Icecast is best. Then we can have the web page do a scan of the FM band, show the PNG with an image map and allow point-and-click tuning to pass the freq value to rx_fm.
Its a bit the same as leantrx, but leantrx seems to use too much CPU to be useful in the FM band.
Added to a test build - needs more testing and tweaking of configs as well as new variable, etc for it.
Example working WBFM command:
rx_sdr -F CF32 -s 3000000 -f 101100000 -g 22 - | csdr fir_decimate_cc 12 0.085 HAMMING | csdr fmdemod_quadri_cf | csdr fractional_decimator_ff 5 | csdr deemphasis_wfm_ff 48000 75e-6 | csdr convert_f_i16 | ices /etc/ices.xml
that is pretty cool! Just few questions:
- Is it mono or stereo?
- Could you please provide some figures about the CPU utilisation on Pluto (e.g. htop or top)?
- Is it possible to integrate ffmpeg on Pluto (ffmpeg supports the streaming to icecast as well but more flexible as ices)?
- Mono, crappy quality as compared to using same hw+antenna in CubicSDR
- No, you can test and see on your own, minus ices, which takes like 1% cpu
- Yes, but I will only choose ffmpeg if it happens to be smaller than ogg/vorbis
That said, I've realized I was overlooking the easiest solution for this and that's using named pipes and an encoder of choice. That encoder will be either ffmpeg or ogg/vorbis, whichever is smaller. Icecast and Ices will not be implemented.
Note to self...WTF, named pipes break when you try to access them through httpd...back to icecast+ices?...