[pulseaudio-discuss] Virtual source (microphone)

[Grzegorz Kryza]

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
>