Show HN: Working on a new network transport for PulseAudio and ALSA
1–10 of 44 posts
Re: Show HN: Working on a new network transport for PulseAudio and ALSA
#2A brief summary.
I'm working on Roc, a toolkit for real-time streaming over the network. Among other things, it provides command-line tools and PulseAudio modules that can be used for home audio. It can be used with PA, with bare ALSA, and with the macOS CoreAudio.
The main difference from other transports, including PulseAudio TCP and RTP streaming, is the better quality of service when the latency is low (100 to 300 ms) and the network in unreliable (Wi-Fi). The post explains why and provides some comparison, usage instructions, and future plans.
There is still a long way to go, and now we're looking for people thoughts and feedback. Do you find the project useful? How would you use it? What features would you like to see?
Re: Show HN: Working on a new network transport for PulseAudio and ALSA
#3Looks awesome! Functionally speaking, it reminds me of Snapcast. Compare/contrast?
Re: Show HN: Working on a new network transport for PulseAudio and ALSA
#4A brief summary. I'm working on Roc, a toolkit for real-time streaming over the network. Among other things, it provides command-line tools and PulseAudio modules that can be used for home audio. It can be used with PA, with bare ALSA, and with the macOS CoreAudio. The main difference from other transports, including PulseAudio TCP and RTP streaming, is the better quality of service when the latency is low (100 to 30…
I've got a home HifiBerry streaming setup over Ethernet. I am using TCP streaming and the latencies are low enough not to be noticeable at all while watching YouTube or playing games and streaming the audio output to my speaker setup on the RPi.
1) Would this make any difference?
2) Does it currently support online plug-unplug the way RTP works without restarting pulseaudio?
Re: Show HN: Working on a new network transport for PulseAudio and ALSA
#5Looks awesome! Functionally speaking, it reminds me of Snapcast. Compare/contrast?
Thanks, I didn't know about this project and will definitely look at the implementation.
Their documentation says they use TCP, which usually means that it won't handle low latencies on Wi-Fi due to packet losses.
On the other hand, they have service discovery, remote control, and multi-room synchronization. All three features are planned but not yet supported in Roc. We'll add the first two in upcoming releases, but the multi-room support requires a serious research.
Their documentation also says the client can correct time deviations by playing faster or slower. We use resampling for that instead. I'm wondering how they can avoid glitches without using a resampler.
One more difference is that they use their own protocols (both for streaming and control) while Roc relies on standard RFCs.
Re: Show HN: Working on a new network transport for PulseAudio and ALSA
#6Sounds great! What about encryption? If that is used in any environment not in complete control of the user that should be mandatory. E.g. in an open wifi, a shared wifi, or directly over the internet. As the protocol is using RTP anyway, it should be easy to slap on SRTP or DTLS? For the beginning, it may even be sufficient to use a static symmetric key. Or directly use WebRTC which has that already included, but what about the FEC then?
Re: Show HN: Working on a new network transport for PulseAudio and ALSA
#7Sounds great! What about encryption? If that is used in any environment not in complete control of the user that should be mandatory. E.g. in an open wifi, a shared wifi, or directly over the internet. As the protocol is using RTP anyway, it should be easy to slap on SRTP or DTLS? For the beginning, it may even be sufficient to use a static symmetric key. Or directly use WebRTC which has that already included, but wh…
Update: I just discovered SRTP in the advanced features list. Awesome!
Re: Show HN: Working on a new network transport for PulseAudio and ALSA
#8A brief summary. I'm working on Roc, a toolkit for real-time streaming over the network. Among other things, it provides command-line tools and PulseAudio modules that can be used for home audio. It can be used with PA, with bare ALSA, and with the macOS CoreAudio. The main difference from other transports, including PulseAudio TCP and RTP streaming, is the better quality of service when the latency is low (100 to 30…
I see you've got Opus on your to-do list. I would really appreciate that! I find Opus (appropriately configured) to be audibly indistinguishable from CD audio, and it would really help with the bandwidth requirements.
I've always been really excited by the possibilities implied by PulseAudio's network capabilities, but disappointed by their latency and bandwidth requirements. Roc + Opus would be amazing.
Re: Show HN: Working on a new network transport for PulseAudio and ALSA
#9Sounds great! What about encryption? If that is used in any environment not in complete control of the user that should be mandatory. E.g. in an open wifi, a shared wifi, or directly over the internet. As the protocol is using RTP anyway, it should be easy to slap on SRTP or DTLS? For the beginning, it may even be sufficient to use a static symmetric key. Or directly use WebRTC which has that already included, but wh…
Update: I just discovered SRTP in the advanced features list. Awesome!
Yeah, SRTP is in the list :) It's not the highest priority right now, but I'll get to that sooner or later (sooner if somebody will be asking for it).
Re: Show HN: Working on a new network transport for PulseAudio and ALSA
#10A brief summary. I'm working on Roc, a toolkit for real-time streaming over the network. Among other things, it provides command-line tools and PulseAudio modules that can be used for home audio. It can be used with PA, with bare ALSA, and with the macOS CoreAudio. The main difference from other transports, including PulseAudio TCP and RTP streaming, is the better quality of service when the latency is low (100 to 30…
I've got a home HifiBerry streaming setup over Ethernet. I am using TCP streaming and the latencies are low enough not to be noticeable at all while watching YouTube or playing games and streaming the audio output to my speaker setup on the RPi. 1) Would this make any difference? 2) Does it currently support online plug-unplug the way RTP works without restarting pulseaudio?
> Would this make any difference?
If you have no issues with 1) latency 2) packet losses and 3) clocks difference, that would be no difference, at least until Roc could offer some new encodings.
(If you're using PA, it handles the clocks difference for you. Its RTP transport sometimes worked strange for me, but its "native" tunnels handled it well.)
> Does it currently support online plug-unplug the way RTP works without restarting pulseaudio?
Roc sinks and sink inputs may be loaded and unloaded at any time without restarting PA. But there is no service discovery yet, which means that 1) when a remote sink input appears, sink is not automatically added 2) when a remote sink input disappears, sink is not automatically removed. (We will add this in upcoming releases). Currently the remote sink input can appear and disappear at any time and the local sink will just continue streaming packets to the specified address.