It's probably something we (https://overte.org/) can use.

We have a 3D environment with spatial audio. Audio is encoded server-side, and since it's spatial everyone needs their own mix. We're using Opus, and audio encoding turns out to be the usual limiting factor on small servers.

So this kind of thing is exactly up our alley: an alternate option that uses less CPU than Opus, but consumes less bandwidth than raw audio.

But adding supporting for FLAC is also on our list. It seems nicely performant when compared to Opus.

I'm curious, why encode audio server-side? Other games in this genre I've seen seem to have clients do encoding/decoding, and do the spatial audio clientside, with the server just passing each user's audio and position data along from client to client. Especially in VR where ideally there should be no latency between turning your head and the audio shifting. Are there any reasons to do this on the server, or am I misunderstanding something?

Doesnt Opus (speex?) have some low CPU settings?

It does, and I've tried tweaking that, but the performance difference isn't very significant.

I appear to be able to get maybe 30% better performance -- pretty nice, but not nearly big enough especially on low end servers.

I'm not sure much gets better latency than Opus but LyraV2 seemed interesting https://opensource.googleblog.com/2022/09/lyra-v2-a-better-f...

Could be an option, but we take high audio quality as a point of pride and encode in Opus 128k by default. Audio doesn't only include speech but also any sound effects, media present in-world, etc.

But that might be an interesting experiment. Right now the low cpu usage/high quality/faily high bandwidth usage category is something we're looking to have an option for.

Lyra is a speech-only codec, so it's apples and oranges to compare with Opus for general-purpose audio compression.

"very fast" could mean many different things that vary by orders of magnitude

in https://phoboslab.org/log/2023/04/qoa-specification he got ffmpeg on one core of an i7-6700k (which is arguably 'modern hardware') to encode a 9807-second file in mp3 in 146.2 seconds, 67× faster than real time. but qoa was 25.75 seconds, 5.7 times faster than that. qoa decoding was 2.5× as fast as dr_mp3

you can imagine situations where reducing the number of audio encoding servers in your audio encoding cluster by a factor of 6 would be a big win, or where you want to encode 100+ audio streams in real time on your laptop (maybe an sdr tuned to every am radio station at once), but i agree with you that battery-constrained devices are a more likely application area: making your audio recorder battery last twice as long is a much bigger win

"very fast" could mean many different things that vary by orders of magnitude