Linearity of Windows volume APIs - IAudioMeterInformation and full-scale signals
This blog post has moved to https://matthewvaneerde.wordpress.com/2011/05/11/linearity-of-windows-volume-apis-iaudiometerinformation-and-full-scale-signals/
Comments
Anonymous
July 18, 2011
I have a question, does this applicable to capture stream also?Anonymous
January 03, 2012
Good question; I don't know.Anonymous
January 01, 2014
Somewhat late, but a discussion at HydrogenAudio about null-testing digital signals brought me here. What were the justifications for deciding to limit output signal amplitude? Was it something done to prevent hard clipping (though in that case the limiter could presumably operate at -0dBFS) or another reason? This is more like idle curiosity on my part. I understand that a limiter operating at ≈ -0,1313 dBFS will definitely not be audible.Anonymous
January 01, 2014
The limiter is there to simplify mixing, and playback of sources which are outside of the (-1, 1) range. It doesn't really serve any purpose if there is only one stream playing and the source is already in the (-1, 1) range.Anonymous
January 02, 2014
That means it doesn't limit at all with a single source playing audio (e.g. WMP) then, right? If this is true then this sets a large misunderstanding about what it does straight.Anonymous
January 02, 2014
If you give WMP a file containing audio outside of the [-1, 1] range, WMP will happily hand the out-of-range data to its IAudioClient, so a limiter is necessary sometimes even in the single-source case. The limiter is almost always in effect, even when it doesn't serve any real purpose (single-source with in-range data.) There are a few exceptions though, e.g., streaming Dolby Digital audio to a receiver with a hardware decoder.