Indeed the MPD system was working, and controlling a local USB soundcard, but I couldn't stop there. I wanted to be able to send the centrally controlled audio around to other parts of the house (I have various NSLU2 devices around the house running Debian with soundcards and wireless). There is a major problem with this as detailed below. One answer is as following...
#On the machine you want to receive the sound run this to create a long-lived daemon which waits for connection, and stays waiting after disconnection...
nc -k -l 17654 | pacat
#On the machine from which you want to send sound, you can target the waiting machine with a sound stream as follows...
pacat -r -d "alsa_output.usb-0d8c_C-Media_USB_Headphone_Set-00-Set.analog-stereo.monitor" | nc 192.168.1.60 17654
This relies on using Pulseaudio as an output on the source machine, and choosing the right source name. The pacat utility allows the bytestream from a pulseaudio source (in this case a sink monitor) to be streamed as bytes. Netcat allows bytestreams to be set up over the network, so if you launch these two command lines on two different machines after configuring MPD to use pulseaudio, and installing the needed packages, such as pulseaudio netcat-openbsd and so on, the audio from one is connected to the other.
This seems to settle at around 200kB consistently and about 3 seconds latency on my network, streaming to my ubuntu laptop's sound card.
BACKGROUND
The problem is that the ARM device isn't capable of accelerated floating point operations, (in contrast to a typical Intel chip). This means that the floating-point encoders which are normally used for MP3 cause the system to slow to a crawl (more than 100% of a Pogoplug's CPU anyway). The result of this is skipping, jumping audio if you activate MPD's built-in HTTP, or indeed attempt any other 'internet radio' strategy which re-encodes the signal, which is the normal way this works. Whilst the MAD decoder exists for MP3, which uses integer arithmetic, the equivalent mainstream ENCODER doesn't seem to exist, although people are experimenting with things derived from the (immature) Shine Decoder codebase, there's nothing simple to configure.
So I spent a bunch of time trying to find media-friendly ways of wrapping the wav output from MPD directly in a media stream without any reencoding, assuming bandwidth isn't an issue (local wireless lan) including this discussion which led to a working configuration of Rygel (but which simply revealed a problematic interaction with VLC).
http://osdir.com/ml/general/2012-05/msg56763.html
Having dug around and found various fifo-oriented tools for interacting with the wav stream I ended up trying the strategy described above, which worked as well as anything else, if you're happy with the command line. If you want something more GUI oriented, then look into the Rygel example a bit more, and find a less buggy client/mime-type configuration than mine. On the plus side, using Rygel you could potentially mount media from there as well as listening to a central MPD.
MISC DETAILS
Note the device name came from running...
pacmd list-sources
You can also try to minimise latency with the following extra options from the sending machine, but it's still a pretty long buffer for 3 seconds delay - that's in my router I guess...
pacat -r --latency-msec=1 --process-time-msec=1 -d "alsa_output.usb-0d8c_C-Media_USB_Headphone_Set-00-Set.analog-stereo.monitor" | nc 192.168.1.60 17654
Have fun with it. I'm saving the money on a baby monitor, feeding the microphone from upstairs to the stereo downstairs!
Cefn
http://cefn.com