Fix crash on Mac OS X caused by querying audio stream latency.

Fix crash on Mac OS X caused by querying audio stream latency.
BUG=109959
TEST=none
(covered by existing tests and tested locally with built-in audio,
 Metric Halo 2882, and Stanton FinalScratch Firewire devices to
 verify that crashes are fixed)

Incidentally, the stream latency was always reported as zero on the devices I tested,
so removing this code should have no practical impact.
Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=120095

[Chris Rogers, 2012-01-31 20:26:03]

Greg Simon reported this bug:
http://code.google.com/p/chromium/issues/detail?id=109959

I also consistently have the crash when using my Metric Halo Mobile I/O 2882
Firewire audio device.  The call querying stream latency, using the
kAudioStreamPropertyLatency selector is the one causing the problem.  The crash
happens every time AUAudioOutputStream::GetHardwareLatency() (the low-latency
output mac codepath) is called (and it's always called).  Removing the call to
query the stream latency fixes the problem.

Unfortunately, I'm not able to see anything wrong simply by looking at the code,
but there appears to be a subtle interaction with the CoreAudio system (and
possibly driver) itself which interacts with another thread.  gdb is of very
little help because it only happens on release builds, and gdb is unable to
properly load the .dSYM files for official builds.  But, the crash does invoke
Apple's Crash Reporter and apparently has enough symbol info (with
filename/line#) to point to the AudioObjectGetPropertyData() call querying the
stream latency. Trying to disassemble the code fails within gdb.

The crash is an odd one, and does not trigger breakpad to upload a crash report.

Incidentally, on all built-in macintosh hardware, this stream latency was
returning 0, so removing this line should not make any difference.

[henrika (OOO until Aug 14), 2012-01-31 21:28:06]

Chris,

Many thanks for digging in this tricky issue.

Shijing wrote these parts and he knows the details better than I do. I recall
that we discussed if the overhead related to the stream-delay and that it did
mostly result in zero-contribution. To me, it feels like a good solution to
remove it since it can cause issues. I'll let Shijing review first.

[no longer working on chromium, 2012-02-01 09:47:10]

Thanks Chris for fixing the problem.

I added the stream delay since the apple documents claimed that the stream
latency was part of the total latency, but I never saw a case where it was not a
zero. So removing those code sounds good to me.

And I am sorry for causing the problem, I did not see the crash issue when I was
writing the code, though I am not sure if I ever tried the release build at that
time.

I will take care of the input part.

BR,
/SX

[no longer working on chromium, 2012-02-01 09:49:38]

lgtm

[henrika (OOO until Aug 14), 2012-02-01 09:59:45]

LGTM.

[acolwell GONE FROM CHROMIUM, 2012-02-01 20:19:14]

On 2012/02/01 09:59:45, henrika wrote:
> LGTM.

LGTM

[Chris Rogers, 2012-02-01 20:21:38]

Hi Shijing, no need to apologize.  It was indeed a tricky one to debug and only
shows up in special cases (with USB and Firewire devices) and there's no obvious
mistake in any of the code...

On 2012/02/01 09:47:10, xians1 wrote:
> Thanks Chris for fixing the problem.
> 
> I added the stream delay since the apple documents claimed that the stream
> latency was part of the total latency, but I never saw a case where it was not
a
> zero. So removing those code sounds good to me.
> 
> And I am sorry for causing the problem, I did not see the crash issue when I
was
> writing the code, though I am not sure if I ever tried the release build at
that
> time.
> 
> I will take care of the input part.
> 
> BR,
> /SX