From alsa-devel-owner@alsa.jcu.cz  Sun Oct  4 20:02:55 1998
Received: from entry.jcu.cz (IDENT:perex@entry.jcu.cz [160.217.1.111])
	by marvin.jcu.cz (8.9.1a/8.9.1) with SMTP id UAA03143;
	Sun, 4 Oct 1998 20:02:27 +0200
Date: Sun, 4 Oct 1998 20:02:25 +0200 (CEST)
From: Jaroslav Kysela <perex@jcu.cz>
To: Andy Lo A Foe <arloafoe@cs.vu.nl>
cc: 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.3.96.981004191138.4361A-100000@entry.jcu.cz>
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

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.

It's true, but if you are mixing PCM streams and if user program write
some mixed data to PCM device, this queue can't be changed anymore. Thus
if some other process require output PCM samples at some small time after
- these samples will be delayed in final output (with data which are
already mixed in driver).

Driver can mix new arriving data directly to playback possition (exactly
in samples) - thus this delay will be shorted to minimum.

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

It's true, I mean little another thing (not scheduling). I mean problem
with main (final) PCM stream which I described above.

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

No, mixed PCM stream should be maintained only with kernel code (driver).

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

It's correct for standard codec chips. But we can use also hardware for
mixing without CPU activity (GUS) and in this case isn't possible give
user application to access to master mixed PCM stream which will not exist
in this case (it will be maintained by hardware).

						Jaroslav

-----
Jaroslav Kysela <perex@jcu.cz>
Academic Computer Centre, University of South Bohemia
Branisovska 31, C. Budejovice, CZ-370 05 Czech Republic


