Re: Polypaudio for Gnome 2.10, the next steps

[Mike Hearn <mike navi cx>]

On Mon, 22 Nov 2004 19:26:08 -0500, Colin Walters wrote:
> Hm, neat.  It does work, but I get constant underruns, and sound quality
> is very audibly degraded even in the one-app case.

What card do you have? I don't suffer that problem here. I have an
i810/AC97 chipset which is known to be super-evil to support. Actually I
think that's just the name of a family of chipsets, alsamixer says this:

Card: SiS SI7012
Chip: Realtek ALC100/100P rev 38

It's possible there is some manual configuration needed and I just got
lucky with the defaults.

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

I'm not sure either. Presumably it must do so, but I've heard reports of
dmix hanging the audio pipeline. And in fact sometimes XMMS just stops for
no obvious reason, maybe that's what's happening.

I find it hard to believe they'd have implemented this without carefully
thinking through the locking. You can see the code here:

http://cvs.sourceforge.net/viewcvs.py/alsa/alsa-lib/src/pcm/pcm_dmix.c?rev=1.57&view=auto

Looks like it's using an IPC semaphore with some kind of mediator server
process. 

> 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.

Yeah. If the app is using GStreamer you can have a ton of intelligence
behind its back.
 
> Re-compressing it does suck though if e.g. your data is Vorbis, and your
> thin client supports decoding Vorbis.

Yeah but in the non-gstreamer case I don't think it can be avoided easily.
At least not without rewriting lots of software, and that is what
the proposal is all about. Though Lennart has done a good job of writing
drivers for every media framework known to man ....

thanks -mike