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.

gh-821

[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]

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

[gavv]

I think you've accidentally committed distfiles from master:

[gavv]

So far roc_audio doesn't depend on roc_sndio (it's the opposite), and I think it's different 10ms. Here 1sec and 1ms are related, and OTOH frame size should be irrelevant.

[gavv]

Not sure what is best practice, but elsewhere in code we don't have anon namespace for .h consts.

Suggested change

	namespace {
	//! Default duration of a frame. 10ms is rather high,
	//! but works well even on cheap sound cards and CPUs.
	//! Usually you can use much lower values.
	const core::nanoseconds_t DefaultFrameLength = 10 * core::Millisecond;
	} // namespace
	//! Sink and source config.
	//! Default duration of a frame. 10ms is rather high,
	//! but works well even on cheap sound cards and CPUs.
	//! Usually you can use much lower values.
	const core::nanoseconds_t DefaultFrameLength = 10 * core::Millisecond;
	//! Sink and source config.

[gavv]

Agree with the better solution.

To take the idea further:

• I'd rather see MTU (size in bytes) parameter instead of roc_sender_config::packet_length (duration)

I think we should have both. User can set packet length (if they care about latency; if they use non-PCM), or MTU (if they care), or both.

If only one is set, the other is derived. If both are set, we may either validate that packet len fits MCU, or use the smaller one.

• 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

Actually, I think we should get make max_frame_size and max_packet_size optional, and if they're not set, don't place any limits. This would require reworking slab pool to support dynamic chunk size, which should be feasible (e.g. using buddy allocator).

[gavv]

Please rebase on fresh develop to make CI green.