Re: Resetting IOAudioEngine Timing Mechanism?
Re: Resetting IOAudioEngine Timing Mechanism?
- Subject: Re: Resetting IOAudioEngine Timing Mechanism?
- From: Dirk Musfeldt <email@hidden>
- Date: Thu, 31 Oct 2002 16:00:36 +0100
Heiko,
thank you for your help. As you might have noticed Jeff Moore suggested just
that: do more work in the primary interrupt.
I already tried that but gave up when I noticed that my machine didn't do
anything more than cursor moves.
With kind regards
Dirk Musfeldt
Meilenstein Mac OS Software
Neue Strasse 5
D-31582 Nienburg
Germany
Tel: +49 (0) 5021 91 24 44
Fax: +49 (0) 5021 91 24 45
<
http://www.meilenstein.de/>
>
Von: Heiko Panther <email@hidden>
>
Datum: Thu, 31 Oct 2002 10:46:44 +0100
>
An: email@hidden
>
Cc: email@hidden
>
Betreff: Re: Resetting IOAudioEngine Timing Mechanism?
>
>
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.