pl bossart wrote:
> 1) The reported latency of 38 years must reflect a bug!(?) Can this be
> > fixed?
This one made my day. Something's obviously broken here. can you
provide the full log for us to figure out what went wrong?
I'll email you separately on this.
Maarten Bosmans wrote:
2011/1/18 Dr. Adrian Wrigley<m...@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.
OK. This is interesting. I had assumed the clock-rate matching was done
on the sending machine only, Disabling or downgrading resampling in the
receiver
might solve my problem.
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 mistake in cutting/pasting! The above shows the tcp configuration which
has the limitations mentioned. This is what I meant to say:
load-module module-alsa-source source_name=wireloop
load-module module-esound-sink server=192.168.1.4:16001
load-module module-loopback source=wireloop sink=esound_out
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?
I did try this in an earlier configuration which didn't meet my needs.
(I am trying to use remote sound from a VirtualBox running Windows)
I can see better how to make RTP work - using loopback in the
server's ALSA (Machine2). Perhaps I'll try it again.
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.
OK. I had assumed the default was to minimum latency without dropouts,
I had tried "latency_msec=100" on the loopback on Machine1, but it didn't seem
to have
any noticeable effect. But from your the above comment, the latency
parameter must be added in the *client*. I was assuming that the latency
parameter
tries to set end-to-end latency.
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.
Interesting. I wouldn't expect adding a vumeter to reduce latency for
other pathways.
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
Thanks for your helpful and prompt comments! While going through this
experience, I've learned a lot about how audio on Linux works nowadays.
It isn't obvious, and there are still lots of "issues". Perhaps ten years from
now, it will all work together smoothly...
The documentation for Pulse and for ALSA is great, but would benefit
by having more detail on the principles behind the parameters.
--
Adrian Wrigley
_______________________________________________
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
