Re: Polypaudio for Gnome 2.10, the next steps

[Lennart Poettering <mztabzr 0pointer de>]

On Mon, 22.11.04 22:46, Mike Hearn (mike navi cx) wrote:

> I've been suggesting that this is a problem better solved lower in the
> OS layer-cake for a while but never really got any feedback on that, so
> I'm guessing it's either a bad idea or nobody really cares either way. 
> 
> Here is a basic form of my original proposal:
> 
>
>http://www.redhat.com/archives/fedora-devel-list/2004-October/msg01520.html

This is really bad idea. Networked audio is more than just
transferring binary audio samples from one host to another. The
solution you describe is even worse the ESOUND currently is. What you
need is passing timing info (latency and such) between the hosts
effectively and minimizing the latency by any means. 

Polypaudio is very good in these two issues. Since movie players
usually query the latency repeatedly in very short periods of time and
getting latency info usually involves a roundtrip, polypaudio
interpolates the latency information. This works quite well, lip sync
video playback with mplayer or xine using their polypaudio drivers
works astonishingly well. In addition to that polypaudio has some very
nifty techniques for allowing large playback buffers (which is
required when doing network transfers with large and non-deterministic
latency) but allows immediate reaction on user events (e.g. the user
presses "pause").

Besides, Polypaudio already exists and works, while your ALSA pulgin
doesn't exist yet.

BTW: I investigated to write an ALSA plugin for passing audio data to
polypaudio. Unfortunately the internal ALSA library API isn't flexible
enough for allowing such things without major changes (i.e. while the
external ALSA API exports multiple audio file descriptors for the
application to select() on, you don't have the ability to export more
than one fd from a single plugin. In addition to that there's no way
to change during runtime what to select() on: for readability,
writability or both). 

I personally think the ALSA API is ugly, much to complicated and way
over-engineered. However, I'll keep an eye on that. I am willing to
provide a polypaudio plugin for ALSA. One of the goals of polypaudio
is compatibility with as many APIs and applications as possible.

Another thing that I miss in your design: sample caching. That's
really something you want to have (in a networked scenario) when your
desktop generates those "ding" sounds whenever you press a button.

> Still, I'd quite like somebody to smack me down and explain why a sound
> server is really the best way forward :) So far the best reasoning I've
> seen is that X11 sync stuff, which I know nothing about. Apparently not
> many other people do either given that Lennart has been unable to find
> prior art.
> 
> Might as well get this one out of the way: I don't really consider
> portability a valid reason for using a sound server here. Some problems
> are just best solved outside the desktop level, eg there's no such thing
> as a GNOME filing system or video driver framework because that problem is

There is a video framework: X11.

And there is such a filing system: gnome-vfs. It even includes its own
daemon the last time I looked. On my debian system I can find it in
/usr/lib/gnome-vfs2/gnome-vfs-daemon

> outside the projects domain. I can't shake the feeling sound server
> type functionality is similar.

Think of Polypaudio as of the X11 for sound. ;-)

> Anyway. Anybody willing to show me the error of my ways?

There are at least five important areas where polypaudio is strong in,
and where it supersedes most other implementations I know:

- Networked sound. I do believe that this a very important issue. It's
  the same as with X11, many people don't use the network
  transparency, but some people do (including me), and are very happy
  with it and would not like to loose it. That X11 is networked is
  one of the great strengths i see in it. That's one of the points,
  where Linux/Unix is better than Windows since years. When I first
  started to work with Linux (coming from DOS/Windows) that was one
  of the points where i said "Wow, that's cool", where I was
  really impressed and started to believe in Linux's superiority. ;-)

  It seems only natural to me to extend network transparency to audio.

- Concurrent playback. You can achieve this with ALSA dmix. However,
  the last time I checked, it was incompatible
  like hell and failed to work in more places than it did work in
  other places. I don't like the implementaion of dmix, it seems that
  the latency management (low latencies and latency measurement)
  doesn't work very well yet, if at all. These are fixable things, but
  it seems as if nobody is actively working on fixing them. Plus, ALSA
  is (currently) Linux specific. (and it seems that at least the
  FreeBSD people dislike ALSA)

- Portability and compatibility. Polypaudio is (probably) much more
  portable than ALSA. "probably" because it has been ported to FreeBSD
  (and to some extent MacOSX) only, as of now. The patch for freebsd
  was only about 20 lines long, and I don't expect much larger patches
  for other operating systems. Polypaudio is compatible with ESOUND,
  which is especially important in Gnome. It is easy to write other
  protocol implementations for polypaudio (like NAS), which would make
  it even more compatible.

- Polypaudio is more than a simple sound server. You can 
  load modules into Polypaudio for teaching it new tricks. Think of
  polypaudio as an extensible application server for sound on the
  desktop. Something like the "Apache for Audio". Without any special
  modules Polypaudio behaves a like a better ESOUND. But when
  you load some special modules into it you get the full power of what 
  polypaudio can give you. Some examples of modules that are either 
  already done, or I am working on, or on my todo list:

    module-x11-bell: a small but very useful module which hooks your X11
    bell to the polypaudio server. If your internal PC speaker is broken
    or you dislike its "basic" sound, this is the module for you.
    (this one is already available in polypaudio)

    module-combine: combine two soundcards into a single one (with
    sample rate adaption). i.e. connect four speakers to your machine
    and have them all play your music synchronously. 
    (this one is already available in polypaudio)

    module-zeroconf: publish polypaudio sinks and sources via
    mDNS/DNS-SD and register foreign sinks/sources locally so that you
    can browse your network for speakers to play your music on.
    (this one is what I am currently working on)

    module-radio-send/module-radio-recv: send locally generated audio
    data to the broadcast address on the local LAN (or a multicast
    group) as UDP traffic. Other polypaudio daemons on the LAN may "tune
    into" this traffic. This is a little toy for pushing audio to a
    whole network of speakers synchronously and simultaneously. The
    design I currently have in mind will even allow lip sync movie
    playback with the audio track played on all your speakers in your
    house. (this is the next point on my todo list)

    module-dbus: control polypaudio with dbus
    (on my todo list)

    module-hal: when the user plugs in his new USB speakers, the
    module autoloads the driver plugin and plays an acknowledgment
    sound. simple but useful
    (on my todo list)
  
  Another cool module I could think of, but that isn't on my todo
  list: module-shout (for pushing audio data to an icecast-server).
 
  X11 synchronization and the accessibility stuff that Alan
  Cox was interested in are other things that could be implemented as
  modules on top of polypaudio. That's way more flexible than any
  other sound server I know.

- Polypaudio is actively maintained and has a maintainer who's really
  interested in getting polypaudio into gnome. ;-)

Lennart

-- 
name { Lennart Poettering } loc { Hamburg - Germany }
mail { mzft (at) 0pointer (dot) de } gpg { 1A015CC4 }  
www { http://0pointer.de/lennart/ } icq# { 11060553 }