shairport-sync VS gnuradio

It's worth noting that shairport-sync exists. Perhaps it could be made easy by knitting some functions together?

You want SnapCast. You'd run snapserver on your Linux box and snapclient on your Pi's. Snapserver has support for Airplay (via shairport-sync) and Spotify (via librespot). I recommend using MPD for your music library, as I don't think PlexAmp can output audio in a way that's useful for snapserver.

I use shairport-sync for airplay (https://github.com/mikebrady/shairport-sync), complete instructions via: https://blog.adena.dev/blog/apple-airplay-on-raspberry-pi-in-7-easy-steps

If you’re interested, you might be able to get Airplay 1 & 2 support by running shairport-sync on your pi.

The plan is to run shairport-sync on the Omega 2 and have audio output to a 2x50w class d amplifier board.

To replace it, I've purchased in-ceiling speakers and a Control 4 Amp (C4-16AMP3-B) which I can control via the network. I plan on using shareport-sync for AirPlay and librespot for spotify as the sources to play music. 90% of the use for my whole home audio is for music.

ShairPort-Sync allows my Mac to listen for a AirPlay with multiple instances available, each pointing to different settings as per this GitHub Issue, which would allow me in theory to run multiple AirPort plugs and output each to an Alexa. Rarely would I ever need to have them playing all at once, and at this point I don't really care about maintaining pure audio quality or latency. I just need to be able to get out of my office and move to the kitchen, then back to my office without needing to spend a ridiculous amount of time trying to move what I was listening to on my iPad into my Echo Show

The benefit of the Pi is the open source software, in particular I use https://github.com/mikebrady/shairport-sync in order to turn it into an AirPlay 2 receiver, which I can stream to using my phone or laptop. It's my main way of sending audio to my hifi setup.

The only option I know of would be to use multiple raspberry pi’s running Shairport-Sync. I’ve been using the airplay 2 version for about a year and it works great. You might be able to build a server and run multiple instances of shairport with multiple audio cards. https://github.com/mikebrady/shairport-sync

So, after looking around, I realised that just like the Nest Hub 2nd gen, the Nest Audio also has a (sort of) exposed debug USB port. And these devices are (originally) running Linux. Since the Nest Hub 2nd gen has been jailbroken, I'm hoping that I can do the same on the Nest Audio, with a singular purpose: to inject a ShairPlay service, which would run parallel to the Chromecast services, which would allow me to use them as native AirPlay2 speakers.

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