Does the built-in snapcast client support Opus codec?

[tilllt]

I configured my snapcast server to transmit the streams compressed with the "opus" codec. Both Chrome and Firefox have built-in Opus codec support. Still, when activating the snapcast server in Mopidy-Iris a modal box pops up saying "Codec not supported: opus". Is this a configuration mistake on my side or does the client indeed not support the opus codec?

Bonus question: is this error message referring to that lack of opus support in the browser or in the snapweb client?

[kingosticks]

Iris includes a copy (?) of snapweb, including a copy of its missing support for Opus. See badaix/snapweb#8

[tilllt]

It's especially unfortunate since the ESP32 snapclients ONLY compressed option is opus (or uncompressed PCM)

[tilllt]

And another question, sorry if thats obvious: why does snapweb needs to have its own OPUS implementation and cannot use the browsers built-in opus codec?

[kingosticks]

Because it (along with all of snapcast) is designed to provide synchronised playback across multiple clients. To do that requires a more complicated playback algorithm. The regular playback in the browser cannot do that. It doesn't matter if you are not using the synchronisation feature, that's how it works.

[jaedb]

This is really a question for the Snapweb author because the Iris implementation is derivative of that. Quite literally, src/js/components/SnapStream.tsx comes from the Snapweb project.

FWIW: you are also more likely to get useful answers by posting questions like this on the Discourse forum, rather than the Iris issue tracker.

[jaedb]

What @kingosticks said ☝️
I am relatively fresh when it comes to understanding the inner workings of audio streaming.

[tilllt]

Because it (along with all of snapcast) is designed to provide synchronised playback across multiple clients. To do that requires a more complicated playback algorithm. The regular playback in the browser cannot do that. It doesn't matter if you are not using the synchronisation feature, that's how it works.

Sure. But as it is stated in the README of Snapcast, it does achieve sync but dropping/duplicating single samples to speed up playback, so in theory this could be done before or after the stream is transported with build-in (or HW implemented) codecs, like opus?

Knowing the server's time, the chunk is played out using a system dependend low level audio API (e.g. ALSA) at the appropriate time. Time deviations are corrected by playing faster/slower, which is done by removing/duplicating single samples (a sample at 48kHz has a duration of ~0.02ms).
Typically the deviation is below 0.2ms.

[kingosticks]

I don't believe the browser audio API provides any mechanism to do that but if you have an implementation please discuss/provide it at badaix/snapweb#8

[tilllt]

I will take the issue to Snapweb, but this sure sounds as if it was possible to adapt playback speed:
https://developer.mozilla.org/en-US/docs/Web/API/AudioBufferSourceNode/playbackRate