From alsa-devel-owner@alsa.jcu.cz  Wed Feb 10 11:45:46 1999
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 LAA21075;
	Wed, 10 Feb 1999 11:43:34 +0100
Date: Wed, 10 Feb 1999 11:43:34 +0100 (CET)
From: Jaroslav Kysela <perex@jcu.cz>
To: Data <data@havoc.gtf.org>
cc: alsa-devel@alsa.jcu.cz
Subject: Re: MIDI/PCM synchro
In-Reply-To: <199902101023.FAA26308@havoc.gtf.org>
Message-ID: <Pine.LNX.3.96.990210113211.3166F-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 Wed, 10 Feb 1999, Data wrote:

> System-wise the task is this: MTC consists (usually) of 'quarter-frame' 
> messages which must be output every 8.333.. ms or so - that's for 30-frame 
> SMPTE, I use 25-frame actually, which changes the interval a bit, but never 
> mind.  For a multitrack recorder, then, it's essential that these blips be 
> sent out exactly in sync with the sample data, and this must be doable on many 
> systems.
> 
> The obvious way to handle this is by watching a sample counter of some sort 
> and firing off an appropriate quarter-frame message when it reaches some 
> multiple.  This is tough to do properly in user-land because there's not much 
> guarantee that you'll have the thread when that time comes around.  So, you'll
> effectively get excessive jitter, and that would probably confuse things 
> pretty badly.
> 
> So, we have to do it in kernel-land for best performance (big surprise there).
> Now, this code has to know some things: what samples are being played, and 
> what time they're being played at, and what the current SMPTE time is 
> supposed to be.  So your MT program has to be able to tell the sync code 
> that this particular block of samples is being played starting at whatever 
> SMPTE time, or some such.  The object of the game then is to be sending out 
> the QFM just as the corresponding block of samples is being sent out the door.
> 
> It seems to me that the most appropriate thing to do would be to somehow make 
> use of the ALSA sequencer for timing and device communication; but new as I 
> am to ALSA, I've not yet got a feel for what would be best.  Also the 
> sequencer seems still to a bit spotty in some areas.  Any thoughts or 
> suggestions or flames or comments?

Maybe best way should be usage PCM device as timer. I think that Frank
mentioned this possibility in the sequencer proposal. It isn't implemented
to ALSA driver at current time.

							Jaroslav

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



