Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: Working on a new network transport for PulseAudio and ALSA

gavv.github.io

Post reply on HN
Print view View original

31–40 of 44 posts

Re: Show HN: Working on a new network transport for PulseAudio and ALSA

#31

Post by gimes4dieni »

gavv42 wrote: post #10
heavenlyblue wrote: post #4

Earlier quoted context omitted.

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 wit…

This is exactly what I did - creating an ALSA plugin and leveraging snd-loopback to pass PCM to a streaming process. I would be interested in incorporating your protocol into SlimStreamer. Currently it uses SlimProto, which is TCP based (so sync part is a nightmare to get working on a reasonable level). How far are you with supporting multiple sampling rates and multiple receivers?

Re: Show HN: Working on a new network transport for PulseAudio and ALSA

#32

Post by kylek »

This is cool! I've recently been playing with streaming local audio to another system (a raspberrypi with a dac). I tried Pulseaudio's builtin way of streaming, but lag was pretty bad. I found JACK[0] to work well ([0] http://www.jackaudio.org/ (is this link dead? here's a few more-

https://github.com/jackaudio/

https://en.wikipedia.org/wiki/JACK_Audio_Connection_Kit )

Re: Show HN: Working on a new network transport for PulseAudio and ALSA

#33

Post by closeparen »

gavv42 wrote: post #2

A 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…

Fun fact: end-to-end latency in midrange digital wireless microphone systems is 2.7ms [0]. People sometimes wonder why we bother with 5-6 figure specialty audio and RF gear when we could "just" use general purpose computers and WiFi. This is one of the reasons.

[0] https://www.shure.com/en-US/support/find-an-answer/ulxd-dual...

Re: Show HN: Working on a new network transport for PulseAudio and ALSA

#34

Post by voldacar »

gavv42 wrote: post #2

A 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…

is 100ms really low latency?

Re: Show HN: Working on a new network transport for PulseAudio and ALSA

#36

Post by gavv42 »

majewsky wrote: post #30
gavv42 wrote: post #26

Earlier quoted context omitted.

I see your point. Many audio streaming apps requires 1-2 seconds latency (especially on Wi-Fi), that's why I called the 100-300 ms range "low". 100ms is the minimum I've seriously tested on Wi-Fi so far. 300ms is, roughly, the maximum UI delay that feels acceptable (you press "play" and hear the sound). I'll think about the wording..

300ms is still noticably laggy when the audio is part of a video. Some media players can delay their audio to account for playback delay in the audio device, if the audio stack supports that. Does Roc support that, or if not, is it on your roadmap?

> 300ms is still noticably laggy when the audio is part of a video.

Agree.

> Some media players can delay their audio to account for playback delay in the audio device, if the audio stack supports that. Does Roc support that, or if not, is it on your roadmap?

We have an open issue for implementing correct latency reports in PA modules. When we'll fix it, players that support that feature should automatically start taking the latency into account.

Thanks for reminding me, I'll test this feature specifically.

https://github.com/roc-project/roc/issues/171

Re: Show HN: Working on a new network transport for PulseAudio and ALSA

#37

Post by gavv42 »

voldacar wrote: post #34
gavv42 wrote: post #2

A 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…

is 100ms really low latency?

I agree, calling it low was not quite correct. See the thread above: https://news.ycombinator.com/item?id=19828567

I didn't perform serious testing on latencies below 100ms yet. I've added to my todo that we should investigate the minimum supported latency.

Re: Show HN: Working on a new network transport for PulseAudio and ALSA

#38

Post by gavv42 »

gimes4dieni wrote: post #31
gavv42 wrote: post #10

Earlier quoted context omitted.

> 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 wit…

This is exactly what I did - creating an ALSA plugin and leveraging snd-loopback to pass PCM to a streaming process. I would be interested in incorporating your protocol into SlimStreamer. Currently it uses SlimProto, which is TCP based (so sync part is a nightmare to get working on a reasonable level). How far are you with supporting multiple sampling rates and multiple receivers?

Great!

> How far are you with supporting multiple sampling rates

Roc currently supports arbitrary input/output rates but only a single network rate (44100). If the network rate differs from the input/output rate, Roc performs resampling.

We're now finishing the 0.1 release, and I was planning to add support for more network encodings, including more rates, in 0.2. Feel free to file an issue or mail us with a list of encoding/rates you need.

> and multiple receivers?

No support yet. If you use a multicast address, it would probably just work though.

Again, feel free to file an issue and describe what you would expect from such support. I'll be happy to implement it if someone needs it.

Another question is how Roc will interact with your sync part. How do you perform synchronization?

Re: Show HN: Working on a new network transport for PulseAudio and ALSA

#39

Post by gavv42 »

matthew-wegner wrote: post #29

Network audio is pretty nifty! I run a Snapcast[0] setup at home, tied into Home Assistant[0] automation for multi-room audio. Some notes: - I have six total audio zones, including my desktop computer. - Audio for a room turns on/off with a room. It's neat to walk from my office into the kitchen, and have the kitchen lights come up and audio follow me in when the motion detectors fire. Some speakers don't mute when "…

Interesting, thanks for sharing.

Re: Show HN: Working on a new network transport for PulseAudio and ALSA

#40

Post by xorcist »

gavv42 wrote: post #26
mrob wrote: post #25

Earlier quoted context omitted.

It's very disappointing that 300ms is considered "low" latency. The circumference of the Earth is 40075km, and the speed of light in optical fiber is slightly faster than 2/3rds of that in vacuum, so it's physically possible to send a signal to any place on Earth within 100ms, and get a reply within 200ms. IMO "low latency" should mean low enough than it's very unlikely to be noticed, which most musicians seem to acc…

I see your point. Many audio streaming apps requires 1-2 seconds latency (especially on Wi-Fi), that's why I called the 100-300 ms range "low". 100ms is the minimum I've seriously tested on Wi-Fi so far. 300ms is, roughly, the maximum UI delay that feels acceptable (you press "play" and hear the sound). I'll think about the wording..

Many years ago we did some unscientific testing how latency affected a telephony application. Already at around 80ms there was measurable impact on the dialogue, with an increased frequency of the callers interrupting each other's sentences. Even modern VoIP applications can still be problematic in this regard and additional latency from the software stack wouldn't help.
Post reply on HN