[sdlsound] SDL_sound v2's internal mixer format...

[Ryan C. Gordon]

> > 2) I reject the mixing to int32
> Ouch.  All right.  If these points don't convince you, I'll drop it.

(See below...)

> > this is extremely cache-unfriendly to keep jumping between different buffers
> > in memory, and it makes it difficult or impossible to use SIMD effectively.
> I'm not sure we need different buffers, converting in place works fine:

I'm sorry, I wasn't clear on several points.

"different buffers" == "different audio files being mixed together"

Rather than mix a sample point from a.ogg, b.wav, and c.mp3 into a
register and then drop that register's value into the output stream,
move on to the next sample point, and repeat, it's better to mix all (or
as much as needed) of a.ogg into the stream, mix b.wav on top of that,
and then c.mp3 on top of that. The cache thrashing comes from jumping
between X number of inputs at arbitrary locations in memory. You can
minimize cache misses by moving sequentially over a buffer (which also
makes using various cache prefetch operations possible, too).

Cache performance and memory bandwidth are the most serious issues on
desktop systems today.

The problem with audio vocabulary is every term has four different
meanings in different contexts ("sample" being the worst of them all). 

:)

As for int32...we _can_ do that, it's just another backend. My assertion
is that saying "just do everything in int32" isn't really going to be a
panacea, but that doesn't mean we can't accomodate int32 at all.

I still say games that would benefit from this are not the norm, but
there's no reason that they can't force an int32 format, callback or
otherwise, to resolve clipping issues; the rest of the games can ignore
this and benefit from lower memory bandwidth, lower cache pressure, and,
in the case of SIMD, more samples processed per-cycle.

Basically, I think we can handle all this and satisfy everyone, is what
I'm saying.

--ryan.