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

11–20 of 44 posts

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

#11

Post by gavv42 »

autopoiesis wrote: post #8
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 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.

Good to know. Yes, Opus will be is one of the highest priorities for us after we'll make the very first (0.1) release.

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

#12

Post by autopoiesis »

gavv42 wrote: post #11
autopoiesis wrote: post #8

Earlier quoted context omitted.

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.

Good to know. Yes, Opus will be is one of the highest priorities for us after we'll make the very first (0.1) release.

Excellent; a few years ago I even started hacking on my own transport, very roughly as a PA module, but life got in the way and it never got very far. So I'm very pleased to see this great project. Thanks, and good luck!

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

#15

Post by zneveu »

autopoiesis wrote: post #8
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 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.

Check out https://github.com/eugenehp/trx for Opus streaming inspiration, I've played around with their code and found it easy to work with. Opus would be great with ROC because in case of buffer over/under runs the codec provides features to mask dropouts based on previous content. This is critical when using Wi-Fi.

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

#17

Post by iforgotpassword »

gavv42 wrote: post #14
Frans-Willem wrote: post #13

Can this also play to multiple devices (at the same time), while keeping the audio synchronized ?

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

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

#18

Post by gavv42 »

zneveu wrote: post #15
autopoiesis wrote: post #8

Earlier quoted context omitted.

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.

Check out https://github.com/eugenehp/trx for Opus streaming inspiration, I've played around with their code and found it easy to work with. Opus would be great with ROC because in case of buffer over/under runs the codec provides features to mask dropouts based on previous content. This is critical when using Wi-Fi.

Thanks.

> Opus would be great with ROC because in case of buffer over/under runs the codec provides features to mask dropouts based on previous content. This is critical when using Wi-Fi.

Are you talking about its PLC or FEC? I didn't test it yet and I'm interested if people are using both of them with music.

BTW it would be also interesting to combine our FECFRAME support with Opus.

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

#19

Post by gavv42 »

dmos62 wrote: post #16

You've mentioned PA, ALSA and macOS CoreAudio. That's Linux and Mac. Will Windows users be able to use this as well somehow?

Currently, no. Windows port is in our roadmap but not a priority right now. However, if someone would want to maintain it, I'm ready to accept PRs and help with porting.

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

#20

Post by jcelerier »

gavv42 wrote: post #14
Frans-Willem wrote: post #13

Can this also play to multiple devices (at the same time), while keeping the audio synchronized ?

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