From alsa-devel-owner@alsa.jcu.cz  Sun Oct  4 16:11:44 1998
Received: from smtp1.xs4all.nl (smtp1.xs4all.nl [194.109.6.51])
	by marvin.jcu.cz (8.9.1a/8.9.1) with ESMTP id QAA17259
	for <alsa-devel@jcu.cz>; Sun, 4 Oct 1998 16:11:28 +0200
Received: from orbital (arloafoe@orbital.xs4all.nl [194.109.37.98])
	by smtp1.xs4all.nl (8.8.8/8.8.8) with SMTP id QAA00891
	for <alsa-devel@jcu.cz>; Sun, 4 Oct 1998 16:11:24 +0200 (CEST)
Date: Sun, 4 Oct 1998 16:12:58 +0200 (CEST)
From: Andy Lo A Foe <arloafoe@cs.vu.nl>
To: alsa-devel@jcu.cz
Subject: Re: PCM mixing draft v0.2
In-Reply-To: <Pine.LNX.3.96.981004112921.4238H-100000@entry.jcu.cz>
Message-ID: <Pine.LNX.3.96.981004151632.343B-100000@orbital>
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, 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


