Victor Gaydov

After a closer look, it seems the last one is really caused by packet loss, as discussed in chat. So it's not a problem of latency adjustment algorithm, it behaves...

The problem can be solved by using larger FEC blocks on sender, e.g. `--nbsrc=30 --nbrpr=20`.

If I use `--packet-len 7ms --nbsrc 40 --nbrpr 20` on sender, which gives FEC blocks of 280ms, receiver still uses target latency of 200ms for some reason. (Jitter is below...

> ### Wi-Fi, unstable channel I did some more experiments in this setup (streaming from laptop to orange pi connected to 2 different 5ghz access points, in turn connected together...

During some short period, I was constantly getting this panic: ``` link meter: seqnum was not processed in writer part ``` I never restarted sender. I restarted receiver multiple times...

Here is an example when tuner was too optimistic, reduced latency, and it caused drops of late packets and crackling. It happened after a long measurement (about 30 minutes). Attached...

If we want to support specifying starting latency in CLI, then we also need it in C API? There are two approaches for C API: * target_latency = 0 means...

> Pipeline tests test_loopback_sink_2_source fail with FlagCTS: timestamp_mapping and timestamp_mapping_remixing It's actually not related to CTS. Currently you have: ```cpp if (flags & FlagRTCP) { ... if ((flags & FlagCTS)...

> We need https://github.com/roc-streaming/roc-toolkit/issues/674 to see these metrics on sender As I said above, total_packets and other link metrics that you see on sender are from RTCP feedback. If you...

```cpp /** Total amount of packets sent or expected to be received. * * On sender, this counter is just incremented every packet. * On receiver, it is derived from...