Re: Built-in limiter in Audio HAL?
Re: Built-in limiter in Audio HAL?
- Subject: Re: Built-in limiter in Audio HAL?
- From: Brian Willoughby <email@hidden>
- Date: Mon, 26 Nov 2018 21:34:02 -0800
These are all very interesting observations. Thanks for sharing!
I expect that Apple has not documented, and will not document these details so
that they can be free to change the characteristics of the limiter and other
speaker processing on a model-by-model basis. It’s entirely possible that one
product’s speakers, enclosure, and electronics will need a significantly
different collection of processing. There’s not even a guarantee that all Apple
products support sample rates above 44.1 kHz, so the ultrasonic realm is on
shaky ground to start with.
That said, there was once a time when Apple released a detailed technical
document for every computer product, and there were usually plenty of details
of the type you observed. Apple’s web site has been reorganized since the last
time I found any of those documents, so I have no idea whether they still
provide them.
If you want to do IPv6 networking over ultrasonic audio, without being
vulnerable to either Apple’s speaker processing or any number of other audio
applications that your user might run, then your only real choice is to provide
separate audio hardware. At this point, you can guarantee higher sample rates
and perhaps even optimize the transducer for ultrasonics. However, I realize
that the user experience in this scenario involves tradeoffs. While your users
won’t have to worry about any audio apps that they might want to run, they will
have to contend with an audio interface accessory.
Brian Willoughby
On Nov 26, 2018, at 7:38 PM, Peter Iannucci <email@hidden> wrote:
> 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