cli tools: fix frame size estimation when frame_length isn't provided

[baranovmv]

In multi channel scenario a frame sz become too big and Frame Factory refuses to allocate frames. Here the max frame size is estimated similar way to max packet sz estimation.

[rocstreaming-bot]

🤖 Pull request description does not have a link to an issue.
If there is a related issue, please add it to the description using any of the supported formats.

[gavv]

Thanks

[gavv]

Let's add:

DefaultFrameLength = 10 * core::Millisecond;

to roc_sndio/io_config.h and remove it from:

• roc_sndio/io_pump.cpp
• roc_sndio/target_pulseaudio/roc_sndio/pulseaudio_device.cpp
• roc_sndio/target_sox/roc_sndio/sox_sink.cpp
• roc_sndio/target_sox/roc_sndio/sox_source.cpp

(all these definitions have same value of 10ms)

...and reuse it in both main.cpp

[gavv]

Also please rebase on fresh develop to fix CI

[gavv]

If you remember a command that reproduces the bug, could you create an issue with command and output? I didn't see this issue in my tests. Nice to have, but not critical.

[baranovmv]

Fixes #821

[baranovmv]

@gavv

If you remember a command that reproduces the bug, could you create an issue with command and output? I didn't see this issue in my tests. Nice to have, but not critical.

The issue itself needs arguebly a better solution. This PR proposes a hot-fix for basic and straightforward scenarios in our CLI tools. So at the moment there is no easy way to verify the fix proposed in this PR with our unit tests.

IMHO the issue reveals a usability problem in our public API and as a consequence lead to a corresponding issue in command line parameter of CLI tools.

Let me elaborate on a "better solution" a bit:

• I'd rather see MTU (size in bytes) parameter instead of roc_sender_config::packet_length (duration)
• roc_context_config::max_frame_size in it's order could be deduced from MTU, but sometimes it'd make more sense to deduce it from the application. E.g. for pipewire modules it'd be great to tie max_frame_size to quants