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<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. 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
