maxmitti
commented
4 years ago I also tracked this down and found out that the buffer_ms related crashes are based on a limitation of opus.
The passed frame_size must an opus frame size for the encoder's sampling rate. For example, at 48kHz the permitted values are 120, 240, 480, or 960. Passing in a duration of less than 10ms (480 samples at 48kHz) will prevent the encoder from using the LPC or hybrid modes.
https://www.opus-codec.org/docs/html_api/group__opusencoder.html#ga88621a963b809ebfc27887f13518c966
The value passed to opus_encode as frame_size is calculated as
int frames = chunk->size / chunk->frame_size / chunk->channels;
where
chunk->size = ctx->samples * ctx->channels * ctx->samplesize * ctx->read_ms / 1000
ctx->samples = samplerate from the sampleformat specification
ctx->samplesize =number of bytes per sample, i.e. bits per sample / 8 also from the sampleformat
ctx->read_ms =buffer_ms
chunk->frame_size is same as ctx->samplesize
chunk->channels and ctx->channels are the number of channels from the sampleformat specification
Ultimately, this leads to frames = samplerate * buffer_ms / 1000 which must be one of opus's accepted values.
With 48000:16:2 this would lead to frames = 48000 * buffer_ms / 1000 = 48 * buffer_ms.
Which results in 5760 for 120ms buffer_ms. However this frame_size is not supported by opus either, according to the documentation. So, either I messed up somewhere or the documentation is outdated, but at least it is a multiple of a supported frame_size.
Anyhow, the working values for buffer_ms are indirectly highly limited by what opus supports as frame_size. I did not even come to the point of realising that changing --buffer (I assume you mean -b) can also cause crashes.
christf
markusj
Currently running on branch mixer. Clients and server run on Debian Buster, the stream is provided by Mopidy.
snapcastc crashes for me for pretty much every configuration of buffer_ms and --buffer except for 120/500 respectively. I originally tried to increase --buffer to cope with bad WiFi conditions, but well, it did not work as expected. This is one valgrind trace I got while trying to figure out what happens:
Sometimes (e.g. with --buffer 1000), the server did not crash (immediately) but produced strange echo or beat artefacts.