It always latency out of bounds when receiver running on openwrt.

[sumdoll]

Hello guys,
This roc-project is very good and I have ported it to openwrt platform which base on MT7688 (580MHz MIPS® 24KEc™ CPU). The sender works well, but the receiver always remove session and then try to create session over again and again. It reports latency out of bounds error:

16:44:03.810 [dbg] roc_fec: fec reader: update source block size: cur_sblen=0 cur_rblen=0 new_sblen=20
16:44:03.810 [dbg] roc_fec: fec reader: repair queue: dropped=10
16:44:03.811 [dbg] roc_audio: depacketizer: got first packet: zero_samples=960
16:44:03.905 [inf] roc_sndio: sox: alsa.c: under-run
16:44:03.909 [dbg] roc_audio: latency monitor: latency=13894 target=8820 fe=1.00000 trim_fe=1.00000 adj_fe=0.91875
16:44:04.013 [inf] roc_sndio: sox: alsa.c: under-run
16:44:04.017 [dbg] roc_audio: latency monitor: latency out of bounds: latency=18209 max=17640
16:44:04.018 [inf] roc_pipeline: receiver: removing session
16:44:04.020 [inf] roc_sndio: sox: alsa.c: under-run
16:44:04.021 [inf] roc_pipeline: receiver: creating session: src_addr=192.168.20.188:58967 dst_addr=0.0.0.0:10003
16:44:04.021 [dbg] roc_packet: delayed reader: initializing: delay=8820
16:44:04.022 [dbg] roc_fec: of decoder: initializing: codec=rs _m=8

The roc-test-audio will take 44799 ms and roc-test-lib failed:
root@Widora:/mnt/mmcblk0/test/mipsel-openwrt-linux# ./roc-test-audio
..................................................
......................
OK (72 tests, 72 ran, 299948 checks, 0 ignored, 0 filtered out, 44799 ms)

root@Widora:/mnt/mmcblk0/test/mipsel-openwrt-linux# ./roc-test-lib

src/tests/roc_lib/test_address.cpp:78: error: Failure in TEST(address, bad_args)
CHECK(!roc_address_ip(&good_addr, buf, 7)) failed

terminate called after throwing an instance of 'CppUTestFailedException'

But the roc-test-audio testing only take 49 ms on x86 PC. So I guess the receiver "latency out of bounds" fail is caused by CPU performance, could you give some suggestion for this issue? I really appreciate for your any idea.

[gavv]

Hello and thanks :)

Interesting! Did you patch Roc? If so, do you have plans to share the patch?

Yes, this looks like a CPU performance issue.

What can be done here:

• Are you building debug (--enable-debug in scons) or release version (default)? If you're building debug, try release.

• You can try to use a lower-quality resampler profile (--resampler-profile=low), or disable resampler at all (--no-resampling). Disabling resampler will lead to latency drift, though, but at least we will understand what the problem is. Resampler can be also configured manually, instead of selected predefined profile, using --resampler-interp and --resampler-window options. Resampler if the most CPU-intensive component. We have a task for trying speex resampler, which should be faster, but it's not complete yet: Switchable resampler backends #235.

• You can try to increase latency and frame size on the receiver. Though, I don't really think it will help, but just in case.

• You can run roc-conv to measure the speed of our pipeline. Here is the output on my laptop:

  $ roc-conv -vv -i file:./stash/loituma.wav
  ...
  17:35:59.215 [21431] [dbg] roc_audio: profiling writer: 793543 sample/sec (17.99 sec/sec)
  17:36:00.215 [21431] [dbg] roc_audio: profiling writer: 783646 sample/sec (17.77 sec/sec)
  17:36:01.215 [21431] [dbg] roc_audio: profiling writer: 777686 sample/sec (17.63 sec/sec)
  

  Here, 17.63 sec/sec means that our the pipeline (more exactly, some part of it, including resampler) processes a frame 17 time faster than the frame duration itself. The value is lower on, e.g. Raspberry Pi, something around 2-4. If this value is lower than 1.0 on your board, it confirms that the pipeline is too slow and we should optimize it.

• What audio backend do you use? If you're using PulseAudio, it may be CPU-intensive if it performs resampling too. We try to ensure that we will resample only once (in Roc), but probably this mechanism fails. Roc automatically enables resampling if network sample rate differs from sample rate suggested by PA. PA automatically enables resampling if app sample rate differs from the sound card sample rate. PA should suggest the sound card sample rate to Roc, but who knows... That suggested rate can be overridden using --rate option. So you can try either to pass --rate equal to your card rate (to force resampling in Roc), or to pass --rate equal to network rate (to force resampling in PA). The network rate is currently always 44100.

• If you're using PA, you may try to temporary uninstall or disable it and use bare ALSA.

• If you're using ALSA, it probably can perform resampling as well? Not sure, but I think dmix can do it (if you're using it...). So you probably can try the same as described above.

• You can also try to output to a file instead of audio device.

[sumdoll]

Hello gavv,
Thanks your support, I really appreciate that. I have not patch Roc yet, I'm glad to share this patch after testing if Roc needs.
There is a good news is that the receiver works with --no-resampling option now. This testing target is release version and use ALSA as audio backend. About the resampler performance result, will be updated after testing.

[gavv]

There is a good news is that the receiver works with --no-resampling option now.

Did you also try --resampler-profile=low?

Would be also interesting to see the output of roc-conv (see example above).

[gavv]

Recent develop branch now has speex resampler support which works a few times faster than our resampler. It's now enabled by default. It may fix this problem.