Re: Underflow causes permanent silence
Re: Underflow causes permanent silence
- Subject: Re: Underflow causes permanent silence
- From: "Timothy J. Wood" <email@hidden>
- Date: Fri, 30 Aug 2002 12:28:02 -0700
On Friday, August 30, 2002, at 11:41 AM, Jeff Moore wrote:
On Friday, August 30, 2002, at 10:56 AM, Timothy J. Wood wrote:
I'm working on a ObjC wrapper around audio units for our game
ports. One of the obvious features is a stream that has a QuickTime
decoder attached to one end and I/O proc attached to the other end.
This all works fine (with the QT decoding happening in one thread and
the I/O proc happening in the HAL thread).
Now, the problem is that if I'm in the debugger, and hit ctrl-c to
stop my program for some reason, or worse, when loading the QT
decompression components the debugger hangs while reading symbols,
this causes CoreAudio to get grumpy with me somehow and I only get
silence from then on even though my decoding and I/O proc seem to be
working just fine.
You should not expect to recover properly from hitting a breakpoint in
gdb in the HAL's IO thread. This throws a huge unbounded amount of
time into things and the HAL just can't recover.
It's a huge pain for debugging and we're always looking for ways of
making it better, but right now it's not going to work too well.
I guess I don't understand why this is the case. If one I/O proc
isn't supplying buffers fast enough, I would expect it to get dropped
from the output. But, each time my I/O proc is called, it should get
the appropriate sample time passed to it. If it starts returning
within an appropriate amount of time, then those buffers should be used.
The current behavior seems pretty fragile -- if the machine chugs for
some reason, audio may break and won't gracefully recover. Worse,
there doesn't seem like a good way to detect that CoreAudio is unhappy
with me and has started ignoring my buffers.
One interesting point here is that when this happens, if I stop for a
short enough period of time I get something like (with logging of the
time stamps enabled for each I/O proc call):
...
iofill: inTimeStamp=(mSampleTime=68608.000000, mHostTime=0x4383454cc7
^C
Program received signal SIGINT, Interrupt.
0x90074328 in mach_msg_trap ()
(gdb) c
Continuing.
iofill: inTimeStamp=(mSampleTime=69120.000000, mHostTime=0x43834b2f55
...
But if I stop for long enough to cause sound to break, I get:
...
iofill: inTimeStamp=(mSampleTime=116224.000000, mHostTime=0x43862d0d0f
Program received signal SIGINT, Interrupt.
0x90074328 in mach_msg_trap ()
(gdb) c
Continuing.
iofill: inTimeStamp=(mSampleTime=116736.000000, mHostTime=0x4385e769e8
...
Note that in the second case the mSampleTime has progressed between
the two calls, but the mHostTime has gone backwards!
(I'm assuming that my logging is OK here -- I'm using '0x%qx' to log
the 64-bit value)
My current thought is that I could implement a "You don't love me
anymore" hook where if a I/O proc detects time going backwards, it
would signal some logic that would disconnect some or all of the
AudioUnit graph and then reconnect it. This would be a terrible hack
full of race conditions, but it might be sufficient for getting
debugging to not totally destroy audio output.
It may also be worth nothing that when I was debugging audio code for
Giants (where we directly used the HAL) I didn't have this problem.
That was on 10.1 though, so maybe something in 10.2 is responsible for
this or maybe its the AudioUnits layer that is responsible.
-tim
_______________________________________________
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.