Subject: Re: [linux-audio-dev] latest audioengine snapshot (laaga proposal)
From: Paul Davis (pbd_AT_Op.Net)
Date: Fri Jun 15 2001 - 17:52:24 EEST
>OK, well that matches what I was imagining, exept I wanted a System
>Timebase "plugin" with a timebase output, e.g. a well known plugin with a
>well known port. If its possible, whats to stop a plugin existing which
>reads SMPTE sync from hardware and produces a timebase signal in the same
>format as System Timebase, just seems a bit more useful. Its really not
>important though.
system timebase has no useful zero reference point, so its not really
very useful for sync.
but yes, there's no reason to not have a plugin that reads SMPTE and
provides some kind of (useful or not) timebase.
however, i want apps to be able to sync without knowing about special
components that they have to connect to. that means using the engine
as a proxy.
>I don't understand the need for the time since interupt, but I'm
>prepared to take your word for it.
its pretty simple. imagine a huge interrupt interval (8192 frames, or
162ms @ 48kHz). We update a screen display with a moving cursor over a
waveform, every 100ms. We need to know where to put the cursor. We
check for the current_audio_frame, which is only updated every
162ms. We draw the cursor in the wrong place. The cursor has to be
drawn at the frame that the user is hearing. thats:
current_audio_frame + frames_since_interrupt - hw_latency_frames
This effect used to be quite noticeable in ardour before i added the
correction. You'd hear a drum hit, and the cursor would pass over it
1/10th of a second later.
>I'm not sure what you mean by defined. I think that at some point we need
>a standard data representation for things like that, otherwise it will be
>a disaster. A MIDI data representation would probably do though.
Well, I don't see any need to have LAAGA itself define a timebase
other than audio frames since "zero". Clients can agree to use
#include <steve_harris_timebase_struct.h>, and share a timebase that
way if they want to use a more structured approach. but any such
timebase is inevitably either the same or worse resolution than audio
frames, so it doesn't seem like it needs to be part of LAAGA. the
library, or a library, can provide functions for audio-frames =>
SMPTE/MTC/etc. but LAAGA wouldn't provide SMTPE/MTC/etc data
itself.
--p
This archive was generated by hypermail 2b28 : Fri Jun 15 2001 - 17:49:59 EEST