I opened an RFP for Polypaudio 0.9.0 in the Debian BTS. Anyone interested?

Update: We have found a volunteer in Franz Pletz.

We are proud to announce Polypaudio 0.9.0. This is a major step ahead since we decided to freeze the current API. From now on we will maintain API compability (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.

padsp works more or less like that ESOUND tool known as esddsp. However, it is much cleaner in design and thus works with many more applications than the original tool. Proper locking is implemented which allows it to work in multithreaded applications. In addition to mere /dev/dsp emulation it wraps /dev/sndstat and /dev/mixer. Proper synchronization primitives are also available, which enables lip-sync movie playback using padsp on mplayer. Other applications that are known to work properly with padsp are aumix, libao, XMMS, sox. There are some things padsp doesn't support (yet): that's most notably recording, and mmap() wrapping. Recording will be added in a later version. mmap() support is available in esddsp but not in padsp. I am reluctant to add support for this, because it cannot work properly when it comes to playback latency handling. However, latency handling this the primary reasoning for using mmap(). In addition the hack that is included in esddsp works only for Quake2 and Quake3, both being Free Software now. It probably makes more sense to fix those two games than implementing a really dirty hack in padsp. Remember that you can always use the original esddsp tools since Polypaudio offers full protocol compatibility with ESOUND.

module-volume-restore is a small module that stores the volume of all playback streams and restores them when the applications which created them creates a new stream. If this module is loaded, Polypaudio will make sure that you Gaim sounds are always played at low volume, while your XMMS music is always played at full volume.

Besides the new release of Polypaudio itself we released a bunch of other packages to work with the new release:

• gst-polyp 0.9.0, a Polypaudio plugin for GStreamer 0.10. The plugin is quite sophisticated. In fact it is probably the only sink/source plugin for GStreamer that reaches the functionality of the ALSA plugin that is shipped with upstream. It implements the GstPropertyProbe and GstImplementsInterface interfaces, which allow gnome-volume-meter and other GStreamer tools to control the volume of a Polypaudio server. The sink element listens for GST_EVENT_TAG events, and can thus use ID3 tags and other meta data to name the playback stream in the Polypaudio server. This is useful to identify the stream in the Polypaudio Volume Control. In short: Polypaudio 0.9.0 now offers first class integration into GStreamer.
• libao-polyp 0.9.0, a simple plugin for libao, which is used for audio playback by tools like ogg123 and Gaim, besides others.
• xmms-polyp 0.9.0, an output plugin for XMMS. As special feature it uses the currently played song name for naming the audio stream in Polypaudio.
• Polypaudio Manager 0.9.0, updated for Polypaudio 0.9.0
• Polypaudio Volume Control 0.9.0, updated for Polypaudio 0.9.0
• Polypaudio Volume Meter 0.9.0, updated for Polypaudio 0.9.0

A screenshot showing most of this in action:

.

This screenshot shows: the Polypaudio Manager, the Polypaudio Volume Control, the Polypaudio Volume Meter, the XMMS plugin, the GStreamer plugin used by Rhythmbox and gstreamer-properties, pacat playing some noise from /dev/urandom, padsp used on MPlayer. (This screenshot actually shows some post-0.9.0 work, like the icons used by the application windows)

Scott Herscher decided to cease development of HOWL. That means only Avahi and Bonjour are left as widely known mDNS/DNS-SD implementations.

Scott, your work on HOWL has not been in vain. Many Linux/Free Software people (including me) learned to know Zeroconf with your software. Without the troubles surrounding the licensing, I would never have started what is now known as Avahi, and HOWL would still be the number one of the Linux mDNS/DNS-SD implementations.

The HOWL legacy will live on, since Avahi includes a HOWL compatibility layer which will be kept around for a while.

A year and a few weeks ago Trent and I decided to merge our efforts and form Avahi from our seperate works. I wonder how much time it will take us until we see a similar R.I.P. note from the Bonjour camp, on our route to AVAHI WORLD DOMINATION. ;-)

In contrast to what Scott wrote in his announcement, Avahi is far from being strictly Linux. Avahi has been ported to FreeBSD, OpenBSD, MacOSX and recently (not yet official) Solaris. (However, he's right with what he writes about me.)

The "Dockland" in Hamburg-Altona:

The result of a few hours of hacking:

pavucontrol cannot only control the volume of hardware devices of the Polypaudio sound server but also of all playback streams seperately, much like the new Windows Vista volume control application.

Get the Polypaudio Volume Control while it is hot.

On a side note I released updated versions of both the Polypaudio Volume Meter and the Polypaudio Manager which are compatible with Polypaudio 0.8.

The reports of Polypaudio's death are greatly exaggerated.

We are proud to announce the release of Polypaudio 0.8, our networked sound daemon for Linux, other Unix-like operating systems, and Microsoft Windows. Since the last official release, 0.7, more than a year has passed. In the meantime Polypaudio experienced major improvements. Major contributions have been made by both Pierre Ossman and me. Pierre is being payed by Cendio AB to work on Polypaudio. Cendio distributes Polypaudio along with their ThinLinc Terminal Server.

Some of the major changes:

• New playback buffer model that allows applications to freely seek in the server side playback buffer (both with relative and absolute indexes) and to synchronize multiple streams together, in a way that the playback times are guaranteed to stay synchronized even in the case of a buffer underrun. (Lennart)
• Ported to Microsoft Windows and Sun Solaris (Pierre)
• Many inner loops (like sample type conversions) have been ported to liboil, which enables us to take advantage of modern SIMD instruction sets, like MMX or SSE/SSE2. (Lennart)
• Support for channel maps which allow applications to assign specific speaker positions to logical channels. This enables support for "surround sound". In addition we now support seperate volumes for all channels. (Lennart)
• Support for hardware volume control for drivers that support it. (Lennart, Pierre)
• Local users may now be authenticated just by the membership in a UNIX group, without the need to exchange authentication cookies. (Lennart)
• A new driver module module-detect which detects automatically what local output devices are available and loads the needed drivers. Supports ALSA, OSS, Solaris and Win32 devices. (Lennart, Pierre)
• Two new modules implementing RTP/SDP/SAP based multicast audio streaming. Useful for streaming music to multiple PCs with speakers simultaneously. Or for implementing a simple "always-on" conferencing solution for the LAN. Or for sharing a single MIC/LINE-IN jack on the LAN. (Lennart)
• Two new modules for connecting Polypaudio to a JACK audio server (Lennart)
• A new Zeroconf (mDNS/DNS-SD) publisher module. (Lennart)
• A new module to control the volume of an output sink with a LIRC supported infrared remote control, and another one for doing so with a multimeda keyboard. (Lennart)
• Support for resolving remote host names asynchronously using libasyncns. (Lennart)
• A simple proof-of-concept HTTP module, which dumps the current daemon status to HTML. (Lennart)
• Add proper validity checking of passed parameter to every single API functions. (Lennart)
• Last but not least, the documentation has been beefed up a lot and is no longer just a simple doxygen-based API documentation (Pierre, Lennart)

Sounds good, doesn't it? But that's not all!

We're really excited about this new Polypaudio release. However, there are more very exciting, good news in the Polypaudio world. Pierre implemented a Polypaudio plugin for alsa-libs. This means you may now use any ALSA-aware application to access a Polypaudio sound server! The patch has already merged upstream, and will probably appear in the next official release of alsa-plugins.

Due to the massive internal changes we had to make a lot of modifications to the public API. Hence applications which currently make use of the Polypaudio 0.7 API need to be updated. The patches or packages I maintain will be updated in the next weeks one-by-one. (That is: xmms-polyp, the MPlayer patch, the libao patch, the GStreamer patch and the PortAudio patch)

A side note: I wonder what this new release means for Polypaudio in Debian. I've never been informed by the Debian maintainers of Polypaudio that it has been uploaded to Debian, and never of the removal either. In fact I never exchanged a single line with those who were the Debian maintainers of Polypaudio. Is this the intended way how the Debian project wants its developers to communicate with upstream? I doubt that!

How does Polypaudio compare to ESOUND?

Polypaudio does everything what ESOUND does, and much more. It is a fully compatible drop-in replacement. With a small script you can make it command line compatible (including autospawning). ESOUND clients may connect to our daemon just like they did to the original ESOUND daemon, since we implemented a compatibility module for the ESOUND protocol.

Support for other well known networked audio protocols (such as NAS) should be easy to add - if there is a need.

For a full list of the features that Polypaudio has over ESOUND, see Polypaudio's homepage.

How does Polypaudio compare to ALSA's dmix?

Some people might ask whether there still is a need for a sound server in times where ALSA's dmix plugin is available. The answer is: yes!

Firstly, Polypaudio is networked, which dmix is not. However, there are many reasons why Polypaudio is useful on non-networked systems as well. Polypaudio is portable, it is available not just for Linux but for FreeBSD, Solaris and even Microsoft Windows. Polypaudio is extensible, there is broad range of additional modules available which allow the user to use Polypaudio in many exciting ways ALSA doesn't offer. In Polypaudio streams, devices and other server internals can be monitored and introspected freely. The volume of the multiple streams may be manipulated independently of each other, which allows new exciting applications like a work-alike of the new per-application mixer tool featured in upcoming Windows Vista. In multi-user systems, Polypaudio offers a secure and safe way to allow multiple users to access the sound device simultaneously. Polypaudio may be accessed through the ESOUND and the ALSA APIs. In addition, ALSA dmix is still not supported properly by many ALSA clients, and is difficult to setup.

A side node: dmix forks off its own simple sound daemon anyway, hence there is no big difference to using Polypaudio with the ALSA plugin in auto-spawning mode. (Though admittedly, those ALSA clients that don't work properly with dmix, won't do so with our ALSA plugin as well since they actually use the ALSA API incorrectly.)

How does Polypaudio compare to JACK?

Everytime people discuss sound servers on Unix/Linux and which way is the right to go for desktops, JACK gets mentioned and suggested by some as a replacement for ESOUND for the desktop. However, this is not practical. JACK is not intended to be a desktop sound server, instead it is designed for professional audio in mind. Its semantics are different from other sound servers: e.g. it uses exclusively floating point samples, doesn't deal directly with interleaved channels and maintains a server global time-line which may be stopped and seeked around. All that translates badly to desktop usages. JACK is really nice software, but just not designed for the normal desktop user, who's not working on professional audio production.

Since we think that JACK is really a nice piece of work, we added two new modules to Polypaudio which can be used to hook it up to a JACK server.

Get Polypaudio 0.8, while it is hot!

BTW: We're looking for a logo for Polypaudio. Feel free to send us your suggestions!

Update: The Debian rant is unjust to Jeff Waugh. In fact, he had informed me that he prepared Debian packages of Polypaudio. I just never realized that he had actually uploaded them to Debian. What still stands, however, is that I've not been informed or asked about the removal.

The result of stitching six photos together with Hugin, autopano-sift, and enblend:

The St.-Pauli-Landungsbrücken with the Queen Mary 2 in the drydock, Hamburg, Germany in November 2005. Photographed from the Stintfang. The full image has a size of 9256x2240.

The result of stitching 16 photos together with Hugin, autopano-sift, and enblend:

The Massif du Soreiller with the Aiguille du Plat de la Selle near Les Deux Alpes, France. Photographed from the Dôme de Puy Salié. The full image has a size of 14443x2156. More pictures from Les Deux Alpes.

In response to mjg59's rant about controlling the LCD brightness on laptops, I invested some time to reverse engineer the Windows driver of my MSI S270 laptop which implements changing LCD brightness. It requires some ugly fiddling with registers of the "embedded controller" on ports 0x62 and 0x66. The result of my work is s270ctrl, a small userspace utility. I'm planning to turn this into a proper kernel module soon.

If you have access to the current issue (03/06) of the german Linux Magazin make sure to read the two extensive articles about Avahi (p.64 and p.90). Daniel S. Haischt wrote the second article, I wrote the other. Both are a worthy read!