Subject: Re: [linux-audio-dev] latest audioengine snapshot (laaga proposal)
From: Steve Harris (S.W.Harris_AT_ecs.soton.ac.uk)
Date: Thu Jun 14 2001 - 16:55:48 EEST
Thanks for the explanation of MTC and co.
On Wed, Jun 13, 2001 at 05:47:26PM -0400, Paul Davis wrote:
> >I'm still not sure this should be an API, couldn't it be implemented by
> >connecting to a timebase output port? Or is there a good reason not to do
> >this?
>
> Well, we could, but that then means you need to write "special code"
> to read it:
Yep, agreed it is more complicated, but, its less of a special case, and
it allows for multiple timebases cleanly. On the downside it makes it more
complicated for hte use, as htey have to wire up the sync port on the app
to a source, though it would make it clearer which things are free running
and which are synced.
I was imagining that the library would provide a timebase decoding
function, or that the buffer pased to process could just be a c
struct or whatever.
Although MIDI Clock is not a proper timebase, applications often try to
sync to it in the same way as they do MTC's bars:beats:frames mode, though
I'm not sure what the low level representation of that is.
> note that apps that respond to the timebase have to be very
> careful. if you are in the process() call and you notice nonlinear
> motion in the timebase, you cannot respond to it from within that
> thread unless you can do so in an RT-compliant way. ardour goes to
> great lengths, for example, to run all "transport control" in a
> temporary thread created specifically for that purpose. its not
> impossible that this could be part of the API one day - you provide a
> callback to audioengine_open(), and its executed in a non-audio thread
> when nonlinear time is detected. but thats for the future.
Yes, I hadn't considered that. I was thinking of things that would just
unlock if they noticed timebase jumps, eg. synced delays.
- Steve
This archive was generated by hypermail 2b28 : Thu Jun 14 2001 - 17:52:57 EEST