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

21–30 of 44 posts

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

#21

Post by gavv42 »

jcelerier wrote: post #20
gavv42 wrote: post #14

Earlier quoted context omitted.

Not yet. This is in our roadmap however.

gstreamer already does that fairly well ( https://arunraghavan.net/2017/01/quantifying-synchronisation... ), is there a reason to duplicate the work ?

Thanks for info.

> is there a reason to duplicate the work ?

I don't know yet. When the time comes to implementation we'll look whether we can re-use either the code or ideas or maybe instead integrate Roc into GStreamer as a network transport (actually I was thinking about it already and there is an item in the roadmap for it).

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

#22

Post by nitrogen »

iforgotpassword wrote: post #17
gavv42 wrote: post #14

Earlier quoted context omitted.

Not yet. This is in our roadmap however.

This would be very cool. I've been pondering about how to do this every now and then (but never worked on any real time stuff, so...) If you ever get around to adding this I will start building my el cheapo raspberry pi based sonos clone. ;-)

Regarding realtime stuff there's a project out there to implement the Ethernet AVB (audio/video bridging) standard on BeagleBone using PTP (precision time protocol) for synchronization.

Some of the older network synchronized transports like CobraNet and Dante might also be interesting for anyone wanting to learn more about this stuff.

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

#23

Post by cbluth »

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…

I would like to show your project to some friends, thanks! Does it support h323?

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

#24

Post by gavv42 »

cbluth wrote: post #23
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…

I would like to show your project to some friends, thanks! Does it support h323?

Thanks.

> Does it support h323?

No, and there were no plans yet. But we probably can add support if someone will need it.

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

#25

Post by mrob »

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…

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 accept as 5ms. (Theoretically, even microsecond level delayed audio can be noticed if mixed with the original signal because of comb filtering.)

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

#26

Post by gavv42 »

mrob wrote: post #25
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…

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..

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

#27

Post by gimes4dieni »

This is great staff! Finally there is an Open Source initiative to create a robust transport for sync audio streaming. Existing Open Source solutions that come to my mind (like SlimProto, SnapCast, ffmpeg) focus on providing 'a product' rather than a reusable 'transport'. Few questions: how do you 'capture' PCM stream in case of ALSA? It is straight forward to create a PA sink and plug it into PA configuration, but I am wondering about pure ALSA. Disclaimer: I am an author of https://www.github.com/gimesketvirtadieni/slimstreamer

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

#28

Post by gavv42 »

gimes4dieni wrote: post #27

This is great staff! Finally there is an Open Source initiative to create a robust transport for sync audio streaming. Existing Open Source solutions that come to my mind (like SlimProto, SnapCast, ffmpeg) focus on providing 'a product' rather than a reusable 'transport'. Few questions: how do you 'capture' PCM stream in case of ALSA? It is straight forward to create a PA sink and plug it into PA configuration, but I…

Thanks.

> Few questions: how do you 'capture' PCM stream in case of ALSA? It is straight forward to create a PA sink and plug it into PA configuration, but I am wondering about pure ALSA.

Good question :) Roc does not implement any special capturing code for ALSA, it just reads from the given device (using SoX currently). The user is supposed to use something like snd-aloop.

It would be possible to create a custom ALSA plugin I guess, but we have no plans for that currently.

You're right about the transport vs product part. I would prefer to work on the transport. And an ALSA plugin would be a product on top of it so it should be a separate project ideally. Actually, the same is true for our PulseAudio modules. I hope later we will either submit them to upstream or separate into a standalone project.

> Disclaimer: I am an author of https://www.github.com/gimesketvirtadieni/slimstreamer

Interesting, didn't see it before.

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

#29

Post by matthew-wegner »

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 "off", but change source to a text-to-speech only channel (for i.e. door/window contact notification, other messages).

- Everything but my desktop (macOS) are speakers connected to a Raspberry Pi via USB DAC.

- One of my motivations here was multi-room audio, but a big one was to connect a Linux VM's audio output directly to the speakers so I could use the official Spotify client, instead of a 3rd-party library that will eventually break.

- Snapcast is really quite DIY for config, but I could set up other sources--an Airplay target, a line in target with a cable hanging off the server so people could plug in devices at a party, etc. I've seen setups online where people do this, and someone in a room can change that room's "channel" to another source.

- Spotify's DRM-as-feature is nice here, because I just use the Spotify client on my desktop normally, with output coming out elsewhere. I run 700ms of buffer, which is just low enough that clicking play/pause doesn't feel broken. I could probably drop it more, since everything is hardwired in the house.

- Previous to Snapcast, I just toggled Spotify's source when I walked between rooms, but there's quite a bit of dead air there, and it's a hassle to setup, plus multi-room audio sync is nice with people over.

[0] https://github.com/badaix/snapcast

[1] https://www.home-assistant.io/

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

#30

Post by majewsky »

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..

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?
Post reply on HN