gavv42

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, e.g.PulseAudio buffer size. So basically you can configure all (or almost all) parameters that can affect the resulting latency.

I'll document these parameters and their configuration a bit later. (Currently you can find all of them in the man-page in in the API, but there is no overview page that explains how exactly do they affect the total latency).

Comment · 7 years 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 latencies on a better channel, but I did no serious testing for lower latencies yet. This is in my to-do list.

[1] https://gavv.github.io/articles/new-network-transport/

Show HN: Roc – Real-Time streaming over the network gavv.github.io

126 gavv42 7 years ago 20 comments

Show HN: Roc – Real-Time streaming over the network gavv.github.io

1 gavv42 7 years ago 0 comments

Comment · 7 years 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 overall latency (PA + network + PA).

Comment · 7 years ago

Thanks :)

Comment · 7 years ago

Interesting, thanks for sharing.