On Mon, 2010-01-18 at 21:38 +0100, Lennart Poettering wrote: > 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. Sound is forwarded between server and client, compressed with vorbis or speex to reduce bandwidth. Right now a timing is not so important and we didn't noticed any drawbacks. Even initial tests with VoIP gave a good results. Probably as a next step we will follow your suggestions and implement a specialized PA module to have a better control over a timing. For sure a better solution but a problematic if a application should work out of box on a wide set of Linux distributions. Other choice can be some kind of virtual ALSA device... > 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. Thanks for clarification. > Lennart >
