Udostępnij za pośrednictwem

Linearity of Windows volume APIs - IAudioMeterInformation and full-scale signals

  • Artykuł

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.