Re: I/O Latency (Was: Layman with a mission)
Re: I/O Latency (Was: Layman with a mission)
- Subject: Re: I/O Latency (Was: Layman with a mission)
- From: William Stewart <email@hidden>
- Date: Wed, 13 Oct 2004 10:17:12 -0700
I think there's one point that needs to be clarified. The I/O mechanism used
by CoreAudio is not buffered in the way that Dennis is asserting.
How it works is this. You have the time as it is now - the time when your
application's I/O proc is called. At that time, the application is presented
with all of the input samples from the I/O size (lets say 64 samples) up
until "now" (I'll come back to "now" in a moment)... So, this means that you
get the most recent 64 samples you possibly can on input.
On output, you are asked to produce the I/O Size - 64 samples - of audio
that will be played 64 samples (the I/O size) from "now". This gives you a
full 100% of the CPU to use to calculate/process/etc... those 64 samples.
By "now" I mean this. On the input side, the "now" is the real, "what is the
time now" minus the safety offset of the driver. So, if the safety offset is
24 samples, then "now" for input is the real now - 24 samples - so you get
the 64 samples that were written in up to 24 samples ago. On output, "now"
is the real now plus the safety offset of the driver.
There is *NO* buffering going on here in the I/O mechanism. There is *NO*
penalty in latency going on here. These comments are all dependent on
whether the driver itself does buffering of course, but the system itself
does not require it.
This safety offset is often abused by driver writers. I think the real
question is this - why are some of the "professional quality" audio devices
and their drivers performing so badly? Have you asked the companies that
produce these products about these problems? We continue to have an open
invitation to *any* driver developer to help work on their code/interface
and I am sure that unhappy customers will exert a great influence to have
these companies fix their problems.
Bill
On 13/10/04 2:10 AM, "Angus F. Hewlett" <email@hidden> wrote:
> Dennis Gunn wrote:
>
>> I replied to William's other points in longer post that is actually so
>> long it is awaiting moderation but probably the biggest the thing that
>> I am asking about here specifically is if it would be possible to
>> simply have a mode where the clock of the application is locked
>> directly to the clock of the IO and there is no need to have buffers
>> to accommodate jitter or unmatching clock rates or whatever (yes I
>> know I am a layman and "simply" is easy for me to say)
>
> That's not possible on a general purpose computer running a general
> purpose OS - you always have to have some kind of buffering. Specialist
> dedicated hardware (DSP-powered hardware/software synths like Virus, and
> DSP-farm cards like Pro Tools TDM and Creamware SCOPE), do work in that
> way and get lower latency as a result.
>
> OS 9 did allow more direct access to the hardware, and GigaStudio on
> Windows goes to even greater lengths (effectively, it runs its entire
> audio engine as a low level system driver rather than a user
> application); however, the general feeling these days is that drivers
> and the low-level parts of the system should be left to specialist
> driver developers and the developers of the OS itself, and third party
> apps should stick *strictly* to "user mode" and trust that the driver
> and system guys are doing their best to provide the lowest latency
> environment that will run safely on the OS. Dennis - if you're
> interested, mail me off-list and I'll dig out some links which explain
> the architecture of a modern OS - all modern desktop OS (OS X,
> Unix/Linux, WinNT/2K/XP) follow pretty much the same principles. In any
> case - even doing things the OS 9 way, you'd still need some degree of
> buffering as a) the link between the CPU and the audio AD/DA converters
> just isn't as direct as on a Virus or a TDM farm, and b) even on 9, the
> CPU can get interrupted by other tasks and has to buffer things for long
> enough to deal with them without gapping.
>
> This is getting a bit OT for the list, but, what it comes down to is
> that this approach will lead in the end to MUCH greater stability. Now,
> I know a lot of working musicians who complain bitterly that X is no
> more stable than 9, and who can't understand why developers keep on
> about how much better and more stable it is, but bear this in mind:- X
> is really a complete rewrite; a lot of software and drivers for it have
> also had to be (re)written from scratch; and, as such, it's not had that
> much time to bed in - whereas, 9 (and the software running on it) was a
> continuation of developments going way further back. The OS itself is
> absolutely rock solid now, but the apps themselves will take a little
> longer to bed in. Once they do, however, I am 100% certain that X will
> be more stable, for everyone, than 9 ever was. It also makes a whole
> bunch of cool stuff possible that just couldn't be done on 9.
>
>> I assume that in as much is as it relates to this latency issue that
>> is the single biggest difference between OS9 where there was no big
>> buffer between the application and the IO hardware and OSX where there
>> is a kind of huge one. For somebody using a DAW it just is not really
>> a consideration, we do not want the OS to do the jitter compensation
>> since jitter is an issue between clock that are not synced, nor do we
>> want the real time SRC. What we want is for everything to be locked up
>> in tight sync and run a low latency with no processing being done
>> outside the DAW app whatsoever.
>
> Yep.. problem is, on any modern, general purpose desktop OS, the DAW
> always has to share CPU time with other tasks (the OS just will not run
> without them), and it always, without exception, has to buffer enough
> audio so that the audio hardware can keep streaming without gaps for as
> long as the CPU gets interrupted by those other tasks. There is just no
> getting away from that - the OS guys can try to make the task handling
> as smart as possible, allowing the buffers to be made smaller, but it'll
> never go away completely. The only alternative is to do all your audio
> processing on some kind of dedicated hardware with direct access to the
> AD/DA convertors. That's one of the main reasons Digidesign can still
> charge $$$$$$ for Pro Tools hardware.
>
> Best regards,
>
> Angus.
--
mailto:email@hidden
tel: +1 408 974 4056
__________________________________________________________________________
Culture Ship Names:
Ravished By The Sheer Implausibility Of That Last Statement [GSV]
I said, I've Got A Big Stick [OU]
Inappropiate Response [OU]
Far Over The Borders Of Insanity And Still Accelerating [Eccentric]
__________________________________________________________________________
_______________________________________________
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