Propeller chip + SPDIF = ???
So, kind of on a random whim, I decided to build a software SPDIF encoder for the Propeller chip. It was an interesting challenge, and the results are pretty cool, but now I have no idea what do do with it. Not an uncommon problem for me, I guess…
Maybe I’ll give my Propeller board an Ethernet port and build a Squeezebox-on-a-chip.
Update: Ok, so maybe that’s not such a crazy idea.. (or is it?) Anyway, I just found this, and I had to order a couple:
Now if only there was a simple way to capture all sound output from a Windows/Linux/Mac machine and stream it over the network… The ESD protocol doesn’t count 
Have you looked at PulseAudio?
I’ve used PulseAudio before for similar projects, but as far as I know there’s no way to use it with unmodified Windows and Mac OS apps. I searched around a bit and found other people that were requesting a Windows sound driver that can loop back to a PulseAudio server, but I haven’t been able to find such a thing.
I spent a little more time looking into emulating a SqueezeBox, so that I could stream audio from SlimServer to a Propeller chip. The protocol doesn’t look too complicated, but I don’t think there’s a way to tell SlimServer that your device doesn’t support MP3 decoding. (I think it will always send MP3s as MP3 data, even if you tell it to decode other formats into PCM.)
This is awesome.
I’ve been thinking about building SPDIF-over-Ethernet, as a transport from our Linux media box to the TV/stereo/game console complex. That’d let me reduce from three cables (power, ethernet, audio) to just two. Please, no comments about optimizing for the wrong thing
I’m familiar with the AVR family, so I’d tentatively planned to build the tail-end out of an ATmega, one of those ethernet jacks from Sparkfun, and the least output-stage electronics I can get away with. I’ll probably “borrow” a lot from this project…
The head-end would be something on the Linux box that turns system audio into SPDIF-o-E. A Pulseaudio sink might be the path of least resistance. But I’ve put almost no thought into it. I have a fast programmable machine with lots of audio content and an eth jack in the back; I can probably make it work.
I also haven’t thought about the protocol itself much. The simplest thing is to pack each SPDIF frame into the data of an Ethernet frame, and just spray them at a designated MAC address. (or multicast?) The only thing the tail-end has to do is copy bits and do the biphase mark stuff.
I didn’t realize the SPDIF bit rate was so high – isn’t 44/16 PCM only like 1.4mbits? But 6 will take up most of a 10BaseT link. I’ll definitely need 100 or gig e for the backhaul across the room. I’ll also need to get a fast chip and make sure I can do the decoding at speed. The AVRs are one instruction per clock and run at ~10MHz; it shouldn’t take much to receive the frame and sling the right bits to the output stage. I’ll need to really look at that ethernet controller’s datasheet, though.
-joe
(Scott’s friend, Prom B1189)
Also, I’m not gonna build a Mac or Windows head-end.
Hi Joe,
It may be more tricky to duplicate this with an AVR, if you’re shooting for minimal external components. At 44/16 PCM, you’re dealing with a 5.6 MHz signal: 44100 samples per second, 2 channels per sample, 32 bits per SPDIF subframe, 2 biphase-encoded bits per unencoded bit.
The Propeller can do this 100% in software because it has a built-in PLL (for synthesizing the sample clock) and a 32-bit shift register which can be driven by this PLL.
With an AVR, you could probably use the SPI hardware as your output shift register. You’d still need an external oscillator, though, unless you ran the AVR at a multiple of 5.6448 MHz.
As for the ethernet end, I’m still not sure what protocol to go for.. I could do something simple where I just spray audio packets out over UDP in real-time, but I also want to at least do some more investigation about making it compatible with esound, PulseAudio, or SlimServer.
Let me know how it goes!
–Micah
Also, if you’re only running at 10 MIPS, that’s less than one instruction per output clock. I don’t think that’s going to cut it… it was quite a squeeze on the Propeller with two instructions per output clock. The most compact implementation of the biphase mark encoding I could come up with uses one test and one XOR per bit.
With the Propeller, I can spend one of its 80 MHz / 20 MIPS cores on the SPDIF encoding and still have seven cores left over for Ethernet MAC, TCP/IP, high-level protocols, and UI. As much as I like AVRs, this does seem like an ideal job for the Prop.