Re: Using MidiMan Delta 10x10 drivers
Re: Using MidiMan Delta 10x10 drivers
- Subject: Re: Using MidiMan Delta 10x10 drivers
- From: Bill Stewart <email@hidden>
- Date: Tue, 13 Nov 2001 11:08:20 -0800
On Tuesday, November 13, 2001, at 02:05 AM, Stephane Letz wrote:
I would imagine that this controls the hardware ring buffer size
in the
kernel. If so, you _really_ don't want to use small number for this.
This value effectively controls the number of hardware interrupts
per second
for the audio hardware. On other systems, the lower the number
the better
the latency.
On Mac OS X, this is not the case. This number has _no_ effect on
latency.
In fact, the lower this number the _worse_ your performance will
be because
the number of interrupts per second increases which makes life
much more
difficult for the rest of the system and increases the load on
the system
dramatically for no gain in system performance.
Does this means that on MacOSX the DMA interrupt is not directly
used to
wake up the codeaudio thread?
And that the coreaudio thread are wake up using the standard
system scheduler ?
Yes - that is correct - thus the accuracy and reliability of the
time stamps the driver lays down is *very* important.
So if i understand correctly DMA interrupt and codeaudio callback
management are not directly related. Is this correct?
Yes
I don't know why MIDIMan would want to expose this setting at all -
I'd ask them as there maybe something that this does for their
driver...
The buffer frame size range is synthesized by the HAL based on
the smallest
schedulable time quantum (roughly 300 microseconds) to 3/8ths the
size of
the hardware ring buffer. By adjusting the ring buffer size so
small, you
have effectively made it impossible for other clients to meet the
deadlines
you've imposed on them.
Where does the 14 frames value come from? could you explain this?
This is the smallest buffer for a user that the HAL is allowing -
its a lower bound limit we place on the buffer sizes that are
available.
(Whilst on the topic of buffer sizes - there is a new property in
10.1 that allows you to specify buffer size in frames rather than
bytes - and for a PCM formatted device this is far easier to use
than the byte size as it takes account (for you) of the n-channels
field based on whatever the device is configured to run at)
Technically, I'd rate this an application problem. They need to
make sure
they can cope with the buffer size the hardware allows them.
Clients of the
Sound Manager (like QuickTime) do this by not playing any sound
since they
can't keep up with those kind of demands. Probably most clients
won't be
able to keep up since the scheduling demands would be so tight
that the
scheduler wouldn't be able to meet them in the first place.
OK. So it seems that when using the MAudio Delta 10x10, the best
is to set
the DMA buffer size to the highest possible value (2048) and then each
application can choose it's period of IOProcs by setting it's
buffer size
from 14 up to 2048. Is this correct?
Then an application that need low latency must choose a small
buffer size.
(even if the DMA is large)
Yes - the "DMA" that is the default for built-in hardware is around
3/4 of a second
Bill
Stephane Letz
Grame: Centre National de creation musicale
9, Rue du Garet
69001 Lyon
Tel: 04-72-07-37-00
Fax: 04-72-07-37-01
Web: www.grame.fr
_______________________________________________
coreaudio-api mailing list
email@hidden
http://www.lists.apple.com/mailman/listinfo/coreaudio-api
mailto:email@hidden
tel: +1 408 974 4056
__________________________________________________________________________
Cat: "Leave me alone, I'm trying to nap... Ah, What's that clicking
noise?"
__________________________________________________________________________