Hi, There's definitely an appeal to simplicity for being able to declare, in default.pa, load-module module-icecast-sink var1=val1 var2=val2 ... However, there are already solutions that allow you to take the output of PulseAudio and pipe it into an Icecast2 server. Darkice is an Icecast2 Source which accepts an input channel from an ALSA device, and it happens to work well with the ALSA<->Pulse plugin for libasound2. In PulseAudio, every sink has a corresponding loopback device, also known as a monitor source. By setting your PA server's default input sink to the monitor source of the sink producing the desired sound, you can pipe any PulseAudio sound to icecast2. By making the sink a null sink, you can opt to route audio through PulseAudio to DarkIce without needing any sound hardware. In this case, the null sink will not produce any sound through PA directly, but as DarkIce monitors the sink, it is able to read the data just before PulseAudio discards it. Having never written a PA module myself, I'm not sure what complexities might be encountered by trying to fit an Icecast2 source library into the PA framework. If the sink idiom isn't a good fit for some reason, you could instead write a general module that accepts a parameter for which sink to monitor, then monitors it and streams that using libshout. You could also not write a module at all, but just a client program *similar to* DarkIce, but which speaks the native PA protocol. But by the time you do that, you could have just as easily extended DarkIce with native PulseAudio support. And DarkIce is sufficiently robust that you'd be reinventing many spokes of the wheel. The UNIX philosopher in me says it's good to maintain separation of concerns between Icecast sources (like DarkIce, or better, mpd) and PCM sound servers (like PulseAudio). Imagine if we tried to merge the concerns of "cp", "mv" and "ls" into a single program: yuck! Another, closer analogy would be, trying to implement VNC as an Xorg DDX (a display driver extension). Double yuck! PulseAudio is to Icecast2 as Xorg is to VNC. Note: I would *completely* be in favor of implementing a robust PulseAudio interface for DarkIce, so we wouldn't have to rely on the functioning of the ALSA compatibility layer for this. ALSA<->Pulse is an interim solution that could break whenever there are changes to libasound2. Now just a few inline comments :) Matthew Patterson wrote: > Hey everyone, > > In my quest to further expand my whole home audio solution I was > thinking about the options for piping the music to non pulse supporting > devices like my internet tablet and cell phones. Right now I stream to > these devices simply by giving them playlists that target my webserver, > but I have tried in the past icecast2. This has the added benefit of > normalizing the stream bitrate for the lower bandwidth of the cell phone > (and is essential now that I am moving to flac as my primary format). > Yeah, native PulseAudio over a network is too much bandwidth for most networks, except LANs operating under low load. With Shoutcast/Icecast, you lose a little bit of quality, gain a ton of latency, but the bandwidth needs are more realistic. > Has anybody worked on a solution for pulseaudio -> shoutcast/icecast? Yes, and it doesn't require a single line of code! See the above DarkIce explanation. > I realize icecast only takes mp3/ogg streams, so the raw pcm data would > have to be piped through an encoder on the fly, True. libshout does not provide encoding facilities. MPD does this very well; it can accept a number of input formats, routes them through low-level audio libraries (libFLAC, libtheora, libmikmod, libmad, etc) and converts them into a format supported by libshout. To interface pulse with libshout, you'd only need the ability to convert PCM into MP3, and PCM into Ogg/Vorbis, since all PA data is PCM. For format conversion, I'd advise against depending on a media framework (Gstreamer or Xine or even ffmpeg), since any "good" PA module would ideally be integrated to the PA tree... and we don't want PA depending on Gstreamer or Xine or ffmpeg. > then shipped to the > icecast server. I also realize synchronization would be lost, but > wouldn't this be a cool addition! > Actually, I'm not sure how you would measure latency, synchronize, or implement buffer rewriting with this, if you used a sink module as your base. It'd be strange to explain to pulsecore that the libshout send buffer is a really huge buffer of non-PCM data which has no correspondence to the data PA clients are writing to the sink. How would you implement rewinding or hot-swapping? > Any ideas? > > Matt > You're welcome to try the PA module architecture for this; it may turn out better than I expect. But if you're just an end user looking for a quick fix, go with DarkIce. I can add stuff to the PA wiki about DarkIce using ALSA<->Pulse if you like? Let us know if you have trouble with the setup. -Sean
