From alsa-devel-owner@alsa.jcu.cz  Sun Oct  4 20:54:34 1998
Received: from ns.anet.cz (ns.anet.cz [194.50.6.66])
	by marvin.jcu.cz (8.9.1a/8.9.1) with ESMTP id UAA07223;
	Sun, 4 Oct 1998 20:53:26 +0200
Received: from smtp3.xs4all.nl (smtp3.xs4all.nl [194.109.6.53])
	by ns.anet.cz (8.9.1/CESNET/roman) with ESMTP id UAA25399;
	Sun, 4 Oct 1998 20:53:27 +0200
Received: from orbital (arloafoe@orbital.xs4all.nl [194.109.37.98])
	by smtp3.xs4all.nl (8.8.8/8.8.8) with SMTP id UAA08391;
	Sun, 4 Oct 1998 20:52:08 +0200 (CEST)
Date: Sun, 4 Oct 1998 20:53:35 +0200 (CEST)
From: Andy Lo A Foe <arloafoe@cs.vu.nl>
To: Jaroslav Kysela <perex@jcu.cz>
cc: alsa-devel@jcu.cz
Subject: Re: PCM mixing draft v0.2
In-Reply-To: <Pine.LNX.3.96.981004191138.4361A-100000@entry.jcu.cz>
Message-ID: <Pine.LNX.3.96.981004203027.2573C-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:

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

I think this can be solved if mixing is done in user space.

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

In user space the PCM data should get mixed right before the low watermark
level is reached. The delay is thus dependand on your fragment size and
your watermark levels, not unreasonable IMHO. And this is the output delay 
only (the problem with delayed mixing of PCM streams should not even
exist). The audio server/daemon, which does the mixing, should of course
have "real-time" priority to achieve this. I've played with "real-time"
scheduling in AlsaPlayer and got quite good results with it. The Linux
scheduler needs some modifications to handle these "real-time"
processes better. Incidentally this is one of the bigger threads
on the linux-kernel list right now! If you want to check the "real-time"
stuff just execute AlsaPlayer with root permission (you will have to trust
me since it's a binary :) You will notice virtually no delay when playing
with the pitch slider for example...

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

Okay..

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

And what if we could export this extra hardware functionality
to user space via the library? It would allow us to be much more flexible. 

As soon as I've got a semi-working AlsaPlayer I'll start experimenting
with user space mixing (threading and shared memory access come to mind)..

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


