Hi, I believe I have uncovered an underlying problem that can cause choppy playback/dropouts when using pulseaudio to stream to an Airport Express using raop. The problem is due to the hardwired configuration of the underlying TCP connection used to carry the audio stream between the pulseaudio server and the Airport Express. Specifically
(i) the size of the socket send buffer used on the raop tcp connection is too small (ii) the size of the receive window used on the raop tcp connection is too small (i) is set by a hardcoded 1024 value in the call to pa_iochannel_socket_set_sndbuf in raop_client.c. Although this is doubled by the kernel this value seems too small to handle variable latencies in network performance. There is also a related system tcp sysctl variable "net.ipv4.tcp_wmem". I changed these values to the following socket sndbuf size = 16384 tcp_wmem = 16384 65536 4194304 (probably overkill - 8k should be OK) (ii) The first parameter in the raop sdp fmtp descriptor line appears to be a receive window size (in file raop_client.c). This is used by the Airport Express as its receive buffer size, and is set to 4096. I changed it to 8192, which seems a safer size. Before I made these changes I was getting persistent dropouts, but after making the changes I have not had a single dropout. Hopefully this will continue. I also observed the TCP traffic with wireshark and can confirm that the TCP dynamics are much healthier with the new values. With the original values the pulseaudio server was sending just two packets in a burst (i.e. before waiting for a TCP ACK), with each packet less than a full sized IP packet (i.e. less that 1514 bytes). There were frequent TCP window closures and reopenings. With the new values the pulseaudio server can now burst up to 5 or 6 full size (1514 bytes) IP packets, with almost no TCP window closures. Remember that the dynamics of this TCP connection are somewhat similar to a satellite connection - high throughput but long latency - so you want to ensure that both the Airport Express playback buffer is kept fed by the pulseaudio server, and also that in the pulseaudio server that the TCP send buffer is kept fed by the sending application (i.e. pulseaudio raop module). The original settings let to starvation due to too many short ping-pong protocol exchanges, instead of allowing the use of longer bursts. As a result of this testing I would suggest changing any hardcoded values in the raop module to 8K (or even greater), or at least making them configurable. A warning message may need to be generated if the current sysctl tcp values are too restrictive to allow the hardcoded or configured settings to take effect. One last point - are the specs for raop v1 and raop v2 published anywhere or have these protocols been reverse engineered? Regards, Bryan G.
_______________________________________________ pulseaudio-discuss mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
