Polypaudio is a relatively new cross-platform networked sound server project. The first release came out in July, 2004, the software has been released under the LGPL. "Polypaudio is a networked sound server for Linux and other Unix like operating systems and Microsoft Windows. It is intended to be an improved drop-in replacement for the Enlightened Sound Daemon (ESOUND)." The main function of a sound server is to allow multiple audio applications to simultaneously share the same sound card, the networking capabilities extend this ability across machines.
Post a Comment
Member since:
2005-07-06
Good to see this is alive and kicking still. While I don't have the greatest of understanding regarding how everything sound-related interacts, I had read that this project had stalled somewhat.
One thing I can't quite grasp with my simpleton understanding of the linux audio stack... how does polypaudio fit in? GStreamer is making great in roads for the linux desktop in Gnome, can polypaudio transparently provide the per-application sound levelling that I like about Vista? How does the whole stack work? Does it require patches to each application, or does it "plug in" somewhere along the way? How far down the sound stack does this sit - I'm assuming below GStreamer, but is this the bottom of the stack?
Any pointers for reading / explanation gratefully received 
Edited 2006-06-02 00:04
Member since:2005-07-08
I'm no expert, but I know polyaudio sits above ALSA, OSS, jack, and other sound sinks and sources. I'm also pretty sure it sits below GStreamer, Xine, MPlayer, and other media frameworks. It serves more-or-less the same function as ESD, dmix, and the charred corpse of aRts.
It's an audio multiplexor, so technically it doesn't need to do anything beyond an unweighted sum of the sources. However, I'm pretty sure they'd implement per-source volume adjustment.
The question about application level support is the most interesting. Clearly it can reasonably support any application that can already sink to any of the media frameworks polypaudio supports. And, supporting any application that alread supports jack is probably pretty easy (and there's a lot of development work being done at the moment do bring jack support to more and more applications). As for applications that currently only support ALSA and/or OSS, I don't know how that would work.
Member since:2006-03-20
I'm not a linux audio expert, but I know enough about the frameworks to have a fair guess.
I'd expect that Polypaudio - in GStreamer, at least - would replace an AlsaSink or OssSink as the output device, and any well designed program (ie: enumerates output devices dynamically, rather than hardcoding an AlsaSink as the output) would simply allow the user to change the output device in it's settings dialog.
Of course, Polypaudio itself would sit in the stack between GStreamer and Alsa/OSS/Whatever.
Member since:
2005-07-06
Member since:2006-06-02
Exactly. For people who know more or less how they can configure sound it's not a real problem. But since I introduced linux to my neighbor, this is where he get's stuck. Running Gnome apps in KDE and vice versa. It would be nice to have a more common way how applications get info on where and how to get sound.
What's the best way to tackle this problem any way.
Member since:2005-07-09
Given "Protocol support beyond ESOUND's protocol and the native protocol. (such as NAS or a subset of aRts)" and "There are output plugins for XMMS, libao (merged in libao SVN) and gstreamer (merged in gstreamer-plugins CVS)" it seems that some sort of consolidation is possible.
gstreamer can run PolyAudio which can run NAS if you're in GNOME, or Phonon can run gstreamer which can run PolyAudio which can run NAS if you're in KDE, unless you use the NAS plugin for gstreamer or Phonon creates a NAS plugin, in which case you cut out a few of the middle mean.
I agree, things are pretty messed up at the moment. It would be nice if people stopped reinventing the oval wheel. One key reason given for reinventing higher levels or adding lower levels is portability, but the problem is, the more fragmentation you add the audio subsystem, the harder it is to port.
Edited 2006-06-02 13:40
Member since:
2005-08-26
Member since:2005-08-10
windows -> * ; no (1)
linux/nix -> * ; yes (2)
where * = nix-ish OS or windows+cygwin
(1) native win32 applics are unaware of sound servers. cygwin port of *nix applics theoretically would work, but I never try.
(2) trival with esound/arts. windows target requires cygwin+sound servers.
"Remote desktop" type of applics might export sound as well. AFAIK nix-ish applics e.g. vnc/nx/x all are video only. Anybody shine some light on MS counterpart(rdp, terminal server)?
Member since:2005-07-06
