Implement GetAudioOutputDeviceNames for Mac OS X.

Implement GetAudioOutputDeviceNames for Mac OS X.

BUG=276894
R=tommi@chromium.org

Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=222217

[Jói, 2013-09-09 12:59:35]

Let me know if there is a more suitable reviewer or who might be able to help
with the following:

One thing that is mysterious to me, and I would appreciate any insight on:

See what happens when I run the unit tests without other tests:

Note: Google Test filter = AudioManager*
[==========] Running 1 test from 1 test case.
[----------] Global test environment set-up.
[----------] 1 test from AudioManagerTest
[ RUN      ] AudioManagerTest.GetAudioOutputDeviceNames
[58228:1799:0909/143856:36492189915964:VERBOSE2:audio_manager_unittest.cc(62)]
Testing platform-default AudioManager.
[58228:16899:0909/143856:36492192311083:ERROR:audio_manager_mac.cc(309)] Error
getting default AudioDevice.
[58228:16899:0909/143856:36492193315434:ERROR:audio_manager_mac.cc(309)] Error
getting default AudioDevice.
[58228:1799:0909/143856:36492206871437:VERBOSE2:audio_manager_unittest.cc(24)]
Got 2 audio output devices.
[58228:1799:0909/143856:36492206913297:VERBOSE2:audio_manager_unittest.cc(30)]
Device ID(default), label: Default
[58228:1799:0909/143856:36492206927591:VERBOSE2:audio_manager_unittest.cc(30)]
Device ID(AppleHDAEngineOutput:1B,0,1,2:0), label: Built-in Output
[58228:16899:0909/143856:36492207735127:VERBOSE1:audio_manager_base.cc(406)]
Firing OnDeviceChange() notifications.
[       OK ] AudioManagerTest.GetAudioOutputDeviceNames (18 ms)
[----------] 1 test from AudioManagerTest (18 ms total)


When I run them with all the other media_unittests, this is the output:

[----------] 1 test from AudioManagerTest
[ RUN      ] AudioManagerTest.GetAudioOutputDeviceNames
[58246:1799:0909/144003:36558973730423:VERBOSE2:audio_manager_unittest.cc(62)]
Testing platform-default AudioManager.
[58246:1799:0909/144003:36558974256926:VERBOSE2:audio_manager_unittest.cc(24)]
Got 2 audio output devices.
[58246:1799:0909/144003:36558974282878:VERBOSE2:audio_manager_unittest.cc(30)]
Device ID(default), label: Default
[58246:1799:0909/144003:36558974297310:VERBOSE2:audio_manager_unittest.cc(30)]
Device ID(AppleHDAEngineOutput:1B,0,1,2:0), label: Built-in Output
[       OK ] AudioManagerTest.GetAudioOutputDeviceNames (2 ms)
[----------] 1 test from AudioManagerTest (2 ms total)


Finally, and strangest of all, when I move that last VLOG in
audio_manager_unittest.cc one line down so that it is after the
AudioManager::Create, here's what happens:

joi-macbookpro2:src joi$ ./out/Debug/media_unittests
--gtest_filter=AudioManager* --v=2
Note: Google Test filter = AudioManager*
[==========] Running 1 test from 1 test case.
[----------] Global test environment set-up.
[----------] 1 test from AudioManagerTest
[ RUN      ] AudioManagerTest.GetAudioOutputDeviceNames
[58205:1799:0909/143846:36481652452195:VERBOSE2:audio_manager_unittest.cc(63)]
Testing platform-default AudioManager.
[58205:1799:0909/143846:36481652777804:VERBOSE2:audio_manager_unittest.cc(24)]
Got 0 audio output devices.
[       OK ] AudioManagerTest.GetAudioOutputDeviceNames (17 ms)
[----------] 1 test from AudioManagerTest (17 ms total)

Cheers,
Jói

[tommi (sloooow) - chröme, 2013-09-09 16:09:23]

lgtm

https://codereview.chromium.org/24072002/diff/9001/media/audio/mac/audio_mana...
File media/audio/mac/audio_manager_mac.cc (right):

https://codereview.chromium.org/24072002/diff/9001/media/audio/mac/audio_mana...
media/audio/mac/audio_manager_mac.cc:185: name.unique_id = 
AudioManagerBase::kDefaultDeviceId;
nit: one space after =

[Jói, 2013-09-09 16:15:44]

Any idea on the mysterious behavior I mentioned in the review email?

In the meantime, I don't think there is any harm checking this in, the test
works in all the normal cases, but it would be good to understand why it fails
in the edge case I mentioned.

Cheers,
Jói

https://codereview.chromium.org/24072002/diff/9001/media/audio/mac/audio_mana...
File media/audio/mac/audio_manager_mac.cc (right):

https://codereview.chromium.org/24072002/diff/9001/media/audio/mac/audio_mana...
media/audio/mac/audio_manager_mac.cc:185: name.unique_id = 
AudioManagerBase::kDefaultDeviceId;
On 2013/09/09 16:09:23, tommi wrote:
> nit: one space after =

Done.

[commit-bot: I haz the power, 2013-09-09 16:15:58]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/joi@chromium.org/24072002/12001

[tommi (sloooow) - chröme, 2013-09-09 17:21:38]

On 2013/09/09 16:15:44, Jói wrote:
> Any idea on the mysterious behavior I mentioned in the review email?
> 
> In the meantime, I don't think there is any harm checking this in, the test
> works in all the normal cases, but it would be good to understand why it fails
> in the edge case I mentioned.
> 
> Cheers,
> Jói
> 

That looks very strange.  No insights right now at least but I can look into it
tomorrow.  The API we're using on Mac has been known to cause problems when run
on anything but the main (first) thread of the process.  Could that have
anything to do with it?

[Jói, 2013-09-09 17:24:46]

It's running on the first thread of the process I think. The interesting
thing is when it fails if I don't VLOG before calling AudioManager::Create.
Perhaps there is some implicit initialization that needs to happen?


On Mon, Sep 9, 2013 at 5:21 PM, <tommi@chromium.org> wrote:

> On 2013/09/09 16:15:44, Jói wrote:
>
>> Any idea on the mysterious behavior I mentioned in the review email?
>>
>
>  In the meantime, I don't think there is any harm checking this in, the
>> test
>> works in all the normal cases, but it would be good to understand why it
>> fails
>> in the edge case I mentioned.
>>
>
>  Cheers,
>> Jói
>>
>
>
> That looks very strange.  No insights right now at least but I can look
> into it
> tomorrow.  The API we're using on Mac has been known to cause problems
> when run
> on anything but the main (first) thread of the process.  Could that have
> anything to do with it?
>
>
https://codereview.chromium.**org/24072002/<https://codereview.chromium.org/2...
>

To unsubscribe from this group and stop receiving emails from it, send an email
to chromium-reviews+unsubscribe@chromium.org.

[tommi (sloooow) - chröme, 2013-09-09 17:54:34]

Yes, maybe.  What I was thinking about was that if worker threads are
spawned and the VLOG gives them a chance to initialize.


On Mon, Sep 9, 2013 at 7:24 PM, Jói Sigurðsson <joi@chromium.org> wrote:

> It's running on the first thread of the process I think. The interesting
> thing is when it fails if I don't VLOG before calling AudioManager::Create.
> Perhaps there is some implicit initialization that needs to happen?
>
>
> On Mon, Sep 9, 2013 at 5:21 PM, <tommi@chromium.org> wrote:
>
>> On 2013/09/09 16:15:44, Jói wrote:
>>
>>> Any idea on the mysterious behavior I mentioned in the review email?
>>>
>>
>>  In the meantime, I don't think there is any harm checking this in, the
>>> test
>>> works in all the normal cases, but it would be good to understand why it
>>> fails
>>> in the edge case I mentioned.
>>>
>>
>>  Cheers,
>>> Jói
>>>
>>
>>
>> That looks very strange.  No insights right now at least but I can look
>> into it
>> tomorrow.  The API we're using on Mac has been known to cause problems
>> when run
>> on anything but the main (first) thread of the process.  Could that have
>> anything to do with it?
>>
>>
https://codereview.chromium.**org/24072002/<https://codereview.chromium.org/2...
>>
>
>

To unsubscribe from this group and stop receiving emails from it, send an email
to chromium-reviews+unsubscribe@chromium.org.

[commit-bot: I haz the power, 2013-09-09 21:54:39]

Retried try job too often on win_rel for step(s) browser_tests,
chrome_frame_net_tests, chrome_frame_tests, chrome_frame_unittests,
content_browsertests, mini_installer_test, nacl_integration,
sync_integration_tests
http://build.chromium.org/p/tryserver.chromium/buildstatus?builder=win_rel&nu...

[Jói, 2013-09-10 08:42:04]

Committed patchset #4 manually as r222217 (presubmit successful).