From alsa-devel-owner@alsa.jcu.cz  Sun Oct  4 20:04:54 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 UAA03305
	for <alsa-devel@jcu.cz>; Sun, 4 Oct 1998 20:04:51 +0200
Received: from localhost (spidey@localhost)
	by viper.dodds.net (8.8.7/8.8.7) with SMTP id NAA23727
	for <alsa-devel@jcu.cz>; Sun, 4 Oct 1998 13:04:45 -0500
Date: Sun, 4 Oct 1998 13:04:44 -0500 (CDT)
From: Stephen Webb <spidey@dodds.net>
To: alsa-devel@jcu.cz
Subject: Re: PCM mixing draft v0.2
In-Reply-To: <Pine.LNX.3.96.981004151632.343B-100000@orbital>
Message-ID: <Pine.LNX.4.00.9810041254140.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

Two things about this. The mixing needs to be done in user space. The
second have you guys seen how EsounD is coming along! It has alot of
things you guys have been talking about. Maybe you can integrate it or
just some of its ideas! 

It is already can use Alsa but it will only use one card and other things.
It needs some work on the interface to alsa but overall it looks good. 

I would just sugest that you work on the Alsa and esound working together
better. Than Bloating the kernel with stuff (if you put mixing stuff in
kernel space) and two Esound works well, it is effient, and has lots of
toys.

One more things I am not saying that you will not need some helper
functions in the kernel space but please Don't put the mixing in there. If
you do there are better options(that is for my setup)

Stephen

P.S. This are only my opinions not hard fact. It is just something for you
guys to chew on!

On Sun, 4 Oct 1998, Andy Lo A Foe wrote:

> On Sun, 4 Oct 1998, Jaroslav Kysela wrote:
> 
> >     ALSA driver already supports all features which are needed for exclusive
> > access to PCM devices. Modern sound driver needs ability of realtime mixing
> > of independend PCM streams. Mixing should be done in user space or in kernel
> > space. Unfortunately user space have some limitations for which this
> > implementation isn't very good:
> > 	1) user code doesn't know precise current position in stream
> 
> How is this? If you have a fragment size of 2K and you set an upper
> watermark level of 6 buffers and a lower for 1, doesn't it mean that at
> the moment you can put something in the buffer there is 5 x 2K amount
> of PCM data waiting to be played? But this may be wrong as I don't know
> the real internal workings of the driver.
> 
> > 	2) user code may deliver samples to kernel space delayed
> 
> But a user program must produce the PCM data. This might also be delayed
> (by too low a scheduling priority maybe of the process) so isn't
> that a bigger problem?
> 
> > 	3) user code doesn't have access to hardware and use optimal mode
> >            for data transfers and playback (GUS cards)
> 
> Okay..
> 
> >    ALSA implementation leaves some code to user space. In user space should
> > be code for conversion to mixing format, rate and adding some digital
> > effects (echo, 3D etc..).
> 
> Yep.
> 
> >    As transfer method between user space and kernel space will be used
> > mmaped access. This means that application will write samples directly
> > to driver's buffer (this shouldn't be hardware buffer of necessity).
> > This eliminates one copy of samples.
> 
> Will it be possible to give user processes access to the mixed PCM sample
> stream? This would allow cool things like for example adding global echo
> effects (over all PCM streams). The current proposal gives each process
> that wants to output data a separate buffer (in driver space) and the
> kernel will mix these buffers into one signle PCM stream before
> outputting it to the hardware, correct? 
> 
> More to follow once I read everything...
> 
> Andy
> --
> Andy Lo A Foe, arloafoe@cs.vu.nl |  Linux v2.1.122  | PII 233 
> http://www.cs.vu.nl/~arloafoe    | GSM: 0622-440695 | Bebox 133
> http://orbital.xs4all.nl/andy    |   ICQ: 7472949   | IRC: Adnans
> 
> ------
> To unsubscribe from <alsa-devel@alsa.jcu.cz> mailing list send message
> 'unsubscribe' in the body of message to <alsa-devel-request@alsa.jcu.cz>.
> 


