Multitrack packets too big per default ("packetizer: can't prepare packet")

[fallingcats]

While trying to add support for additional channels to the pipewire module, I ran into the following issue while testing with 8 channels:

[err] roc_audio: packetizer: can't prepare packet

I discovered I could prevent that error from occurring by setting roc_sender_config.packet_length to less than 2_891_156ns. I'd appreciate though if the defaults were set (or rather calculated?) such that this didn't happen.

I understand that using MULTITRACK is not exactly default in itself, but it's not documented (to my knowledge) that I manually need to limit packet size through packet_length (or possibly other means?). Increasing roc_context_config.max_packet_size also works (locally) but I'm not sure how that translates to network packets w.r.t MTU

Currently I'm using sender_config.packet_length = 20_000_000 / channels. Please let me know if that's a bad idea, thanks :)

_{roc v0.4.0 (and pipewire master 76a31a47)}

[baranovmv]

Thank you for filing the idea, seems like it could be negotiated automatically indeed!

[Ayoub-glitsh]

Hi 👋
I’ve read through the issue and the discussion, and I’d be happy to help if you’re looking for contributors.
Let me know if you’d like me to investigate the packet sizing defaults or try to propose an improvement.
Thanks!

[baranovmv]

@Ayoub-glitsh you're very much welcome! It'd be great if you'll be able to come up with your thoughts and general plan in order to get initial feedback earlier.

BTW, I wonder what discussion have you read through?

[baranovmv]

@fallingcats have you managed to get the update to pipewire module doing something useful for you? Have you uploaded anywhere? It'd be cool to see!

If it is under construction please don't hesitate to upload it please! I'm also into roc-sink module these days, so it might be cool to join forces

[Ayoub-glitsh]

Hi @baranovmv, thanks for the welcome . Sorry for the confusion by “discussion” I mainly meant the original issue description and your comment about automatic negotiation, not an external thread.

[Ayoub-glitsh]

@baranovmv , Before I dive deeper and start implementing changes, I just wanted to ask a quick question:
is this issue planned to be associated with a bounty?

If a bounty is added, could you please share the link to the platform where the bounty is hosted so I can register and follow the process properly?

I’m happy to work on the issue either way, but knowing this would help me better prioritize the time and scope of the work.

Thanks for the clarification, and I’ll proceed with the investigation in the meantime

[fallingcats]

@fallingcats have you managed to get the update to pipewire module doing something useful for you? Have you uploaded anywhere? It'd be cool to see!

If it is under construction please don't hesitate to upload it please! I'm also into roc-sink module these days, so it might be cool to join forces

It's already upstream, see module-roc: Add support for multi-channel audio

If you want to use it, then run PipeWire 1.5.82 or newer

[baranovmv]

@fallingcats thanks for info!

[baranovmv]

@Ayoub-glitsh no bounty I am aware of. Please feel free to ask further questions and request advice or comments on your plan or thoughts

[Ayoub-glitsh]

Thanks for the clarification, @baranovmv.
In that case, I’ll proceed with the investigation and try to come up with a concrete proposal for improving the default behavior around packet sizing in multitrack scenarios. I’ll share my findings and a rough plan once I have a clearer picture, and I may ask for feedback along the way if any design questions come up.

[baranovmv]

@Ayoub-glitsh follow up the pr #833: sorry for closing it. An ideal solution in my humble opinion should explicitly take the MTU size into account.

It could look this:

1. add a new parameter mtu wherever a packet duration is configured -- cli, public api etc. with default value of 1200 bytes (default mtu in webrc for various reasons) or 1480 (max for UDP in genuine ethernet).
2. if both packet duration and mtu are not configured by a user -- pick one of them which will lead to the least packet size.
3. if either one of them is set by a user -- use it and ignore the other. In case of error mention both parameters in an error message.
4. If both parameters are set two variants are sensible, not sure which one is better: a. return an error and abort b. log a warning and pick the one that lead to the least packet size.

@Ayoub-glitsh please share you opinion this.