Re: [linux-audio-dev] timebases and sync in LAAGA

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: Re: [linux-audio-dev] timebases and sync in LAAGA
From: Paul Davis (pbd_AT_Op.Net)
Date: Mon Jun 18 2001 - 20:12:24 EEST


>Is it right to assume that in the case you described, the audio i/o client
>would provide the timebase (current frame) and at the same time would adapt
>the playback speed of the audio out interface based on the SMPTE input.
>(through interpolation/sample insertion/skipping) ?

if the audio i/o client believes that the interface doesn't play at
the correct speed, then yes, it will need to do some correction. i
don't believe that anyone serious about SMPTE will be using interfaces
where this condition is sufficiently noticeable that the client needs
to worry about it.

>Ok for the alarm bell.
>But assume that the softsynth wants to play a sampled loop which must
>stay perfectly in synch with the background music that is already recorded on
>the video tape ?
>
>Assume the loop starts at time 0:15 (mins: secs) (at frame 661500) , and
>ends at 0:25 (duration = 10secs, 441000 frames )
>(samplerate = 44.1kHz)
>
>What's the best way to do this from the softsynth (or a HDR playback engine)
>perspective ?

if the interface is driving the engine, and the interface runs at the
correct speed, then nothing needs to be done.

if the interface does not run at the correct speed, there are a couple
of choices:

   1) the audio i/o client understands how to adapt playback speed so
        that the "correct" N samples are emitted in each second.
        this may not be easy to do :)
   2) the user buys h/w capable of doing the right thing.

>Personally I would put the softsynth in slave mode where it gets the current
>song position (in frames) from the audio i/o client (which adapts playback
>speed of the soundcard to stay in sync with the video timebase).
>That way even if the reference timebase varies, the loop generated by the
>softsynth/HDR engine would still be perfectly in sync without needing to care
>about timing (from the softsynth POV).
>
>Does this make sense ?

yes, if you're going to insist on being able to use an interface
incapable of generating 44.1 samples/sec at 44.1kHz :)

>> if you wish to aggregate multiple audio h/w into a single
>> driver/client, use ALSA's PCM "multi" device.
>
>Interesting.
>I was not able to follow ALSA development lately, can you (or any other ALSA
>developer (Abramo,Jaroslav?)) briefly explain us how this works and what
>kind of capabilities the "multi" PCM devices offer ?

I'm afraid I can't. Abramo is the only one who can do this. AFAIK,
support for inter-card keep-in-sync is not present in the current
implementation. Abramo's the person to check with on this.

>Understood.
>I assume the LAAGA API will provide a way to speficy which client produces
>the reference timebase, right ?

audioengine_takeover_timebase().

its assumed that this will be called in response to user-action
(e.g. clicks on "Become Clock Master").

>> 2) IMHO, people who want to do this are wasting their time
>> and the programming community's time.
>
>In what sense ?
>That for serious recording you should use only pro-audio hw that has
>hardware based sync support so that the problem does not arise ?

Yep. The expectation that two devices driven by different clocks
should (or even can) remain in sync is widely derided in (digital)
audio manuals and books. People using computer audio interfaces should
read them and take the lesson to heart. We happen to be able to hack a
s/w solution that will drop samples from time to time, or whatever;
that doesn't mean its a good idea.

>If you meant this then I do agree, but there are lots of hobbists doing
>recording sessions and they perhaps would like to use their two
>el-cheapo soundcards simultaneously.

Tough. They'll have to convince Abramo or some other clever programmer
to implement the sync/drift code in ALSA. They'll never convince me to
do it, thats for sure :)

--p


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Mon Jun 18 2001 - 20:12:25 EEST