Re: achieving very low latency
Re: achieving very low latency
- Subject: Re: achieving very low latency
- From: William Stewart <email@hidden>
- Date: Mon, 09 Jul 2012 10:37:55 -0700
On Jul 7, 2012, at 8:16 AM, Paul Davis wrote:
On Fri, Jul 6, 2012 at 7:38 PM, William Stewart <email@hidden> wrote:
On Jul 5, 2012, at 7:48 AM, Paul Davis wrote:
On Thu, Jul 5, 2012 at 10:30 AM, Markus Fritze <email@hidden> wrote:
Any current Mac supports 16 sample buffer settings and it works just fine.
the buffer setting and the actual playback latency are not equivalent, even ignoring D/A issues. until the driver layer removes the safety buffer, this will always be the case.
i'm also not as confident of the claim that 16 samples always works as you seem to be. its also not as relevant as it might appear because there is a lot of audio interface h/w that doesn't support this setting.
Paul
This doesn't have anything to do with HW settings.
I understand this (very clearly, believe me). I am almost never interested in the number of samples that an audio app can render on each IO callback. The only thing I was referring to was the overall latency between the IO callback and whatever analog output device is in the path.I don't believe that many users care too much that the app they are using is processing 16 samples at a time if there is a queue of 4096 samples between its IO callback and the monitors.
Indeed, but your statement was ambiguous, so I thought it needed clarification.
This would be a good time for me to reiterate my profound respect for the way CoreAudio interacts with audio interface hardware. The fact that the drivers do *not* rely that heavily on the interrupt from the device is simply genius, and I wish very much that we had adopted this design on Linux back in 1999.
|
_______________________________________________
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