gavv42

13 ms·

1.
Show HN: Roc VAD – macOS virtual device for audio streaming(github.com)
1 points by gavv42 2y ago|1 comments
2.
Show HN: Go Bindings for Roc Toolkit(github.com)
5 points by gavv42 4y ago|0 comments
3.
Show HN: Signal Estimator – Measure characteristics of a looped back signal(github.com)
2 points by gavv42 7y ago|0 comments
4.
Show HN: WebRTC Command-Line Peer(github.com)
7 points by gavv42 7y ago|0 comments
5.
A step-by-step tutorial for live audio streaming with Roc(gavv.github.io)
3 points by gavv42 7y ago|0 comments
6.
Show HN: Single-Page HTML5 Generator for Ruby RDoc(github.com)
1 points by gavv42 7y ago|0 comments
7.
by gavv42 7y ago
AFAIK zita-njbridge is quite similar to Roc, but it's JACK-specific and has no loss recovery.
8.
by gavv42 7y ago
Right. You can as well configure the FEC block size (it should be smaller than the target latency), the length of network packets, the length of internal audio frames in the pipeline, and the resampler window. And also the I/O latency,
9.
by gavv42 7y ago
So far I mostly tested Roc on several 2.4 Ghz Wi-Fi networks. You can usually expect 100-500 ms in this case (depending on the network). See "Typical configuration" in this article[1]. Most likely you will be able to achieve lower
10.
Show HN: Roc – Real-Time streaming over the network(gavv.github.io)
126 points by gavv42 7y ago|20 comments
11.
Show HN: Roc – Real-Time streaming over the network(gavv.github.io)
1 points by gavv42 7y ago|0 comments
12.
by gavv42 7y ago
That small experiment in my post does not include a correct latency estimation. I just configured all three transports with the desired latency. Actually I'm thinking about writing a tool for such benchmarks that will measure the overa
13.
by gavv42 7y ago
Thanks :)
14.
by gavv42 7y ago
Interesting, thanks for sharing.
15.
by gavv42 7y ago
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 r
16.
by gavv42 7y ago
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 shoul
17.
by gavv42 7y ago
> 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 no
18.
by gavv42 7y ago
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
19.
by gavv42 7y ago
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, roughl
20.
by gavv42 7y ago
Thanks. > Does it support h323? No, and there were no plans yet. But we probably can add support if someone will need it.
21.
by gavv42 7y ago
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 n
22.
by gavv42 7y ago
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.
23.
by gavv42 7y ago
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
24.
by gavv42 7y ago
Not yet. This is in our roadmap however.
25.
by gavv42 7y ago
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.
26.
by gavv42 7y ago
> 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 c
27.
by gavv42 7y ago
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).
28.
by gavv42 7y ago
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 han
29.
by gavv42 7y ago
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,
30.
Show HN: Working on a new network transport for PulseAudio and ALSA(gavv.github.io)
107 points by gavv42 7y ago|43 comments

More ›