Re: [linux-audio-dev] App intercomunication issues, some views.

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

Subject: Re: [linux-audio-dev] App intercomunication issues, some views.
From: .n++k (Knos_AT_free.fr)
Date: Wed Jul 24 2002 - 15:28:52 EEST


/wrote Paul Davis

| >/wrote Paul Davis <|@op.net> [Tue, 23 Jul 2002 19:58:16 -0400]
| >
| >|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, &current_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.

Thanks, indeed! I hadn't seen the jack_port_get_total_latency call
which provides me with enough information to solve the synchronization
issue i have between audio and video..

|
| > ... 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.

Well, perhaps i shouldn't use the term 'synchronization' ... since my
problem is only a sub-problem of the one most people encounter. I
don't have a video clock, since the video is more synthetized than
streamed: the audio clock is perfectly sufficient as long as i can
know what the current audio frame being played is. (and not just how
fast it is playing)

People playing video anyway have other sources of quirks, like for
example having to cope with mismatch between the wide range of frame
rates desktop machines use and the stream's own frame rates. Any
video/audio synchronization is going to be a << best effort >> kind of
solution.


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

This archive was generated by hypermail 2b28 : Wed Jul 24 2002 - 15:47:38 EEST