From alsa-devel-owner@alsa.jcu.cz  Thu Feb 11 01:23:20 1999
Received: from post.mail.nl.demon.net (post-10.mail.nl.demon.net [194.159.73.20])
	by marvin.jcu.cz (8.9.1a/8.9.1) with ESMTP id BAA19041
	for <alsa-devel@alsa.jcu.cz>; Thu, 11 Feb 1999 01:23:16 +0100
Received: from [212.238.75.184] (helo=obelix.vande-pol.demon.nl)
	by post.mail.nl.demon.net with esmtp (Exim 2.02 #1)
	id 10AjuU-0003UJ-00
	for alsa-devel@alsa.jcu.cz; Thu, 11 Feb 1999 00:23:14 +0000
Received: (from frank@localhost)
	by obelix.vande-pol.demon.nl (8.8.7/8.8.7) id BAA22149
	for alsa-devel@alsa.jcu.cz; Thu, 11 Feb 1999 01:18:47 +0100
From: Frank van de Pol <frank@vande-pol.demon.nl>
Message-Id: <199902110018.BAA22149@obelix.vande-pol.demon.nl>
Subject: Re: A Proposal [was: Re: MIDI/PCM synchro]
To: alsa-devel@alsa.jcu.cz
Date: Thu, 11 Feb 1999 01:18:47 +0100 (MET)
In-Reply-To: <199902102244.RAA19320@havoc.gtf.org> from "Data" at Feb 10, 99 06:29:57 am
Content-Type: text
Reply-To: alsa-devel@alsa.jcu.cz
Sender: alsa-devel-owner@alsa.jcu.cz
Precedence: list

Data wrote:
> 
> > 
> > I think this feature will be very useful for all applications where should
> > be synchronized audio stream with MIDI stream.
> > 
> > 							Jaroslav
> 
> .. and I've just come up with an idea for how to do it.
> 
> The process would operate as follows:
> 
> 1. A capability would be added to the upper-level PCM drivers.  The user 
>    could request that the driver send a timing message to the sequencer 
>    once every n samples.  For example, to send 30 fps quarter-frames with 
>    a 44.1 KHz sampling rate, the driver would send a message of some sort 
>    to the sequencer every 367.5 samples.  For accuracy the user 
>    could request fractional intervals, and the driver would interpolate 
>    accordingly.
> 
> 2. The user would then tell the sequencer that it was being externally 
>    clocked, and the sync source would be the PCM driver.
> 
> 3. When playback commences, the user first tells the sequencer to use a 
>    certain SMPTE offset, then to start playing.  The sequencer would 
>    reset its internal data to reflect the requested time, and begin 
>    waiting for timing messages from the PCM driver.
> 
> 4. The user then begins shovelling off bytes to the PCM driver.  When this 
>    happens the driver begins sending timing messages since it is now 
>    playing samples.

This looks good, and is indeed the most generic way for syncing the ALSA
sequencer to an external source. The SMPTE (or MTC) QFrame message contain
enough info to construct a full timestamp. This incoming timestamp will be
used to adjust the timer's current time. Once the ALSA sequencer timers
(seq_timer.c) allow external sync, we can accept many sources: audio
playback/recording, SMPTE, MTC, and (by adjusting tempo instead of time)
also midi clock. See <http://www.vande-pol.demon.nl/alsa/node5.html> for
the description of some of my ideas on this issue.

In your scenario the PCM devices would act as a timing source. The problem
would be to have the codecs (which are often playing using DMA) send out the
timing events at required rate (as for MTC). A more practical approach would
be to have the PCM device send out 'some' (complete) timestamp event when it
want to (eg. every few interrupts, at a pace of approx 10 Hz or better if
one wants to - it is basicly up to the PCM driver). This "Current time is
xxxxxxx" message is to be send (schedule time = NOW) to the sequencer timer,
and this timer will slowly/fast adjust current time to match the received
timestamp.

This 'PCM timing source' scheme can be implemented as a (kernel) sequencer
client which has a port for each of the PCM devices present in the system.
These ports are only capable of sending out timing events (time stamps,
start, stop).




Next part is basicly "sending out sync data to clients, ie. acting as timing
master". this can been seen separate from first part.
 
> 5. The sequencer would then begin sending timing messages to its clients.  
>    For a hard disk recorder one of these would generate MTC messages and 
>    route them to a MIDI output.
> 
> 6. When playback stops, the user ceases to feed the PCM driver with data, 
>    and then issues a 'stop' command to the sequencer, which leaves off 
>    waiting for timing messages.
> 
> Latency here would be minimal, but in the case of MTC, timing errors can be 
> corrected anyway, by applying small offsets to the SMPTE offset passed to the 
> sequencer.
> 
> Any reactions?

:-)


+---- --- -- -  -   -    - 
|Frank van de Pol                  -o)
|Frank@vande-pol.demon.nl          /\\
|                                 _\_v
|Linux - Why use Windows, since there is a door?
|
|ALSA Sequencer: http://www.vande-pol.demon.nl/alsa/

