mechanism for frontend to report preferred samplerate to core

[zeromus]

Some cores may have the ability to output variable samplerates due to their internal structure (being able to run audio synthesis at virtually any rate, or running audio synthesis at an eccentric >100khz rate and adding a resampler to avoid creating surprising output for frontends).

Therefore the frontend should have a mechanism to state its preferred samplerate. This could avoid excess synthesis time in the core and potentially unnecessary resampling in the frontend.

However, If the frontend is essentially running at a flexible samplerate all the time due to syncing and rewinding, etc., then there's really no such thing as a 'preferred' samplerate such that resampling can be avoided, so this idea is not so useful. But still-targeting the frontend's basic output samplerate (e.g. 32khz for the wii) could still result in the core spending less time on audio synthesis if for instance it defaulted to a sensible 48khz.

While resampling may not cost much, audio synthesis of 48khz when only 32khz is needed.. well, it probably still doesn't cost much. But, considering this is essentially a free optimization, I don't see the harm.

One thing to be aware of: some core authors will mistakenly feel the need to add their own resamplers to meet the specified preferred samplerate. This would be a mistake--it's only meant for cores that already need to pick a samplerate. The documentation should make note of this.

[leiradel]

+1