Re: Underflow causes permanent silence
Re: Underflow causes permanent silence
- Subject: Re: Underflow causes permanent silence
- From: Benjamin Golinvaux <email@hidden>
- Date: Wed, 4 Sep 2002 15:11:38 +0200
In my audio proc, i need to call a function that,
99 times out of 100, takes only a couple of 5s but, sometimes, consumes
several hundreds of ms
(this is only a debug call, but i need it at the moment). When this
happens, the sound indeed disappears
for 5 or 6 seconds then everything is fine again.
The weird thing is : if, for some reason, a system sound plays during
those 5 seconds
(in another process i mean), then CoreAudio seems to instantly recover
and my callback is again called
normally.
I think it did not happen under 10.1 but I'm not totally sure.
Cound it be another "instance" of the same problem ?
If so, could we expect this fix to be included in 10.2.1(i need my
lengthy function for
debugging purposes so this fix would be great) ?
Thanks
Benjamin Golinvaux
On Saturday, August 31, 2002, at 01:17 AM, Doug Wyatt wrote:
If you'd brought this up 24 hours earlier you might have saved me some
time debugging last night, but I am checking in a change this
afternoon that should address this. Synchronicity :-)
Doug
On Friday, Aug 30, 2002, at 12:28 US/Pacific, Timothy J. Wood wrote:
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.
_______________________________________________
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.
_______________________________________________
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.