Built-in limiter in Audio HAL?
Built-in limiter in Audio HAL?
- Subject: Built-in limiter in Audio HAL?
- From: Peter Iannucci <email@hidden>
- Date: Mon, 26 Nov 2018 22:38:08 -0500
Hi all,
I'm working on an application that does IPv6 networking over ultrasonic
audio. I'm using the Audio Hardware API (need to control sample rate,
don't want any filtering applied, etc.).
I have an... unusual request, and a question. I'm running 10.13.2 on a
15-inch 2017 MBP.
I'd like for the capability to exist to bypass the system audio volume
control. No, I'm not (entirely) crazy. Ideally, everything else on the
system gets mixed and gain-adjusted, and then my (inaudible) signal gets
mixed in right before clipping.
One way that this could work without changing the system would be if my
IOProc exceeds the [-1, +1] range by a factor of (1 divided by volume). I
decided to give this a whirl using the built-in speakers, figuring that
Core Audio would probably clip my samples both before and after mixing them.
In fact, based on my experiments, my Mac mixes unclipped samples, then
applies a limiter, then clips, then quantizes; the system audio volume
control appears to be applied either after clipping, or else by an entirely
separate mechanism. Here's what I have been able to figure out. Can
anyone tell me anything more about how the limiter behaves? Is this
user-land behavior? Kernel? Driver? Hardware?
The limiter seems to have a minimum gain of -40 dB, and a maximum gain of 0
dB. Its attack is much faster than its release.
1. Playing a 440 Hz tone with an amplitude less than 100 produces a pop,
followed by a steady tone with no discernible odd harmonics on my spectrum
analyzer
2. Playing the same tone with an amplitude of 102 produces a pop, followed
by a tone with discernible odd harmonics.
3. Playing a tone with a rising linear amplitude ramp (amplitude >= 1)
gives a steady tone.
4. Playing a tone with a falling linear amplitude ramp (amplitude >= 1)
gives a pop followed by a decrescendo.
The limiter seems to have a very rapid, but not infinite, attack.
1. A single loud sample (amplitude 10000) does not trigger limiting.
2. 1 ms of loud samples does trigger limiting, in a buffer otherwise filled
with a 440 Hz amplitude-1 sinusoid.
The limiter seems to have a multi-stage release. The initial release seems
to be complete after one second, with the gain rising to -10 dB. After
about 2.8 seconds from the spike, the limiter ramps up to about -2.3 dB,
and then it stays there until at least 27 seconds from the spike (the limit
of my instrument; my ears didn't detect a third release within a minute,
while the first two were quite noticeable 1-second ramps). If I sustain
the tone for 9 seconds after the spike, then mute it for a second, and then
bring it back, the gain actually jumps up higher than it was before the
spike, by about 7.5 dB!
This is all most peculiar, and I am unaware of any relevant documentation.
I can clip my samples myself in order to avoid most of this behavior, but
I'm still at the mercy of other applications triggering the limiter to duck
my signal at the transmit side. If this happens, not only do I not know
how to detect the issue at the transmitter, but the receiver's job becomes
more difficult, because it cannot rely on steady levels.
My application could benefit from a deeper understanding of what's going on
here. Anything you can tell me would be very helpful.
Thank you very much,
-Peter Iannucci
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden