Re: dmix plugin

[Jaroslaw Sobierski <fycio@gucio.com>]

> > b) sum overflow: we can lower volume of samples before sum; I think that
> >    hardware works in this way, too
> 
> Here I don't understand you. Suppose we have 3 samples to mix:
> a = 0x7500
> b = 0x7400
> c = 0x8300
> 
> If you do a + b + c (in this order) you obtain:
> d=0
> d += a -> 7500
> d += b -> 0xe900 -> 0x7fff
> d += c -> 0x02ff
> 
> while the correct result is 0x6c00. You see?

AFAIK most hardware does not mix by reducing volume before the sum. On the
contrary, it is usually summed "as is" to a wider register, and often even so
used. For example, a sound card able to mix 16 chanels of 16 bits would have
a 16+4 bits or 24 bit register were the channels are added and no saturation
can occur. In good hardware this would not even be downscaled back to 16 bits,
but a 24 bit D/A converter would be used instead. In older times (Gravis Ultra
Sound and I think older SB AWE) this could easily be spotted by the difference
in supported "hardware" channels and "software" channels. A card with a 32 bit
sum register and 24 bit DA could support (as above) 16 hardware channels and 
for example 64 software channels (mixed together in quadrouplets to the 16 hw).

In our case, such "solution" would have to affect the whole buffer, meaning 
we would need 3 (or better yet 4) bytes per sample, which would eventually get
reduced back to 2 bytes on the way out to the sound card. This seems neither
elegant nor memory efficient but would work, and also solves the "a)" problem
because we don't need to saturate so an atomic add can be performed on each
sample. 

--------------
Fycio (J.Sobierski)
 fycio@gucio.com


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf