Delays while playing music on the network via wifi

[vectart]

There are two computers with Ubuntu Lucid Alpha3: - PC, connected to the router via cable - Laptop connected to the router via wifi g (with a maximum signal)

Laptop is an audio client, and PC - audio server.

When playing music through Rhytmbox, the sound is interrupted for 10-30 seconds. Then continues to play and he was again interrupted.

This problem has been observed for two years, ever since I tried PulseAudio. Did you ever fix this problem or will continue to assert the possibility of a network of sound, which is practically no? :))

[bgamari]

I too experience this trying to play through an i810 Lucid box. The symptoms are very similar to what was described above. Unfortunately, I've been hard-pressed to find any actual error messages. I would love to try tracking this down, but debugging documentation has been pretty tough to find. Any advice?

[bgamari]

It seems there have also been several other uses seeing similar symptoms: https://bugs.launchpad.net/pulseaudio/+bug/273742/ http://pulseaudio.org/ticket/366 (3rd comment) http://www.mail-archive.com/pulseaudio-discuss@mail.0pointer.de/msg01826.html http://ubuntuforums.org/showthread.php?t=1057261

[vectart]

Replying to bgamari:

I would love to try tracking this down, but debugging documentation has been pretty tough to find. Any advice?

Of course, that there's no any errors. The problem of delays is not in some errors, but the implementation in general.

It seems that the developers forgot about the fact that this network. Network (and especially, wifi) has such defects as delays, breakages, low bandwidth. Programmers should be aware of all these details in writing programs.

[bgamari]

After looking at pulseaudio -vvvv output on the server, it seems like the problem is simply underruns. While playing, I get hundreds of "D: protocol-native.c: Requesting rewind due to rewrite" errors, with the occassional "D: protocol-native.c: Underrun on '$STREAM_NAME', $N bytes in queue" with $N generally being 0.

This seems strange as while the audio server transfers around 3 Mbit/sec, I'm on a 54 Mbit/sec network. I understand network overhead can cut into the total available bandwidth, but I would still contend that the network should have a throughput higher than 3 Mbit/sec.

[vectart]

audio server transfers around 3 Mbit/sec

oh shi~ it's crazy!

Good MP3 quality is 192 kbit/s Perfect MP3 quality is 320 kbit/s

[bgamari]

Here's a simple throughput test confirming the plentiful amount of bandwidth on the network,

[0921 ben@venus ~] $ time dd if=/dev/zero bs=512k count=100 | nc mars.local 9999100+0 records in
100+0 records out
52428800 bytes (52 MB) copied, 48.8073 s, 1.1 MB/s

With another process running on the pulseaudio server,

[0921 ben@mars ~] $ nc -l 9999 | dd bs=512k of=/dev/null
0+69938 records in
0+69938 records out
52428800 bytes (52 MB) copied, 52.4389 s, 1000 kB/s

In short, the network can carry at least 8 Mbit/second. A raw audio stream (48kHz, 24 bits/sample, 2 channel) on the other hand should require only 2.19 Mbit/second. Unless I am missing something, network bandwidth does not explain the poor performance of network streaming in PulseAudio.

[acidice333]

I've noticed that when you use "server" instead of "sink" it works a lot better.

With the "server" specified, I can stream my audio at about 300-400kb/sec with less than 50kb/sec coming back to me.

When I'm using a "sink", it seems as tho if I don't have anything playing, it still transfers at whatever the top speed is for my transmission source/receiver is. So if I'm using wireless, it transfers at 600 up and 600 down. Why am I receiving so much data?!

I've hooked both up to wired LAN and it performs better but I don't want wires.