Re: Latency Paper
Re: Latency Paper
- Subject: Re: Latency Paper
- From: Karl MacMillan <email@hidden>
- Date: Fri, 3 Aug 2001 22:54:43 -0400 (EDT)
On Fri, 3 Aug 2001, Bill Stewart wrote:
>
on 3/8/01 11:50 AM, Karl MacMillan wrote:
>
>
> For those of you that saw my latency paper
>
> (http://mambo.peabody.jhu.edu/~karlmac/publications/latency-icmc2001.pdf) I
>
> made a minor update to the MacOS X numbers. The latency in the original paper
>
> was incorrect. The correct value is 3.97ms, which is still the best system
>
> with load. I'm surprised no one noticed since the original number was below
>
> the minimum settings that CoreAudio seems to allow (at least on my system).
>
>
>
> Thanks,
>
> Karl
>
>
>
>
Actually I'd noticed. However this figure is too high, the theoretical round
>
trip latency is 2.902 msecs with the minimum buffer allowed in 10.0.x
>
systems. Any other overhead is introduced by co-ordinating the copy from the
>
input to the output buffers of the two different devices and how these two
>
IO Procs might "beat" against each other.
>
Well, I don't think that this figure is too high, but I would certainly
like some discussion on the point. I don't think that it was a problem
with the coordination of the IOProcs as the callbacks seemed to be made in
a very consistent and predictable way.
>
However - for hardware that publishes both an in and out stream, then the
>
throughput latency is 2.902 msecs (at 44.1KHz) plus whatever latency is
>
introduced by the actual D-A process of the hardware layer (in the case you
>
tested of built-in hardware, that should be barely detectable).
>
Are you talking about a unified IOProc? I was testing with two IOProcs (of
course). As far as the convertor latency, I am certainly not familiar with
the details of the built-in hardware, but the hardware types that I have
talked to suggested that modern convertors should introduce a measurable
latency. The figures that I got for most of the systems seem to agree
with the MacOS X numbers as far as the latency of the convertors. I
would be interested if you have the actual figures for the latency of
these convertors because that could easily clear up this matter.
One of the big points of doing this research for me is to get an idea of
the actual latency that can be acheived by a competent programmer (i.e. me
:)) when the entire system is taken into account. Across the board I have
gotten higher numbers than the theoritical numbers put forward by most
people and I think that a lot of this can be attributed to the latency of
the convertors.
>
I've also heard several concerns raised about your figures for Mac OS 9 -
>
they seem far worse than they should actually be. Did you test other
>
hardware solutions on Mac OS 9 - like a DigiDesign system for instance, an
>
RME card, a MoTU system? These are systems that are used in the professional
>
space and have a very high reputation for latency performance, but your
>
paper didn't present any figures on those systems that I could see.
>
I am looking into these concerns about OS 9, but won't be finished with
them for a while becuase of other things going on. I did test a system
with a Motu PCI324 card (and those numbers are in the paper), but that was
the only system that I had access to with a professional card.
>
Mac OS 8/9 is in a similar position to the Linux based systems your paper
>
discusses, in that you are profiling in effect custom solutions that involve
>
extensive work at the very lowest levels of the operating system (for
>
instance you substitute a custom kernel in Linux, or with a Digi system you
>
substitute a custom driver stack on OS 9), but on that point the comparison
>
would be fair and compares the "best of breed", customised solution
>
delivered on a given platform.
>
Well, the custom linux systems didn't do any better than the stock RedHat
systems in the test. I take your point, though. What I tested is what I
see people actually using who take music making with computers seriously.
It would be nice if these was stock systems, but in many cases it isn't.
>
I think the telling point for Mac OS X in all of this (which also includes
>
the figures you quote for Windows) is that it is a latency figure that is
>
generated by a shipping, non customised, come as it is, out of the box
>
solution. Furthermore, the audio device CAN BE SHARED even at this
>
low-latency figure between multiple applications. On page 2, 2nd column, you
>
make a considerable point of this capability with one of the Linux systems
>
without mentioning Mac OS X in that context - (unfortunately:)) that is
>
mentioned in a separate paragraph on page 3.
>
I agree with you completely. It is definitely unfortunate that the great
features of MacOS X did not make it into all parts of the paper, but the
numbers almost didn't make it at all. I hesitated to put them in because
they were obtained only hours before the deadline for the paper, but I
thought it was important so I went ahead. Obviously I should have doubled
checked my very simple math . . .
>
Still we were pleased to see the figures you quoted being within the
>
ballpark of the results we'd have expected.
>
I'm glad you are happy with the results, but I would like to clear up you
remaining doubts about the numbers if you are willing to cooperate.
Additionally, one of your engineers offered RME hammerfall drivers - if I
could get those it would certainly help by allowing me to test a
professional card under MacOS X. It will mean making some hardware changes
in machines that aren't mine, but I think that I can arrange it. Any
results of these won't make it into the paper, but I can present them at
the Internation Computer Music Conference in September.
Karl
>
Bill
>
>
>
mailto:email@hidden
>
tel: +1 408 974 4056
>
__________________________________________________________________________
>
Cat: "Leave me alone, I'm trying to nap... Ah, What's that clicking noise?"
>
__________________________________________________________________________
>
>
---------------------
Karl W. MacMillan
Computer Music Department
Peabody Institute of the Johns Hopkins University
email@hidden
mambo.peabody.jhu.edu/~karlmac