Weekly Edition
Return to the Development pageSponsored link
Serve your customers, not your servers, with VERIO Linux VPS. Full-access test-drive here.
| Weekly edition | Kernel | Security | Distributions | Search |
| Archives | Calendar | Subscribe | Write for LWN | LWN.net FAQ |
Polypaudio, a networked sound server
Some of the main Polypaudio features include:
- An extensible plugin architecture with support for loadable modules.
- Compatibility with many popular audio applications.
- Support for multiple audio sources and sinks.
- Low-latency operation and support for latency measurement.
- A zero-copy memory architecture for processor resource efficiency.
- A command-line interface with scripting capabilities.
- A sound daemon with command line reconfiguration capabilities.
- Built-in sample conversion and resampling capabilities.
- The ability to combine multiple sound cards into one.
- The ability to synchronize multiple playback streams.
The Polypaudio FAQ explains some of the Polypaudio dependencies and compatibilities, and has numerous examples of command-line operations.
Although GNOME/GTK is not required for Polypaudio operation, some GTK-based GUI utilities are provided, including Polypaudio Manager, Polypaudio Volume Meter and Polypaudio Volume Control.
Version 0.9.0 of Polypaudio was announced on May 26, 2006. It now fully matches or improves upon the ESOUND feature set. "This is a major step ahead since we decided to freeze the current API. From now on we will maintain API compatibility (or at least try to). To emphasize this starting with this release the shared library sonames are properly versioned. While Polypaudio 0.9.0 is not API/ABI compatible with 0.8 it is protocol compatible. Other notable changes beyond bug fixing, bug fixing and bug fixing are: a new Open Sound System /dev/dsp wrapper named padsp and a module module-volume-restore have been added."
Polypaudio version 0.9.0 adds new versions of the modules gst-polyp for use with the GStreamer multimedia framework, libao-polyp for Ogg-vorbis support, and xmms-polyp for sinking XMMS media player output.
With its support for a wide variety of popular audio utilities, actively developed code, and broad capabilities, the Polypaudio project fills an important role in Linux-based audio development.
(Log in to post comments)
Polypaudio, a networked sound server
Posted Jun 1, 2006 9:00 UTC (Thu) by rjw (guest, #10415) [Link]
Ubuntu dropped polypaudio and reverted to esound because of unreasonable CPU usage,IIRC. Has this issue been solved?
Polypaudio, a networked sound server
Posted Jun 1, 2006 10:01 UTC (Thu) by nix (subscriber, #2304) [Link]
The plural of anecdote is not data, but I've found polypaudio to have substantially lower CPU consumption than esound, not least because esound tended to go into CPU-hogging endless loops.polypaudio 0.8+ now uses liboil for many tight inner loops, which should one hopes reduce this problem.
Polypaudio, a networked sound server
Posted Jun 1, 2006 11:01 UTC (Thu) by k8to (subscriber, #15413) [Link]
I do not believe "distribution X dropped technology Y because of problemZ" is an isolated anecdote. When one considers that the people working
on that decision probably want to make good choices, it is more than a
side story, although it may merit more investigation.
Polypaudio, a networked sound server
Posted Jun 1, 2006 17:46 UTC (Thu) by edgewood (subscriber, #1123) [Link]
I believe nix's comment about anecdotes referred to his own experience with Polypaudio, not Ubuntu's.
Polypaudio, a networked sound server
Posted Jun 5, 2006 16:43 UTC (Mon) by nix (subscriber, #2304) [Link]
Indeed it did. Ubuntu's experience is at least a much more *widely-experienced* anecdote. :)
Polypaudio, a networked sound server
Posted Jun 1, 2006 22:50 UTC (Thu) by NoTiG (guest, #38147) [Link]
here is what the comment in the ubuntu wiki said :
done: dmix by default, gstreamer->alsa, libesd-alsa, default sound card selector, polypaudio bug fixing, Red Hat hack investigation, esd and polypaudio reconnect; hotplug dialog prepared, but not uploaded (pending discussion); /dev/dsp hack impossible; (2005-07-19): polypaudio still too unstable, so breezy will stay with esd; (2005-07-19): remaining issues: configuration dialog on hotplug, test beep/capture;(2005-08-02): implemented last outstanding bit: hotplug response, upload pending libnotify promotion to main; (2005-08-05): libnotify has problems on powerpc, will debug; outstanding: some cleanup of the ~/.asoundrc configuration backend (with jdthood), some bug fixes; (2005-08-10): fixed notify, added hotplug notification to g-v-m; test beep/capture will be deferred after discussion with mdz. (2005-08-22) All fxed and completed.
Polypaudio, a networked sound server
Posted Jun 1, 2006 10:02 UTC (Thu) by nix (subscriber, #2304) [Link]
I was mourning polypaudio: it looked like Lennart had got completely distracted by avahi.
But no, it lives! :)
Software Mixing
Posted Jun 6, 2006 0:22 UTC (Tue) by fanopanic (guest, #27958) [Link]
Why is FreeBSD the only free OS that managed to do software mixing right? I mean, with all the ambitious plans to make Linux desktops a veritable alternative to Windows/MacOSX, both of which support painfree software mixing, this should be a number one priority.
I can live without windows-only applications and fancy games, but I do not understand why I should play around with starting/stopping/restarting applications because the sound device is already in use. The alternatives, sound servers or meticulously fiddling with asound.conf in order to get dmix running, are not fun and not acceptable, especially considering that FreeBSD simply does it in-kernel, without any hassle for the user at all.
Software Mixing
Posted Jun 6, 2006 7:17 UTC (Tue) by drag (subscriber, #31333) [Link]
It's due to legacy support of OSS driver system. It's a bit funky and designed to be used with ancient-style sound cards.
If, on very modern linux systems, if you disable OSS compatability stuff (make sure the oss modules for alsa don't get loaded) then everything should be software mixed by default by dmix. Although disabling OSS will break some maladjusted applications.. most can be configured to use alsa though. This is relatively new with the past 2 kernels or so. Not sure how hot it works though, I still have to mess around with my asoundrc, but then again I have multiple sound cards. :)
Software Mixing
Posted Jun 9, 2006 18:20 UTC (Fri) by tialaramex (subscriber, #21167) [Link]
It took a while, but today's distros get this right. Fedora Core 5 had dmix settings up out of the box and I was able to run as many ALSA apps together sharing the single sound card as I pleased. As far as I can see it detects at runtime if you have hardware mixing on your card (from a list) and if not it uses dmix to simulate it.
Of course dmix doesn't fix OSS applications, but OSS hasn't been anything but a legacy API on Linux for many years now. Might as well complain that SELinux doesn't work with your Minix root filesystem...
"FreeBSD simply does it in-kernel"
The consequence is that your OS kernel is doing resampling, an expensive operation that would ideally be done with FP math, except of course trampling on the FP registers, especially on x86, is too nasty to be worth doing in the OS kernel, so you have some even more complicated integer maths to "kludge" it, and/or you get nasty artifacts depending on which applications you run in which order...
The comparison to Windows (which also does this kernel mixing for run of the mill applications) fails to mention that Vista moves away from that model due to reliability problems. Did I mention the kernel bugs found in the BSD mixer? Found and fixed of course... until next time.