coreaudio "ethernet audio" driver issues
coreaudio "ethernet audio" driver issues
- Subject: coreaudio "ethernet audio" driver issues
- From: rimas <email@hidden>
- Date: Thu, 28 Aug 2003 11:51:17 -0700
greetings,
i have written a coreaudio driver to support a custom audio interface i
have developed which communicates with its host machine via ethernet. my
driver generally works okay, but i'm running into problems when running CPU
intensive sound synthesis/analysis programs (i.e. MAX/MSP).
basically my driver behaves like a data link network kernel extension
(NKE). when it receives a packet containing audio data, it copies data
from the packet into the coreaudio buffer. then it makes a new packet,
copies the audio data from the coreaudio buffer into the new packet and
sends it off. ideally i'd like the reply packet to go out on the wire
before the next incoming packet arrives (although there is buffering built
into my device so some "slop" is okay).
i can observe the timing of the transmitted and received packets on an
oscilliscope i have hooked up to my custom hardware. the hardware
transmits packets very regularly (each packet has 32 sample frames in it)
regardless of whether it receives a reply packet. when i'm doing something
relatively non-CPU intensive (i.e. running iTunes) i can see that the
computer generally manages to send a reply packet before the next incoming
packet arrives, however fairly frequently the computer doesn't send a reply
packet before the next packet arrives, and then sends a cluster of two
packets back to back.
small gaps like that in the reply packets from the computer are tolerable
due to the buffering in the hardware.
however these timing irregularities become much much worse when i run a CPU
intensive patch in MAX/MSP (a visual programming language for sound
analysis/synthesis/etc). basically there will be long (5-10 millisecond)
gaps where no reply packet is sent and then a big burst of packets gets
sent all at once.
the discussion of Mac OS X kernel threading here (on page 8):
http://developer.apple.com/technotes/tn/pdf/tn2028.pdf
contains this snippet:
As far as the Mach scheduler is concerned, threads running within the BSD
kernel are like any other Mach thread. One
particularly interesting consequence of this is . When a high priority
thread wakes up it will
preempt a thread running within the BSD kernel. This happens regardless of
whether the high priority thread is a kernel
thread or a user thread. As long as the high priority thread does not
attempt to acquire a kernel funnel (that is, it makes no
BSD system calls), it can do its job despite the limited re-entrancy of the
BSD parts of the kernel. This design allows Mac
OS X to meet the real-time goals required by its real-time components, such
as the highly responsive audio playback
engine.
which leads me to believe that whats happening is that the thread which is
doing the computation for the synthesis (which ps -axM reports as having
prioirity 96 which i believe is the coreaudio callback thread) is treated
as having a higher priority by the scheduler, causing the kernel thread
which is running in the networking part of the BSD kernel to be stalled
until the synthesis thread yields. does this sound right ??
anyhow i am presently searching for a solution to this problem - a way to
improve the transmit/receive timing of my driver - any
advice/insight/pointers to further sources of information would be very
greatly appreciated !
one thing i tried was to bypass the network stack entirely by modifying the
AppleGMACEthernet driver in such a way that my driver could talk to it
directly. however this didn't result in any major improvement.
thanks in advance for any information, i can provide more details about my
situation if they might be useful
-rimas
_______________________________________________
coreaudio-api mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/coreaudio-api
Do not post admin requests to the list. They will be ignored.