Re: Polypaudio for Gnome 2.10, the next steps

[Colin Walters <walters redhat com>]

On Tue, 2004-11-23 at 00:09 +0000, Mike Hearn wrote:
> On Mon, 2004-11-22 at 19:01 -0500, Seth Nickell wrote:
> > Substantially, I agree with Mike. It seems like this problem should be
> > solved at the Alsa layer. In fact, Alsa already has this implemented, we
> > just need to have it setup by default on cards that don't support
> > hardware mixing.
> 
> It's getting easier. For Fedora Core 3 the only change I had to make was
> putting this in /etc/asound.conf:
> 
> pcm.!default {
>         type plug
>         slave.pcm "dmix"
> }

Hm, neat.  It does work, but I get constant underruns, and sound quality
is very audibly degraded even in the one-app case.

> Unfortunately alsalib is still substantially buggy at least on my
> chipset (which I admit is the chipset from hell). Hopefully they'll get
> there soon.

Could be general alsalib bugginess too.  It's not entirely clear to me
how the dmix/asym shared memory approach avoids locking issues.

> Actually grabbing the audio at the gstreamer layer has the problem that
> only gstreamer apps can do remote audio which would not make the LTSP
> people very happy. It'd be like the situation where only gnome-vfs apps
> can access remote servers from the file picker.

Ideally you can do both of course; for GStreamer you have a special
gstremotesink which can do negotiation over the network, and in the non-
GStreamer case just send uncompressed audio over, or I guess compress it
again.

> The proposal sent to fedora-devel-list outlines one way in which
> [nearly] all applications on Linux could expose their audio output in a
> flexible way, that'd allow some arbitrary application to pick it up, mix
> it, compress it,

Re-compressing it does suck though if e.g. your data is Vorbis, and your
thin client supports decoding Vorbis.