Summary:

I did some quicky tests on a Raspberry Pi v1 Model B that I had lying around.  With a modern kernel build with FPU support, it should work.

Deets:

Despondent over the recent findings with the Netduino Plus 2 board (that I would likely have to do major reimplementation in libvorbis to get it to work with memory constraints -- a daunting task), I awoke to remember that I have another board on-hand (coincidentally about the same age) that has never been given any love:  a Raspberry Pi v1 Model B.

My initial thoughts were that perhaps the raw speed increase (700 MHz) might help, and certainly the large memory (512 MB) would.  I was pleasantly surprised to find out that the CPU used has the FPU option -- news to me.  It turns out that the original kernel builds were not built with the FPU support, though, out of some fear of compatibility, but later an 'armhf' build was created that did.

I found a kernel image for it here:
http://www.linuxsystems.it/raspbian-wheezy-armhf-raspberry-pi-minimal-image/
which is a minimal (118 MB) image that is functional on even a 1 GB SD card.  For development I will use a bigger one, and I'll have to install all the build tools, etc.

For a quick initial test, though, I installed 'vorbis tools', which has a pre-built encoder and decoder from the command line.  I compressed a sample file, and it took 2m 11.4s to compress a 5m 22.0s, which is about half the duration, so I naively interpret that to mean that I will see about 50% CPU load for the compression process, leaving the other 50% for everything else.  I can work with that!

Out of curiosity, I ran the same test on another ARM device I have -- a Sheeva Plug -- which runs at 1.2 GHz, but does not have an FPU.  It took 7m 12.0s to compress the 5m 22.0s (even though the processor is 70% faster), which would not be able to keep up realtime, so the FPU is definitely needed.  Normalizing for clock speed, this means the FPU gives about 5x-6x performance improvement to this particular codebase.

OK, I still feel like I'm cheating a bit using the R-Pi, but I forgive myself because I still will have plenty of work to do on implementing the radio (and making sure it works), interfacing to the R-Pi over I2S (audio) and I2C (control), and also the server software.  Anyway, I consider this an initial prototype.  If it turns out to be cool, and other folks are interested, then maybe I'll design a bespoke CPU board.

So, now that I have a notionally suitable board, I need to research how to use the I2S and I2C drivers on the R-Pi.  Then I need to make a radio board.  Oh, those parts all came in.  They are so tiny!  Yikes!  Oh, well.  The future is a tiny place....

Next:

• research I2S master input capability on the R-Pi.  This is used for receiving the 32 ksps stereo audio stream from the radio.
• research I2C capability on the R-Pi.  This is used for all control functions of the radio.
• design, fabricate, and build a circuit for the radio.  Hope it works, it's an expensive part.