Subject: [linux-audio-dev] Re: Sync Issues (was Re: External MIDI Sync using OSS/Free)
From: David Olofson (audiality_AT_swipnet.se)
Date: pe loka 29 1999 - 17:01:31 EDT
On Thu, 28 Oct 1999, Billy Biggs wrote:
> > Do not forget to apply the lowlatency patches, or your timing will
> > simply suck ! even an untuned IDE disk, when it reads/writes a small
> > amount of data from/to the disk, could cause 20-50ms delay in your app
> > and this is very bad for MIDI. ( see my tests , especially the non DMA
> > ones = horrible :-) )
>
> What lowlatency patches?? kernel patches?? That's just ugly. Where
> can I get them?
There's no way you'll ever have real time performance in a non-RT
system... The pre 2.2 and 2.2 "RT" was flawed, and close to useless,
so it had to be fixed. As far as we have seen, the patch has no effect
on, or even improves performance of non-real time stuff. The patch is
not an uggly RT scheduling hack, but a quite clean and very useful
improvement. (Especially to us audio guys, and to multimedia folks in
general. :-)
> How can you tell if you've underrun under OSS? Using ALSA, I guess you
> can use it's time stuff to calculate if you've missed a frame, but even
> that seems hacky.
Waitaminnit'... "Underrun" is a severe error condition, and must
never occur in a real time system. What you need to know is when you
can throw in another buffer. Before generationg the buffer, you also
need to know exactly when it will be played, in relation to your
time base.
> I don't like using one dsp as the sync master since I always want to be
> able to sync to something external, like MIDI.
Sync master, no; bad idea. *Timing* master is different, though. You
have to decide on one single sample rate to use in your engine, and
that one is easiest derived from the timing master card. This card's
play position is what you use as your system time base.
> So, the problem becomes, how do you sync many soundcards and have it all
> synced off external MIDI. :)
You could run one engine/card, and just translate all "MIDI event"
timestamps (the ones you set when you recieve the events) to the time
base of the engine each one is sent to.
Or you have only one engine thread, running at the sample rate of
the timing master card, resampling all data that doesn't match that
sample rate. That would include any streamed audio tracks, as their
playback rates would have to follow the external MIDI clock.
Alternatively, you run the engine at the sample rate of the audio
tracks, and resample for *all* audio cards. However, that;
1) ...doesn't make much sense unless all audio tracks are recorded
with the exact same sample rate. (Which will *not* be the case
if they were recorded on different cards!)
2) ...means you have to resample for all cards, including the one
that still actually acts as timing master, in that your engine
syncs to it.
3) ...results in weird buffer sizes through the engine. (You do
the math here; I've seen enough of that variant, I think...)
So, timing master is one thing, sync master is another. You can see
it as the engine running at a fixed rate no matter what you do,
resampling data and adjusting the sequencer/automation tempo as needed
to follow the external sync clock.
//David
·A·U·D·I·A·L·I·T·Y· P r o f e s s i o n a l L i n u x A u d i o
- - ------------------------------------------------------------- - -
·Rock Solid David Olofson:
·Low Latency www.angelfire.com/or/audiality ·Audio Hacker
·Plug-Ins audiality_AT_swipnet.se ·Linux Advocate
·Open Source ·Singer/Composer
This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:28:00 EST