gnuradio VS Mopidy

In gr-dtv transmitter examples for Gnuradio, I see some times people use a resampler block before the RF hardware sink. Say our sampling rate is ~9.14Msps which satisfies the Nyquist criterion because our samples are complex numbers.

2.1. Thanks for that tip, I forgot that I was able to check the source code of the WBFM Receive block. As you have said, there are mostly the same. There are some differences between how values are picked. The WBFM Receive block would be a synonym of Quadrature demod => Fir Filter (decimation => Low pass filter) => FM Deemphasis. 2.3. My question there is why 10 and not 20 or 100. I understand that the idea is to reduce the sample rate asap, but what I don't understand is why those values were picked and how can I understand what would be the "correct" or "best" value. 2.4. I'm not fully understanding what you said. If I check the WB FM recieve source code the values that are supplied as the cutoff freq and transition width of the Low pass filter differ from the one of the example. The webfm would apply a sample rate / decimation / 2 - sample rate / decimation / 32 as a cutoff freq and a sample rate / decimation / 32 as a transition transition width. Calculating those values would end up in different that the ones supplied in this second example. Again, is there a rule of thumb to pick these values?.

Gaussian filter is used only on the tx side, so specifying bt in the receiver makes no sense. Take a look at gfsk mod/demod blocks implementation: https://github.com/gnuradio/gnuradio/blob/master/gr-digital/python/digital/gfsk.py

GNU Radio

Here's the filter coefficients used for the GNU-Radio interpolator block to get you started. This is a 7th order interpolator (i.e., 8 FIR taps) with very good performance. Each "row" of the array sets the delay in steps of sample_time / 128.

From their README: “open-source software development toolkit that provides signal processing blocks to implement software radios.” https://github.com/gnuradio/gnuradio

Lots and lots of FOSS music players use libspotify or can otherwise connect to your Spotify account.

Here's just one. It's BYO frontend. https://mopidy.com/

Probably a good time to give a shout out to Mopidy: https://mopidy.com/

Though as for myself, I'm still running Squeezebox - nothing like being able to SSH into your smart speaker and mess around with the Perl system that's running it.

Have you tried Mopidy or MPD daemon? There's even a mopidy-party extension that is

I've tried several times to get mpd working over a network. The only way I got it to work was with mopidy. At some point it broke and I moved on to jellyfin instead. Too bad, because I love ncmpcpp as a client.

I have a music library on my home server that I use mopidy to play via the iris plugin integrated into my home assistant UI. It plays over Snapcast which streams over the network to multiple devices in the home with independent volume control. I can fire up the Snapcast client in my phone to get it going there as well, which does work over vpn if I'm away, though I generally just fire up the files from my phones SD card for out-of-home listening. I recently started using whipper on Linux to extract audio from craigslist cds.

https://mopidy.com/

https://mopidy.com/ext/iris/

https://github.com/badaix/snapcast

https://github.com/whipper-team/whipper

Could instead use Mopidy as the music player, which has plugins for Spotify and Airplay support.

Thanks! I use it on a daily basis, but I don’t think it’s ready for a wider adoption yet — for example, a pause button is still missing ... I’d be curious to know your experience with it though! For something more stable, you might like Mopidy.

Right now I'm reading about mopidy and iris (I have a server with some docker services and it would be nice using it as a Spotify connect device), I think this setup could be extended with extra algorithms, maybe they already exist as modipy extensions. I've never gone into detail about these but I'll do it!