[linux-audio-dev] XAP and these <MEEP> timestamps...

David Olofson david at olofson.net
Sat Dec 14 19:11:01 UTC 2002


On Sunday 15 December 2002 00.26, Paul Davis wrote:
> >A nice question to ask is 'what is time'. I suppose that there is
> > a direct correlation between time and sample frequency; but what
> > to do with non-constant sample frequency? (This is not a
> > hypothetical situation, since a sampled system which is
> > synchronised to an external source, could be facing variable
> > sample rate - when slaved to a VCR for instance). I believe the
> > answer lies in definition of which is your time master, and use
> > that as such; so in case of the slowed down VCR, the notion of
> > time will only progress slower, without causing any trouble to
> > the system. If no house clock or word clock is availble, things
> > might end up hairy...
>
> i believe, though i am not certain, that you are confusing two
> different kinds of synchronization. there is:
>
>     * positional synchronization ("where are we?")
>     * sample clock synchronization ("how long between samples?")
>
> they are not related to each other in *any* way, AFAIK.

Well, they could be "related", I think... (Read on.)


> synchronizing position with a VCR via SMPTE (for example) has
> nothing to do with sample clock sync. likewise, a word clock
> connection between two digital devices has nothing to positional
> synchronization.

Good point. One could say that every sync source generates one of 
these:
	* timing data (tempo, sample clock,...)
	* positional data (song position, SMPTE,...)

Positional data sort of implies that you can extract timing data as 
well, provided you get a stream of positional data with sufficiently 
accurate timing.


Anyway, in that other post, I think I said there *is* a relation 
between all of these, but I forgot to explain why:

	* Audio device syncs to wordclock
	* Sequencer uses audio for timing (nominal sample rate assumed)

Note that both are just *sync* - not lock. If you wanted to sync with 
a VRC, you would most probably be using SMPTE instead of wordclock - 
and then, it would make a *lot* more sense to sync + lock the 
sequencer to that, and just let the audio interface do 48 kHz, or 
whatever you like.


Either way, the point I was trying to make still stands; by the time 
the host starts calling all plugins to process one block of data, 
*all* information the plugins will access must *static* - or you will 
have plugins that run in "parallel" mysteriously fall out of sync.

So, the sequencer (which will obviously be one of the first plugins 
in the graph, if not integrated in the host) will have to figure out 
the SMTPE, audio, MIDI clock or whatever it's syncing or locking to 
for the first sample of the block, construct the timeline info for 
the block, and pass it to the plugins that want it.

At this point, all is decided. Sync and lock has been applied, and 
for all practical matters, you may consider this block property of 
the audio hardware; you just have to do some audio processing to 
generate the actual data.


> so, slaving to a positional reference has no effect on sample
> rate.

Well, it *could*, if you assumu that one SMPTE frame corresponds to N 
samples... ;-)

Not much point, though - you would only end up modulating the tempo 
of the still free running sequencer, as well as the pitch of any 
audio you generate. :-)


> conversely, slaving to a sample clock source has no effect on
> positional tracking. word clock does make variable sample rate
> possible, and indeed some systems use it to implement sync'ed
> varispeed. but its definitely not a consequence of using a
> positional reference like SMPTE or MTC. when slaving to those
> signals, the sample rate remains constant (all other things
> remaining the same), and all that changes are the notions of "where
> we are?" and "how fast are we moving?" and "what direction are we
> moving in?". the same number of samples are processed every second,
> but what those samples contain will vary with the positional
> reference.

This is a great explanation, IMHO.


//David Olofson - Programmer, Composer, Open Source Advocate

.- The Return of Audiality! --------------------------------.
| Free/Open Source Audio Engine for use in Games or Studio. |
| RT and off-line synth. Scripting. Sample accurate timing. |
`---------------------------> http://olofson.net/audiality -'
   --- http://olofson.net --- http://www.reologica.se ---



More information about the Linux-audio-dev mailing list