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 (6)

  1. tongy says:

    I have a question, does this applicable to capture stream also?

  2. Good question; I don't know.

  3. ferongr says:

    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.

  4. 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.

  5. ferongr says:

    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.

  6. 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.

Skip to main content