Re: Resetting IOAudioEngine Timing Mechanism?
Re: Resetting IOAudioEngine Timing Mechanism?
- Subject: Re: Resetting IOAudioEngine Timing Mechanism?
- From: Heiko Panther <email@hidden>
- Date: Thu, 31 Oct 2002 10:46:44 +0100
Dirk,
you should try to do your splitting work in your ClipOutputSamples /
ConvertInputSamples routines. As I get it, these are called in the
context of the HAL thread, which has highest priority.
If you consider doing work in the hardware interrupt - don't do it. Let
me quote this posting from Godfrey in darwin-development, 2002-10-12:
-----------------------------------------------------
From: Godfrey van der Linden <email@hidden>
Subject: Re: Raise priority on EvenSource handling
Actually a timer wouldn't help you as you aren't competing with
another work loop, probably. I'm guessing but most of the
interesting priority problems we have had are usually IOAudio related.
Assuming the issue is IOAudio where you have a classic priority
inversion. Between the audio thread and the workloop that services
the audio thread. What is the solution?
Does it surprise anybody on this list that I recommend a
non-traditional solution. Most programmers say, 'Well if my work
loop is being held off then FINE I'll just use the interrupt to do
lots and lots of work and my life will be fine, and the systems
throughput is NOT my problem'. The ostrich solution in otherwords.
I propose something more subtle. Getting thread priorities right can
be a sublte art. The key is to break the job into clear cut tasks
and try to assign relative importance to the task.
So with Audio throughing (i.e. input, signal process, output) what
are the tasks?
1> hardware is free-running and storing data. Periodically it has
sufficient captured and needs to notify some customer that data is
available.
2> Collection of data and copying into a buffer that the client can use.
3> Signal process of collected data as soon as possible after the
data is collected and using as much CPU as we can for sophisticated
AUDIO processing.
Now the priority inversion comes from step 3 using so much processing
time that it starves itself of data from step 2 by holding it off for
too long.
Solutions:
Combine step 1 and 2. Pro simple and obvious good thing under KISS.
Con possibly holds off other real time threads for far too long. May
be KISS should be KISSS: Keep it sufficiently simple stupid.
Don't allow step 3 to hog the processor. In other words the
programmer who wrote the real time thread needs to understand that he
has been given tremendous power and he need to accept the
responsibility of not shooting him/her self in the foot. Con: Earth
to Godfrey, this is the *real* world!
Last solution: Priority handoff. Say your interrupt fires and your
drivers notes that it has data available and schedules the work loop
to coelesce/copy the data when it gets around to it. In the mean
time the real time thread says, hey GIVE me some data NOW. Well your
driver knows some data is available so it uses the client's real time
thread to PIO the data out of the chip. Then when the work loop
finally gets around to scheduling it just says hey no copy to do,
cool I'll just go on with some housekeeping. Finally if the real
time thread runs for more than say 125ms then YOUR driver is allowed
to break. Any program that uses 100% of the CPU for 125ms
continuously without giving the system any time at all deserves to
fail. Pro get the priority at exactly right at each level so we can
maximise the efficiency of the system under all possible loads. Con:
Unless the code was designed this way in the first place it can be
tricky to balance the locking between the real time thread and the
work loop.
-----------------------------------------------------
_______________________________________________
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.