> > 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) [EMAIL PROTECTED] ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
