Re: Userland driver: Not enough headroom at first in IO operation.
Re: Userland driver: Not enough headroom at first in IO operation.
- Subject: Re: Userland driver: Not enough headroom at first in IO operation.
- From: Brian Willoughby <email@hidden>
- Date: Fri, 30 Aug 2013 13:59:43 -0700
Latency is intended to allow a CoreAudio application to compensate
for any timing delays in the software and hardware. It should not
affect the performance of your driver in any way. The only reason the
driver even deals with the latency number is because usually the
driver is the only piece of software that can determine the details
of the specific hardware related to latency. Implementation of
latency correction is entirely up to the CoreAudio host application,
while reporting of latency is the responsibility of the driver (and
other parts of CoreAudio).
In contrast, the Safety Offset is very much involved with the
implementation of a driver and it will affect your code as you've
seen. This parameter is provided so that your driver can coordinate
with CoreAudio to make sure there are no gaps in the audio due to the
multithreaded nature of OSX.
The behavior you are seeing is as expected (unless I've missed
something).
Brian Willoughby
Sound Consulting
On Aug 30, 2013, at 13:01, Eric Gorouben wrote:
As far as I understand, and after measuring the effect of these two
parameters on the IO loop, the safety offset is actually the exact
extra headroom frames added (inSampleTime ≈ theroretical_SampleTime
- safety_offset), while the latency seems to have no effect.
Is this correct?
Thanks
Eric
Le 29 août 2013 à 22:22, Ploytec a écrit :
I frequently can’t get enough headroom at the beginning of a
recording. My real sample time is sometimes significantly lower
than expected due to jitter, delay or drift.
The problem is especially acute when the device is aggregated.
Yet, at startup core audio doesn’t know about this jitter or delay
or drift. It expects an amount of available data (buffer size +
sample time) just slightly under the theoretical value of
available samples (given the sample rate and initial zero host time)
I’ve tried to play with the latency value or safety offset, but
this does not give good results (if any).
I’ve also tried fancy delays but probably too fancy…
What am I missing?
_______________________________________________
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