[pulseaudio-discuss] More on the native protocol complexity

Rafal Wojtczuk rafal at invisiblethingslab.com
Mon May 10 03:35:31 PDT 2010

On Sun, Apr 25, 2010 at 02:10:49AM +0200, Lennart Poettering wrote:
> > A solution acceptable from VM_HOST's point of view on security is:
> > 1) Load module-simple-protocol-tcp in VM_HOST
> > 2) Run pulseaudio daemon in VM_USER (and make users connect to it, instead
> > to VM_HOST). Load module-pipe-sink, and pass the pipe output over the network 
> > to port 4711 in VM_HOST (to module-simple-protocol-tcp code).
> That is not workable, as this provides no timing info at all. Video will
> be jumpy, and with uncontrolled latencies.
What do you think about implementing synchronization by enforcing low buffer
size ? [yes, I am aware of http://www.pulseaudio.org/wiki/LatencyControl, but
it hardly applies in this case]
Tested setup involves:
1) Patch parec-simple and pacat-simple
so that they read/write to vchan, not stdin/stdout. Vchan is an interVM pipe, 
practically latencyless, with only 1024 bytes of internal buffers (it will
block if written to more)
2) In parec-simple, change the buffering parameter (in the call to
pa_simple_new) to {.maxlength=8192, .fragsize=1024}
3) run parec-simple in VM_USER (it will fetch from auto_null.monitor I
4) run pacat-simple in VM_HOST.

The above works fine, at least when judging by a nontrained ear.

Note that if we do not patch to use vchan directly, but use vanilla tools
and pick data from their stdout/stdin instead, the buffering introduced by the
stdin/stdout pipes results in noticeable delay between sound generation in
VM_USER and reception in VM_HOST.

Known downsides:
1) About 10% of CPU time overhead, because of frequent I/O due to small buffers.
2) Risk of dropouts

Let's say 1) is acceptable (and can be probably lowered by tweaking buffer
sizes); 2) should be mitigated by elevated scheduling priority ?

Do you have any comments ? Particularly, do you see any scenario when
desynchronization can occur ?


More information about the pulseaudio-discuss mailing list