Subject: Re: [linux-audio-dev] App intercomunication issues, some views.
From: Paul Davis (pbd_AT_op.net)
Date: Wed Jul 24 2002 - 14:44:58 EEST
>/wrote Paul Davis <pbd_AT_op.net> [Tue, 23 Jul 2002 19:58:16 -0400]
>
>|the most fundamental problem with SGI's approach to audio+video is
>|that its not based on the desirability of achieving low latency for
>|realtime processing and/or monitoring. its centered on the playback of
>|existing, edited, ready-to-view material. the whole section at the end
>|of that page about "pre-queuing" the data makes this point very clear.
>|
>|SGI tried to solve the problem of the Unix read/write API mismatch
>|with realtime streaming media by adding timestamps to data. CoreAudio
>|solves it by getting rid of read/write, and acknowledging the inherent
>|time-basis of the whole thing, but for some reason keeps timestamps
>|around without using them in many cases. JACK follows CoreAudio's
>|lead, but gets rid of the timestamps.
>
>My concern is audio+video synchronization:
> Currently, i'm using the audio clock, snd_pcm_status_get_tstamp or
> ioctl(fd, SNDCTL_DSP_GETOPTR, ¤t_ptr) to provide a timestamp
> at the start of the video processing..
>
> With JACK's api not providing a timestamp, I cannot know
> whether there's any extra buffering/latency
> added once the callback buffer is processed..
> (which would be the case of rather braindead hardware or driver)
JACK provides both current time and information on the latency
(potentially much more complete latency information than with most
other systems). The time information is only valid if a client has
volunteered to provide it, because the time is "transport time", which
is what you're really interested in. The latency information is valid
all the time. Its possible to create some connection graphs that make
it hard for JACK to return the "correct" answer to the port latency,
since there isn't a single answer.
> ... It also requires me to keep a local clock that i would
> empirically correct by one buffer_size, as set by
> the jack_set_buffer_size callback, in the hope it corresponds
> with the actual delay between processing and the actual time
> sound will be heard. This is critical for audio/video
> synchronization, whichever the latency the system is aiming for.
>
> am I at least right in my assumption?
no, i'm afraid you're wrong.
synchronization between two streaming clocks that run at different
speeds related by a non-integer ratio is always hard. but JACK doesn't
make it any harder, and it (correctly, IMHO) currently forces use to
the higher resolution clock (from the audio interface) to control the
passage of time.
i believe that the way to handle synchronization in the case you
describe doesn't involve timestamps at all, certainly not stamps
provided by the device driver interface.
--p
This archive was generated by hypermail 2b28 : Wed Jul 24 2002 - 14:58:53 EEST