From alsa-devel-owner@alsa.jcu.cz  Mon Oct  5 00:28:42 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 AAA24181;
	Mon, 5 Oct 1998 00:28:04 +0200
Date: Mon, 5 Oct 1998 00:28:01 +0200 (CEST)
From: Jaroslav Kysela <perex@jcu.cz>
To: Andy Lo A Foe <arloafoe@cs.vu.nl>
cc: alsa-devel@alsa.jcu.cz
Subject: Re: PCM mixing draft v0.2
In-Reply-To: <Pine.LNX.3.96.981004203027.2573C-100000@orbital>
Message-ID: <Pine.LNX.3.96.981004223424.4361N-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:

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

OK. Looks like main problem is good scheduler. I see that in both cases is
main delay caused by task scheduler now. Current Linux scheduler is
probably limited with system clock (100Hz on i386). This means that delay
should be up to 20ms (or I missed something?). Other delay should be added
by effects, filters, conversions etc, but this must be done in both cases.

**************************************************************************
OK. People, I'm postponing this feature and marking as 'it will be
implemented only if future will show that this is right way'...
This was only thought from me... Back to safe user space...
**************************************************************************

Thank you to all for replies to this theme...

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

This functionality is already supported via exlusive PCM interface for GUS
soundcards (only channel volume and panning should be added for better
support)...

						Jaroslav

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


