Question about OGG packet size and streaming latency for Opus-based ASR

[eastack]

I’m building a streaming ASR application and currently sending audio in Opus/OGG format, as required by the ASR provider.

However, with my current setup, it takes almost ~1 second before an OGG packet is produced and sent, which introduces noticeable latency. I’m not sure whether this is the intended or recommended usage for real-time streaming.

Is it possible (or advisable) to reduce the OGG packet size or flush OGG pages more frequently?
Alternatively, would it make more sense to stream raw Opus frames to my backend service and encapsulate them into OGG there, instead of generating OGG packets on the client side?

Any guidance on best practices for low-latency streaming in this scenario would be appreciated.

[eastack]

Could PAGE_SIZE_TARGET in src/ogg/ogg-muxer.ts be made configurable? It seems like it might be related to this size.

[Vanilagy]

Hey, this is probably due to the Ogg muxer batching the Opus packets into pages. Having larger pages results in a smaller file sile at the cost of increased output latency, as you've correctly determined! When creating files for offline use, large pages are a non-issue, but for live-streaming it breaks down somewhat. I have two ideas here:

• Configurable page size: This is the most direct config one can conclude from the current muxer implementation, although it feels slightly low-level to me
• Time-based page flushing: Other containers in Mediabunny already have this feature where you can specify the duration a fragment/chunk/page must have before it can be flushed. Adding this option to the Ogg muxer might be easier to use: you can simply specify, "I want each page to be 0.1 seconds long at most," which is much more reliable than the page size-based approach as it's independent of the size of the underlying audio packets.

I think I might add the second approach!

Also, really happy the Ogg parts of Mediabunny are seeing use.

[Vanilagy]

Added maximumPageDuration in 2ab1be3

Lands in the next version!

[eastack]

I’m truly excited—and even moved—by how quickly you responded and by the seemingly better solution you provided. Seeing all of this happen so fast is incredible. Thank you for everything you’ve done; I can’t wait for the next version to be released.

[Vanilagy]

It's out in v1.28.0, try it!

[eastack]

Works really well overall, but I've noticed a potential issue that might be related to the browser and this configuration option. #282