On Mon, 18.01.10 21:19, Grzegorz Kryza (gkryza at gmail.com) wrote: > > If you do that you need to make sure you provide an interface for the > > PA server to query the latency synchronously with the data > > transferred. Note that most video players schedule frames based on the > > audio clock, so if the latency estimation is not smooth and dependable > > video playback will be jumpy. > > Thanks for interesting info. > > However if a audio/video synchronization is not needed, for example > in case of virtual microphone? There are other drawbacks of using pipe > sink/source? Especially if it actually works in our case. I am not sure what you try to do, but unless you severely limit the apps you allow to be run on top of PA you need to think about the timing interfacing. When doing playback, jumpy video frames will be the most obvious indication of lacking timing control. However, when doing recording it matters, too. For example, there are apps (pavucontrol as one example) which show some kind of graphical display of what is recorded in a vumeter style or a sine wave or whatever. They too use the timing info of the sound backend to schedule those video frames and will hence appear jumpy. Also, VoIP applications tend to compensate for clock differences of the remote/local and input/output devices and will be greatly confused if one of the devices does not provide a proper clock. And this goes on and on and on. Audio clocks do matter. You cannot just ignore them. Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4
