From alsa-devel-owner@alsa.jcu.cz  Sun Oct  4 23:25:05 1998
Received: from viper.dodds.net (IDENT:spidey@storms-177-214.res.iastate.edu [129.186.177.214])
	by marvin.jcu.cz (8.9.1a/8.9.1) with ESMTP id XAA19242;
	Sun, 4 Oct 1998 23:24:32 +0200
Received: from localhost (spidey@localhost)
	by viper.dodds.net (8.8.7/8.8.7) with SMTP id QAA03727;
	Sun, 4 Oct 1998 16:24:29 -0500
Date: Sun, 4 Oct 1998 16:24:28 -0500 (CDT)
From: Stephen Webb <spidey@dodds.net>
To: Jaroslav Kysela <perex@jcu.cz>
cc: alsa-devel@jcu.cz, ericmit@ix.netcom.com, scorpio@dodds.net
Subject: Re: PCM mixing draft v0.2
In-Reply-To: <Pine.LNX.3.96.981004205308.4361J-100000@entry.jcu.cz>
Message-ID: <Pine.LNX.4.00.9810041602580.15043-100000@viper.dodds.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Reply-To: alsa-devel@alsa.jcu.cz
Sender: alsa-devel-owner@alsa.jcu.cz
Precedence: list


	Hi, I'm Bibek Sahu <scorpio@dodds.net> stealing Steve's account
for this message, since I'm not on this list.

On Sun, 4 Oct 1998, Jaroslav Kysela wrote:

> OK. I must still ask why we cannot mix data in kernel space? EsounD mixing
> daemon _CAN_ use this ALSA PCM mixing interface described in draft. This
> interface is designed mainly for most efficient way to deliver one stream
> to soundcard with minimum delay when data comes to playback.

	My personal view is to have kernel mixing as an _option_.  In the
case of something like the GUS, there are advantages to having driver
level mixing support.  On the flip side, I only have a single SB AWE64
Gold and would really rather the driver not be less efficient by having in
it code to do stream mixing.  Esound does this for me.

	If I can select _at compile time_ whether or not to include driver
mixing support, then I'm all for adding the support.  I'll probably build
the driver without it most of the time, but I like the idea of having the
support.

	You mentioned in a previous message that there will not be support
for doing anything to a stream after it has been mixed, whereas I'm
working on filter support for esound which will eventually make its way
into the cvs and an official esound release.  In the case of using a
filter, esound has support that this driver implementation does not have.
Also, in this case esound cannot use the driver's mixing capabilities
because there's no way to get the data back before sending it to a filter.

> Current EsounD daemon reads data from streams over net and it is doing
> mixing, effect adding and output to exclusive device.

	Quite true...

> EsounD daemon with ALSA PCM mixing interface should do same function, but
> it should use for mixing ALSA driver which can use for mixing hardware (if
> possible).

	And if this actually goes through, I might even look into adding
support for it myself, for the situation where there are no filters.  As
mentioned above, this won't work when filters are being used.

	However, since as I said I'd prefer it possible to disable this at
compile time, there probably ought to also be a way to find out (via.
alsalib?) whether or not it's enabled.

> But if author of EsounD have some other meaning we can talk about this...

	Well, I'm certainly not the author, but I have been doing quite a
lot with it.

- Bob

PS: the esound cvs has preliminary support for picking the first available
card under alsa.  As I only have one card, I haven't been able to test it
much to see if it works yet (though it's based on what I found in aplay,
so I _hope_ it works... ;-).  If someone with multiple cards would test it
and get back to us, I would much appreciate it. :-)


