PulseAudio network transports + Wifi

Now that I have an idea of a cool hardware for listening to music, I’ve been experimenting with pulseaudio network support. Over Wireless.

They are two ways of using pulse for network streaming : RTP and TCP. The first one was a total failure for me (using pulse 1.0). The second, however, was very straightforward to setup and is almost working perfectly. I only get micro-interruptions every 10 seconds. But that’s enough for not being suitable.

First, the upload rate is about 200kb/s, so maybe that’s too much for a cheap wireless card (I’m using the ath9k driver). According to Lennart, the problem is partly due to pulse not compressing streams over the network. One possible solution is to use the CELT codec (from Xiph), which has been designed to produce high fidelity audio with very low latency and power consumption. CELT’s features are the following:

  • Ultra-low latency (typically from 5 to 22.5 ms)
  • Full audio bandwidth (≥20kHz; sample rates from 8 kHz to 48 kHz)
  • A quality/bitrate trade-off competitive with widely used high delay codecs
  • Stereo support
  • Packet loss concealment
  • Constant bit-rates from 32 kbps to 128 kbps and above
  • A fixed-point version of the encoder and decoder (interesting for embedded boards)

Given the random network latencies, I can assume we have around 2ms using a wifi connection, plus pulse and celt, that would be something around 10ms… which would still be pretty ok. Having this would make a close alternative to Apple’s RAOP protocol that uses ALAC. Still, ALAC is lossless while Celt is limited to 128kb. So, FLAC or ALAC itself maybe ? Even if it eats more processing power, for desktop and powerful boards, that would still make sense.

To prevent multiple encodings/decodings, another trick would be to implement a server-side decoding and therefore write module for PA that supports speex, vorbis, etc. But that’s another story.

Second, this could also be a jitter/latency problem. In fact, I’m a bit more convinced this is the real problem. According to Maarten Bosmans, there’s still room for improving these things in the pulse core ; so that’s good news. I don’t understand why my wifi N card, if I’m not doing anything else, wouldn’t be able to keep up with the 200kb/s rate. But that’s only intuition here.

Conclusion: before going further, I’ve to understand first if this is a latency or bandwidth-related problem to pick the right fight.

Share via email

2 thoughts on “PulseAudio network transports + Wifi”

  1. Hi Rune ! sorry for the very late answer. You’re pretty correct, that really seems to be a buffer problem. I’ve traced the response with wireshark, and it seems the stream is not continuous due to missing ACKs that never come (and the algorithm seems to wait for it before going on). I can share the graph if you want!

  2. Have you gotten any further with this? I’m almost sure it has to be a latency or perhaps a clock issue. At less than 200 KB/s, I can’t imagine it being bandwidth.

    If the network module simply receives a stream and plays it as it does with a local stream, that’s definitely the problem. It needs to have a buffer implemented, that can deal with a temporary pause in the network stream of data. Buffer sizes for local playback would be completely unsuitable for wifi. Local buffer sizes would probably be sufficient at 5 ms, while wifi probably needs more like 50 or 100 ms.

Leave a Reply

Your email address will not be published. Required fields are marked *