> >Well, but when adding a+b we have no idea that that overlow will be compensated >by next very big negative sample. Also mixing signals which already fill 90% of >dynamic range is not a good idea. My "fix" is heuristic - it works for >occasional _small_ overflows like 0x4100+0x4000 -> 0x7fff is much better than >0x8100. > >The idea of dmix as I understand it is that buffer is already in the native >format for the sound card. So if sound card supports 24 bit, OK. But then >people will start mixing 24 bit samples :-) > >> 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 > >And here our "wider register" is 16bit. That means end users should not expect >too much if thay mix full power signals on it. > >BTW. If you have uncorrelated signals, then to mix 4 signals it may be good >enough to reduce the amplitude of them just factor 2, because power will drop >factor 4. Ocassionally there will be overrruns, but 0x7fff limit will make it >almost not hearable. Not a correct fix, but I can assure you that it works in >standard cases :-)
That's a good point. As long as we're dealing with 2 or 3 channels we probably can do with saturating. But we should consider adding a shift right by one (after adding, before saturation) once we have 4 channels, by two at 8 channels, or something similar. Otherwise we will start getting some ugly clipping artifacts. The problem is, this can cause a (noticable) sudden drop in volume when a "threshold" client connects/disconnects. We could ramp, but that's a multiplication... -------------- 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
