[pulseaudio-discuss] module-alsa-source latency is 1199291857647 ms

Maarten Bosmans mkbosmans at gmail.com
Tue Jan 18 11:45:15 PST 2011


2011/1/18 Dr. Adrian Wrigley <mail at adrianwrigley.com>:
> Hi all,
>
> I'm now having problems with latency.
>
> I'm trying to send the analog input on Machine2 to the speakers on
> Machine1.  I'm currenty trying with esd protocol and module-esound-sink
> on Macine2.
>
> (Unfortunately, native tcp protocol doesn't work for me.  It produces only
> silence
> or brief bursts of sound unless I am running pavucontrol on Machine2 at the
> same time, when it works fine (weird).  Also, the CPU usage is excessive on
> the machine
> receiving the audio - about 12%, which then requires fan cooling (650MHz
> Pentium laptop).
> The latency on native tcp protocol is fine.  Why is native tcp need 10x the
> CPU of esd?)

This has to do with resampling to correct for clock drift between the
machines. You could try setting a lower quality resampler to save CPU,
or disabling resampling all together.

> The latency with esd I hear is about 1500ms.  I'd like under 200ms.
>
> The three key modules I load on Machine2 are:
>
> load-module module-alsa-source source_name=wireloop
> load-module module-tunnel-sink server=192.168.1.4:16001
> load-module module-loopback source=wireloop sink=tunnel.192.168.1.4

You mentioned ESD before. I fail to see any use of protocol-esound
here. Or are you describing two different setups?

> My questions:
> 1)  The reported latency of 38 years must reflect a bug!(?)  Can this be
> fixed?
> 2)  Is my configuration for listening to the ALSA source sensible? is there
> a better way?

Did you try module-rtp-send and module-rtp-recv?

> 3)  Where does my 1.5 second latency come from?  How can I reduce it?

By default pulse tries to wake up as little as possible. This is done
by setting a large buffer size. I'm still a little bit confused about
your exact setup, so I can't really tell you how to reduce the latency
in your case, other than: look at the available module parameters.

> 4)  Why does native tcp protocol (module-tunnel-sink) need pavucontrol
> running to work?

pavucontrol sets up streams to every sink to monitor audio for its
vumeters. For these streams it requests a low latency. That makes the
latency for all the streams low. The solution would be to ask pulse
for a lower latency for your stream.

> A work-around for the moment is to bypass Pulse by running this command on
> Machine2
> arecord -f S16_LE -c 2 -r 44100 | /usr/bin/esdcat   # Lower latency transmit
> to Machine1
>
> Using Puleaudio adds 1.5 seconds in the path.
>
> Thanks again for any helpful comments!
> --
> Adrian Wrigley

Maarten



More information about the pulseaudio-discuss mailing list