sound server

[Mike Hearn]

> Do we have any comments on the sound server topic from a broader
> perspective than only GNOME?
> 
> A competing proposal I've heard is to just use ALSA directly.

I've got some notes on how to get hardware accelerated/network 
transparent mixing sorted out with minimal effort, which unfortunately I 
don't have here. I could post them in a few days, hopefully.

Basically:

- Write an alsa-lib plugin that by default just forwards the audio to
   the slave device (ie, is a no-op) but when a magic environment
   variable is set or whatever takes the audio and writes it to a
   socket created somewhere with the name == pid of process, ie

      /tmp/audio-mike/12345

   The alsa-lib configuration format allows passing environment vars
   as plugin parameters, ie it's all quite flexible with minimal policy
   hardcoded.

   Typically therefore you'd have the following alsalib plugin pipeline:

      default -> as-yet-unnamed-plugin -> [dmix] -> plughw:0,0

- Have a simple GStreamer app that monitors $MAGIC_DIRECTORY and
   when a new socket appears that is readable, connect to it and
   start downloading the audio direct from the app. You can then
   feed it via any GST pipeline you like; ie:

      fdsrc ! vorbisenc ! oggmux ! tcpsink

   (dunno the exact plugin names). Net result is sound-server policy
   is very flexible: you can have a dedicated "connect to me" style
   server or you can stream it via SSH or via X, or you can forward
   audio on a case-by-case basis.

- The key point is that in the common case of no network transparency
   you can take advantage of dmix mixing (so instant interop with all
   other ALSA supporting apps and OSS apps via the alsa LD_PRELOAD
   wrapper), and in the case of having a sound card that doesn't suck
   you can use hardware accelerated mixing/resampling as ALSA supports
   this natively.

- One issue I haven't considered is syncing with X, because I don't
   know anything about that. How often do people play movies over a
   remote X connection anyway?


The main catch is that it doesn't exist, I just made it up. Somebody 
would have to learn ALSA plugin programming then write 
as-yet-unnamed-plugin.  I don't have time, sorry :(

The other major catch is that obviously it's not portable. To be frank I 
don't care about this whatsoever - IMHO audio 
mixing/resampling/network-transparency is *not* a desktop level problem, 
it's an operating system level problem. If the sound system of other 
operating systems don't support automatic software mixing or network 
transparency then too bad. However I suspect a proposal based on 
leveraging ALSA would go down like a ton of bricks in most portable 
desktop projects. There's nothing inherantly unportable about the ALSA 
API, but people would still object.

Final catch: in Fedora Core 2 at least ALSA support still seems a bit 
buggy. I found running XMMS for long periods with the ALSA plugin caused 
a huge memory leak, and also after playing music for a while noise and 
corruption started leaking into the audio.

Here is the ALSA dmix bug:

http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=130593

thanks -mike