From alsa-devel-owner@alsa.jcu.cz  Wed Feb 10 11:25:16 1999
Received: from havoc.gtf.org (IDENT:data@panic.ohr.gatech.edu [130.207.47.194])
	by marvin.jcu.cz (8.9.1a/8.9.1) with ESMTP id LAA19261
	for <alsa-devel@alsa.jcu.cz>; Wed, 10 Feb 1999 11:23:12 +0100
Received: (from data@localhost)
	by havoc.gtf.org (8.8.7/8.8.7) id FAA26308
	for alsa-devel@alsa.jcu.cz; Wed, 10 Feb 1999 05:23:06 -0500
From: Data <data@havoc.gtf.org>
Message-Id: <199902101023.FAA26308@havoc.gtf.org>
Subject: MIDI/PCM synchro
To: alsa-devel@alsa.jcu.cz
Date: Wed, 10 Feb 1999 05:23:06 -0500 (EST)
Content-Type: text
Reply-To: alsa-devel@alsa.jcu.cz
Sender: alsa-devel-owner@alsa.jcu.cz
Precedence: list


Hello all,

I'm new to this list, and having perused the archive, feel satisfied that this 
issue hasn't been addressed in some time; so please forgive me if I'm wasting 
bandwidth :)

Right, so I'm thinking of writing a multitrack hard-disk recorder.  I've got 
B. Nagels' program Multitrack running right now but I can't trick it into 
running on ALSA (I think this was due to the 2-soundcard bug, maybe I'll try 
it again).  The difficulty with this program is that Mr. Nagels seems awfully 
reluctant to release his code, and it won't put out MIDI Time Code.  Hence 
my thinking of writing one that _can_ (plus I think I can do it a bit 
better maybe :) )

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?

Cheerio
Michael Ashton



