AUDIO: Possible optimisations for the software mixer

[ccawley2011]

Some ideas on possible ways to speed up the software mixer:

• Allow AudioStream subclasses to report the integer size, so that conversion can be folded into the resampling and mixing code.
• Add a skip function to the AudioStream class to allow non-seekable streams to skip output when sound is muted without needing an intermediate buffer.
• Optimise for cases where the volume is silent or at the maximum value.
• Optimise for cases where the destination buffer is all or partially zeroed out.
• Restore the ARM assembly code that was previously removed in commit 99e5de9. This will require updating it for compatibility with Thumb-2 and ARMv3M to get it working on more devices. Issue #6957 will also need to be reopened and fixed.

[mikrosk]

I would also add the note from audio/mixer_intern.h: In the future, we might make it possible for backends to provide (partial) alternative implementations of the mixer, e.g. to make better use of native sound mixing support on low-end devices.

[mikrosk]

Oh and one more thing (I hope you don't mind ;)) -- another great optimisation would be adding an option to preload music data. Right now only the required amount of sample data is loaded, creating an uncomfortable dilemma between choosing less I/O for the price of bigger lag/delay.

This could be used in at least two ways, one could be a complete preload (a lot of free RAM => load/convert everything only once), the other being touching the disk only every 1-2 seconds.

[mikrosk]

Another thing we have noticed while profiling: many (if not all) engines do its own sample / mixing before reaching the generic mixer. For instance Scumm::IMuseDigiInternalMixer, it would be nice if all those M-bit -> N-bit and/or mono/stereo conversions and mixing could be handled (and optimised / disabled) at one place.

[ccawley2011]

Another thing we have noticed while profiling: many (if not all) engines do its own sample / mixing before reaching the generic mixer. For instance Scumm::IMuseDigiInternalMixer, it would be nice if all those M-bit -> N-bit and/or mono/stereo conversions and mixing could be handled (and optimised / disabled) at one place.

It should be possible to bypass the custom mixing in DiMUSE by selecting "Enable low latency audio mode" in the per-game options dialog. I'm only aware of a few other engines that do conversion independently of the mixer, namely SCI32 and the Broken Sword games.

[mikrosk]

Accidentally, those are exactly the games/engines I'm testing most so I may have been biased. What is the reason behind keeping those custom mixers?

[ccawley2011]

With SCUMM (and possibly SCI32), I think the custom mixer is more accurate to the original compared to using the global mixer directly. For Broken Sword 1 and 2, it's probably just because those engines are older.

[AndywinXp]

Hi! Please don't ever ever ever touch the Digital iMUSE internal mixer, as doing that will kill audio accuracy, 12-bit audio, and probably the whole system :-D (not to mention that we've been working very hard in the last two years to make that sound system accurate and glitchless).

[AndywinXp]

I think that we should always strive for accuracy when possible, so this includes doing sound samples handling and mixing in the same way the original does, when this has an effect on how the output sounds. Optimizations are always welcome of course, but I think there shouldn't be abstractions and optimizations in the event that they compromise the final product.

Just my two cents :-) (but really, don't touch the iMUSE mixer)

[mikrosk]

Of course, accuracy should always be the goal. However I see no harm in offering a low cost version (like the mentioned checkbox for SCUMM games). There's even more explicit option hidden in the mame opl called "FM_high_quality", basically lowering the quality in favour of speed.

So don't worry, nobody is going to mess with your valuable work. :)

[sev-]

Moved to Planka: ​https://planka.scummvm.org/cards/1382186040223074043