1406981 - going to about:support crashed my browser

Status: RESOLVED FIXED

(Core :: Audio/Video: cubeb, defect, P2)

Description

[Michael Froman [:mjf]]

Attachment: Apple's crash report info

The whole browser crashed, not just a content process, when I went to about:support.  I'm running Nightly 58.0a1 (2017-10-09).  I do have a 6 Firefox windows with a fair number of tabs open, but less than 30 tabs total.  At the moment, if I allow Firefox to restore my session, and then open a new window and try about:support again, it is a repeatable crash.

Comment 1

[Michael Froman [:mjf]]

Nothing current is showing in about:crashes

Comment 2

[Michael Froman [:mjf]]

For the record, creating a new profile does not stop the crash going to about:support.

Turning off my MOTU 828mk3 *does* stop the crash on about:support.

I will check for a driver update.

Comment 3

[Michael Froman [:mjf]]

Updating to the latest available driver (v1.6.73220) does not fix the crash.

Comment 4

[Michael Froman [:mjf]]

One further note, using the MOTU 828mk3 as an audio device works fine.  It is only going to about:support that causes an issue.

Comment 5

[Jean-Yves Avenard [:jya]]

Guessing a cubeb issue

Comment 6

[Michael Froman [:mjf]]

Seems to crash here: CoreAudio`AUHAL::GetHardwareAudioChannelLayout
First few lines of backtrace:
    frame #0: 0x0000000186de643e CoreAudio`AUHAL::GetHardwareAudioChannelLayout(CAAudioChannelLayout&)
    frame #1: 0x0000000186de66ef CoreAudio`AUHAL::GetAudioChannelLayout(unsigned int, unsigned int, AudioChannelLayout*, unsigned char&) + 57
    frame #2: 0x0000000186ddbf67 CoreAudio`AUBase::DispatchGetPropertyInfo(unsigned int, unsigned int, unsigned int, unsigned int&, unsigned char&) + 607
    frame #3: 0x0000000186e7a976 CoreAudio`AUMethodGetPropertyInfo(void*, unsigned int, unsigned int, unsigned int, unsigned int*, unsigned char*) + 112
    frame #4: 0x00000001089c166a XUL`mozilla::widget::HeadlessClipboard::AddRef(this=0x0000000000000002) + 18070218 at HeadlessClipboard.cpp:14
    frame #5: 0x00000001089c367a XUL`void nsAutoOwningThread::AssertOwnership<34>(this=0x00007fff5fbf24e0, aMsg=<no value available>) [34]) const - 18446744069270129029
    frame #6: 0x00000001089be585 XUL`mozilla::widget::HeadlessClipboard::AddRef(this=0x00007fff5fbf2501) + 18057701 at HeadlessClipboard.cpp:14
    frame #7: 0x00000001067864bc XUL`mozilla::dom::TestInterfaceMaplike::cycleCollection::TraverseNative(this=0x00007fff5fbf25b8, p=0x000000010218b901, cb=0x000000010f8653b8) + 6395596 at TestInterfaceMaplike.cpp:13
    frame #8: 0x00000001067871c1 XUL`mozilla::dom::TestInterfaceMaplike::cycleCollection::Unlink(this=0x000000010218b978, p=0x00007fff0000b9a8) + 6399041 at TestInterfaceMaplike.cpp:13
    frame #9: 0x0000000104d19cd9 XUL`nsIconProtocolHandler::nsIconProtocolHandler(this=0x00000001285df340) + 800969 at nsIconProtocolHandler.cpp:20

Comment 7

[Paul Adenot (:padenot)]

(In reply to Michael Froman [:mjf] from comment #4)
> One further note, using the MOTU 828mk3 as an audio device works fine.  It
> is only going to about:support that causes an issue.

I know we have a problem with this MOTU. I wanted to diagnose it, but playing any sound on my system with it plugging in resulted in an OSX kernel panic.

Chun-Min, this is in your about:support page, can you have a look?

Comment 8

[C.M.Chang[:chunmin]]

(In reply to Paul Adenot (:padenot) from comment #7)
> I know we have a problem with this MOTU. I wanted to diagnose it, but
> playing any sound on my system with it plugging in resulted in an OSX kernel
> panic.
> 
> Chun-Min, this is in your about:support page, can you have a look?
Sure.

/src/cubeb_audiounit.cpp#1138,1151(In reply to Michael Froman [:mjf] from comment #6)
> Seems to crash here: CoreAudio`AUHAL::GetHardwareAudioChannelLayout
> First few lines of backtrace:
>     frame #0: 0x0000000186de643e
> CoreAudio`AUHAL::GetHardwareAudioChannelLayout(CAAudioChannelLayout&)
>     frame #1: 0x0000000186de66ef
> CoreAudio`AUHAL::GetAudioChannelLayout(unsigned int, unsigned int,
> AudioChannelLayout*, unsigned char&) + 57
From the public code on Apple Developer[0], GetAudioChannelLayout will be called when receiving `kAudioUnitProperty_AudioChannelLayout`, so I guess it crashed in [1].

Chrome had same issue in version 60(current version is 61)[2], but it's unclear if it's fixed now.


Hi :mjf,
Could you do me a favour? It would be better if we have the following information.
1. Check if it crashes on Chrome, under the same conditions.
2. Attach a log file for us. You could see the log on termianl by `$ MOZ_LOG=cubeb:5 /Applications/Firefox.app/Contents/MacOS/firefox-bin`. There is more detail in [3].

[0] https://developer.apple.com/library/content/samplecode/CoreAudioUtilityClasses/Listings/CoreAudio_AudioUnits_AUPublic_AUBase_AUBase_cpp.html
[1] http://searchfox.org/mozilla-central/rev/31606bbabc50b08895d843b9f5f3da938ccdfbbf/media/libcubeb/src/cubeb_audiounit.cpp#1138,1151
[2] https://productforums.google.com/forum/#!topic/chrome-de/_TKEmsKNFSk;context-place=topicsearchin/chrome-de/category$3Amac%7Csort:relevance%7Cspell:false
[3] https://developer.mozilla.org/en-US/docs/Mozilla/Debugging/HTTP_logging

Comment 9

[Michael Froman [:mjf]]

> 1. Check if it crashes on Chrome, under the same conditions.
Chrome doesn't seem to have an exact match for about:support, but I tried every single one of the pages listed under chrome::/about with no crash.

> 2. Attach a log file for us. You could see the log on termianl by `$
> MOZ_LOG=cubeb:5 /Applications/Firefox.app/Contents/MacOS/firefox-bin`. There
> is more detail in [3].
Attachment is on the way.

Comment 10

[Michael Froman [:mjf]]

Attachment: AudioCrashLog.txt shows crash going to about:support

This is a log for launching Nightly and immediately going to about:support.  There is no audio playing, but the 828mk3 is on.  If the 828mk3 is off, there is no crash.

Comment 11

[C.M.Chang[:chunmin]]

Hi :mjf,
Thanks a lot for your help! I was wondering if you could switch your default device from 828mk3 to others and open about:support again. If it doesn't crash(it shouldn't crash in this case), could you attach your screenshot for the media part in about:support? I need to get its information so I can push it into the blacklist. If it crashes again, please attach the crash stacks again. Thanks!!

Comment 12

[Michael Froman [:mjf]]

(In reply to Chun-Min Chang[:chunmin] from comment #11)
> Hi :mjf,
> Thanks a lot for your help! I was wondering if you could switch your default
> device from 828mk3 to others and open about:support again. If it doesn't
> crash(it shouldn't crash in this case), could you attach your screenshot for
> the media part in about:support? I need to get its information so I can push
> it into the blacklist. If it crashes again, please attach the crash stacks
> again. Thanks!!

What will putting it into the blacklist do?  We (Firefox) will still be able to play audio through the 828mk3, correct?

Comment 13

[Michael Froman [:mjf]]

Additional info while looking at this crash:
1. Switching input/output device to 828mk3 after launch allows about:support to work:
   a) Switch input/output device to built-in line-in and internal speakers
   b) Launch Nightly
   c) Switch input/output device to 828mk3
   d) Goto about:support
   e) It works
   f) Quit Nightly
   g) Relaunch Nightly
   h) Goto about:support
   i) Crash
2. If output device is not 828mk3, but input device is 828mk3 about:support works:
   a) Switch input device to 828mk3
   b) Switch output device to internal speakers
   c) Launch Nightly
   d) Goto about:support
   e) It works
3. If output device is 828mk3, but input device is not 828mk3 about:support crashes:
   a) Switch input device to Line-in
   b) Switch output device to 828mk3
   c) Launch Nightly
   d) Goto about:support
   e) Crash

Comment 14

[C.M.Chang[:chunmin]]

(In reply to Michael Froman [:mjf] from comment #12)
> What will putting it into the blacklist do?  We (Firefox) will still be able
> to play audio through the 828mk3, correct?
Hi :mjf
Thanks for your concern. The blacklist will only be used to block it to query the channel layout, so it won't crash the Firefox.

Comment 15

[C.M.Chang[:chunmin]]

(In reply to Michael Froman [:mjf] from comment #13)
> Additional info while looking at this crash:
Thanks for the detailed report. Could you also attach your screenshot for the media part in about:support so I could see the information from 828mk3?

Comment 16

[C.M.Chang[:chunmin]]

(In reply to Chun-Min Chang[:chunmin] from comment #15)
> (In reply to Michael Froman [:mjf] from comment #13)
> > Additional info while looking at this crash:
> Thanks for the detailed report. Could you also attach your screenshot for
> the media part in about:support so I could see the information from 828mk3?
Could you also help us to test whether 828mk3 could play audio/video? 

I guess it crashes when `audiounit_get_current_channel_layout` is called, but it's also be used when we configure our output stream[0]. If you can play audio/video, then the problem may be caused by other places[1].

[0] http://searchfox.org/mozilla-central/rev/a984558fa2bbde6492d3fb918496fc0b0835b2ce/media/libcubeb/src/cubeb_audiounit.cpp#1400
[1] http://searchfox.org/mozilla-central/rev/a984558fa2bbde6492d3fb918496fc0b0835b2ce/media/libcubeb/src/cubeb_audiounit.cpp#1197

Comment 17

[Michael Froman [:mjf]]

(In reply to Chun-Min Chang[:chunmin] from comment #16)
> I guess it crashes when `audiounit_get_current_channel_layout` is called,
> but it's also be used when we configure our output stream[0]. If you can
> play audio/video, then the problem may be caused by other places[1].
As noted in Comment #4 above, it plays audio (youtube, iTunes, etc) without any issues.  It is _only_ going about:support that causes an issue.

Comment 18

[C.M.Chang[:chunmin]]

(In reply to Michael Froman [:mjf] from comment #17)
> As noted in Comment #4 above, it plays audio (youtube, iTunes, etc) without
> any issues.  It is _only_ going about:support that causes an issue.
Thanks for the info. Could you please provide the screenshot of the media section in about:support by changing the default output device to other than 828mk3. I need this info to block it to get preferred channel layout. You can still play audio even I block it to get the layout.

Comment 19

[Michael Froman [:mjf]]

Attachment: About-support-with-828mk3.tiff

Here is the screen shot of the media section showing the 828mk3.  This shows scenario 2 in Comment #13.

Comment 20

[C.M.Chang[:chunmin]]

Attachment: Block MOTU 828mk3 to get preferred channel layout

The about:support page crashes when `AUHAL::GetAudioChannelLayout` is called with MOTU 828mk3s, so the crash must happen in `audiounit_get_preferred_channel_layout(2 arg)`[0]. There are two functions to get the layout. The first one is `audiounit_get_preferred_channel_layout(1 arg)`[1] and the second one is `audiounit_get_current_channel_layout`[2]. The `audiounit_get_current_channel_layout`[3] works well when MOTU 828mk3 plays audio(comment 17), so the crash is more likely to be in `audiounit_get_preferred_channel_layout(1 arg)`. Thus, I add a blacklist in `audiounit_get_preferred_channel_layout(1 arg)` to block MOTU 828mk3s to get the layout(It won't affect the audio playback).

Hi :mjf,
Please help me to check if this patch works for you. Could you apply this small patch and set MOTU 828mk3s to your default output device, then help me to check the follow things. I will need the cubeb log to figure out what's going on, so please enable logger by `$ MOZ_LOG=cubeb:5`.

1. Check if MOTU 828mk3s is blocked to get preferred channel layout[4] and whether about:support crashes
  1) $ MOZ_LOG=cubeb:5 ./mach run
  2) If everything works well, we should see `Current channel layout is XXXX` in the log[5].
  
  Example
  -----
  [Main Thread]: E/cubeb ../src/cubeb_audiounit.cpp:1178: The device: com_motu_driver_FWA_Engine:000009f200 is in the blacklist!
  [Main Thread]: E/cubeb ../src/cubeb_audiounit.cpp:1221: Preferred channel layout is undefined
  [Main Thread]: E/cubeb ../src/cubeb_audiounit.cpp:1243: Current channel layout is stereo
  [Main Thread]: E/cubeb ../src/cubeb.c:565: DeviceID: "SoundflowerEngine:1"
	 Name:	"Soundflower (64ch)"
	 Group:	"SoundflowerEngine:1"
	 Vendor:	"ma++ ingalls for Cycling '74"
	 Type:	output
	 State:	enabled
	 Maximum channels:	64
	 Format:	S16
  ......
  ......
  [Main Thread]: E/cubeb ../src/cubeb_audiounit.cpp:1243: Current channel layout is stereo

2. Check about:support works with active channel layout[6]
  1) $ MOZ_LOG=cubeb:5 ./mach run
  2) Disable e10s by setting browser.tabs.remote.autostart to false on about:config
  3) Restart nightly ($ MOZ_LOG=cubeb:5 ./mach run) and open any video to play
  4) Get the cubeb log like
  -----
  [Main Thread]: E/cubeb ../src/cubeb_audiounit.cpp:1178: The device: com_motu_driver_FWA_Engine:000009f200 is in the blacklist!
  [Main Thread]: E/cubeb ../src/cubeb_audiounit.cpp:1221: Preferred channel layout is undefined
  [Main Thread]: E/cubeb ../src/cubeb_audiounit.cpp:1243: Active channel layout is stereo
  ......
  ......


[0] http://searchfox.org/mozilla-central/rev/8a6a6bef7c54425970aa4fb039cc6463a19c0b7f/media/libcubeb/src/cubeb_audiounit.cpp#1197
[1] http://searchfox.org/mozilla-central/rev/8a6a6bef7c54425970aa4fb039cc6463a19c0b7f/media/libcubeb/src/cubeb_audiounit.cpp#1203
[2] http://searchfox.org/mozilla-central/rev/8a6a6bef7c54425970aa4fb039cc6463a19c0b7f/media/libcubeb/src/cubeb_audiounit.cpp#1223
[3] http://searchfox.org/mozilla-central/rev/8a6a6bef7c54425970aa4fb039cc6463a19c0b7f/media/libcubeb/src/cubeb_audiounit.cpp#1400
[4] https://github.com/ChunMinChang/gecko-dev/blob/bfa82a6e69d2a0571f65e8296f04866024c59d60/media/libcubeb/src/cubeb_audiounit.cpp#L1178
[5] https://github.com/ChunMinChang/gecko-dev/blob/bfa82a6e69d2a0571f65e8296f04866024c59d60/media/libcubeb/src/cubeb_audiounit.cpp#L1243
[6] https://github.com/ChunMinChang/gecko-dev/blob/bfa82a6e69d2a0571f65e8296f04866024c59d60/media/libcubeb/src/cubeb_audiounit.cpp#L1230

Comment 21

[Michael Froman [:mjf]]

(In reply to Chun-Min Chang[:chunmin] from comment #20)
> Created attachment 8921011 [details] [diff] [review]
> Block MOTU 828mk3 to get preferred channel layout
> 
> The about:support page crashes when `AUHAL::GetAudioChannelLayout` is called
> with MOTU 828mk3s, so the crash must happen in
> `audiounit_get_preferred_channel_layout(2 arg)`[0]. There are two functions
> to get the layout. The first one is
> `audiounit_get_preferred_channel_layout(1 arg)`[1] and the second one is
> `audiounit_get_current_channel_layout`[2]. The
> `audiounit_get_current_channel_layout`[3] works well when MOTU 828mk3 plays
> audio(comment 17), so the crash is more likely to be in
> `audiounit_get_preferred_channel_layout(1 arg)`. Thus, I add a blacklist in
> `audiounit_get_preferred_channel_layout(1 arg)` to block MOTU 828mk3s to get
> the layout(It won't affect the audio playback).
> 
> Hi :mjf,
> Please help me to check if this patch works for you. Could you apply this
> small patch and set MOTU 828mk3s to your default output device, then help me
> to check the follow things. I will need the cubeb log to figure out what's
> going on, so please enable logger by `$ MOZ_LOG=cubeb:5`.
> 
> 1. Check if MOTU 828mk3s is blocked to get preferred channel layout[4] and
> whether about:support crashes
>   1) $ MOZ_LOG=cubeb:5 ./mach run
>   2) If everything works well, we should see `Current channel layout is
> XXXX` in the log[5].

> 2. Check about:support works with active channel layout[6]
>   1) $ MOZ_LOG=cubeb:5 ./mach run
>   2) Disable e10s by setting browser.tabs.remote.autostart to false on
> about:config
>   3) Restart nightly ($ MOZ_LOG=cubeb:5 ./mach run) and open any video to
> play
>   4) Get the cubeb log like


Hello: I didn't get past step 1.  It still crashes with the 828mk3 as the default output device.  I will attach the log output for both the non-working case (828mk3 is default output) and the working case (828mk3 is non-default output).

Comment 22

[Michael Froman [:mjf]]

Attachment: 828-default-output-log.txt

This log file is with the 828mk3 set as the default output and crashes on about:support.

Comment 23

[Michael Froman [:mjf]]

Attachment: 828-non-default-output-log.txt

This is the log file for the 828mk3 on, but not set as default output device.  about:support works in this case.

Comment 24

[Michael Froman [:mjf]]

Both log files were generated with your patch from comment 20.

Comment 25

[Michael Froman [:mjf]]

I took some time to look at what was happening after adding your patch on my machine.  In either case, with or without your patch, we're crashing on the AudioUnitGetPropertyInfo call here:
https://dxr.mozilla.org/mozilla-central/rev/ce1a86d3b4db161c95d1147676bbed839d7a4732/media/libcubeb/src/cubeb_audiounit.cpp#1137

The reason your patch hasn't changed the crash behavior in either case we're returning CUBEB_LAYOUT_UNDEFINED from here:
https://dxr.mozilla.org/mozilla-central/rev/ce1a86d3b4db161c95d1147676bbed839d7a4732/media/libcubeb/src/cubeb_audiounit.cpp#1203

Your patch causes CUBEB_LAYOUT_UNDEFINED to come from audiounit_get_preferred_channel_layout.
Without your patch, CUBEB_LAYOUT_UNDEFINED is returned from cubeb_channel_map_to_layout here:
https://dxr.mozilla.org/mozilla-central/rev/ce1a86d3b4db161c95d1147676bbed839d7a4732/media/libcubeb/src/cubeb_mixer.cpp#36

Comment 26

[C.M.Chang[:chunmin]]

(In reply to Michael Froman [:mjf] from comment #25)
> I took some time to look at what was happening after adding your patch on my
> machine.  In either case, with or without your patch, we're crashing on the
> AudioUnitGetPropertyInfo call here:
> https://dxr.mozilla.org/mozilla-central/rev/
> ce1a86d3b4db161c95d1147676bbed839d7a4732/media/libcubeb/src/cubeb_audiounit.
> cpp#1137
828mk3 is really expensive so I cannot get it for now, thanks for your help!

This function is also called when playing video/audio here[0], but the weird thing is that you can play video without any issue, when you set 828mk3 to the default output device. Can you also attach the log in this scenario with the patch applied? I want to see what the 828mk3's channel layout[1] is when the video is played successfully.

Thanks a lot!!!

[0] https://dxr.mozilla.org/mozilla-central/rev/ce1a86d3b4db161c95d1147676bbed839d7a4732/media/libcubeb/src/cubeb_audiounit.cpp#1400
[1] https://github.com/ChunMinChang/cubeb/blob/018790a8126597972dc96f98da2db1e8fdfe1dce/src/cubeb_audiounit.cpp#L1420

Comment 27

[Michael Froman [:mjf]]

Attachment: 828-default-output-playing-video.txt

This is the log for playing a video (from SoundCloud) with the 828 selected as default output.

Comment 28

[Michael Froman [:mjf]]

The code in audiounit_layout_init[0] is interesting.  It uses stm->output_stream_params to output channel layout to stereo (roughly correct since only 2 of the 14 output channels are mapped), but it then queries the current channel layout, and sets the value in stm->context->layout.  This actually ends up CUBEB_LAYOUT_UNDEFINED because of cubeb_channel_map_to_layout bailing out here on the first unmapped channel here[1].  Interestingly, this doesn't keep the audio from working.

[0] https://dxr.mozilla.org/mozilla-central/rev/a124f4901430f6db74cfc7fe3b07957a1c691b40/media/libcubeb/src/cubeb_audiounit.cpp#1385-1401
[1] https://dxr.mozilla.org/mozilla-central/rev/a124f4901430f6db74cfc7fe3b07957a1c691b40/media/libcubeb/src/cubeb_mixer.cpp#36

Comment 29

[C.M.Chang[:chunmin]]

(In reply to Michael Froman [:mjf] from comment #28)
> The code in audiounit_layout_init[0] is interesting.  It uses
> stm->output_stream_params to output channel layout to stereo (roughly
> correct since only 2 of the 14 output channels are mapped), but it then
> queries the current channel layout, and sets the value in
> stm->context->layout.  This actually ends up CUBEB_LAYOUT_UNDEFINED because
> of cubeb_channel_map_to_layout bailing out here on the first unmapped
> channel here[1].  Interestingly, this doesn't keep the audio from working.
Even the layout is undefined, it can still play. The layout only affect how we mix audio when the input source is different from the current setting(e.g. Dowmix audio 5.1 to stereo).

(In reply to Michael Froman [:mjf] from comment #25)
> The reason your patch hasn't changed the crash behavior in either case we're
> returning CUBEB_LAYOUT_UNDEFINED from here:
> https://dxr.mozilla.org/mozilla-central/rev/
> ce1a86d3b4db161c95d1147676bbed839d7a4732/media/libcubeb/src/cubeb_audiounit.
> cpp#1203
> 
> Your patch causes CUBEB_LAYOUT_UNDEFINED to come from
> audiounit_get_preferred_channel_layout.
> Without your patch, CUBEB_LAYOUT_UNDEFINED is returned from
> cubeb_channel_map_to_layout here:
> https://dxr.mozilla.org/mozilla-central/rev/
> ce1a86d3b4db161c95d1147676bbed839d7a4732/media/libcubeb/src/cubeb_mixer.
> cpp#36
So I don't think CUBEB_LAYOUT_UNDEFINED will cause any problem when playing video or get the preferred layout. If the preferred channel returns CUBEB_LAYOUT_UNDEFINED, then it will shows "undefined" on about:support.

(In reply to Michael Froman [:mjf] from comment #25)
> I took some time to look at what was happening after adding your patch on my
> machine.  In either case, with or without your patch, we're crashing on the
> AudioUnitGetPropertyInfo call here:
> https://dxr.mozilla.org/mozilla-central/rev/
> ce1a86d3b4db161c95d1147676bbed839d7a4732/media/libcubeb/src/cubeb_audiounit.
> cpp#1137
The crash is at https://dxr.mozilla.org/mozilla-central/rev/ce1a86d3b4db161c95d1147676bbed839d7a4732/media/libcubeb/src/cubeb_audiounit.cpp#1137
but the weird thing is that it doesn't crash when you're playing video. It can pass the crash at `AudioUnitGetPropertyInfo` above then run to `audiounit_convert_channel_layout`, then to cubeb_channel_map_to_layout[0].

I guess the difference is that we call `audiounit_set_channel_layout` before calling `audiounit_get_current_channel_layout`. In this case, I'll block this soundcard to query `audiounit_get_current_channel_layout`[1] if `audiounit_get_preferred_channel_layout()` returns CUBEB_LAYOUT_UNDEFINED and there is no active `ctx->layout`.

[0] https://dxr.mozilla.org/mozilla-central/rev/a97fb1c39d51a7337b46957bde4273bd308b796a/media/libcubeb/src/cubeb_audiounit.cpp#1129
[1] https://dxr.mozilla.org/mozilla-central/rev/ce1a86d3b4db161c95d1147676bbed839d7a4732/media/libcubeb/src/cubeb_audiounit.cpp#1223

Comment 30

[Michael Froman [:mjf]]

(In reply to Chun-Min Chang[:chunmin] from comment #29)
> I guess the difference is that we call `audiounit_set_channel_layout` before
> calling `audiounit_get_current_channel_layout`. In this case, I'll block
> this soundcard to query `audiounit_get_current_channel_layout`[1] if
> `audiounit_get_preferred_channel_layout()` returns CUBEB_LAYOUT_UNDEFINED
> and there is no active `ctx->layout`.
For the record, I tried adding that call, and it didn't help.

I also tried cobbling together a full cubeb_stream_init before the call to audiounit_get_current_channel_layout in audiounit_get_preferred_channel_layout.  That didn't fix the crash either.  It is like there is something happening much higher up in the media code when playing video that isn't happening from the about:support to initialize something.

As a sanity check I also connected a different audio interface (Line6 Helix, which happens to be a guitar processor that will also act as audio interface) via USB and it works on about:support just fine.  The 828mk3 is connected via firewire, which is slightly different I suppose, but still doesn't explain why the same call works when trying to play audio and doesn't work on the about:support case.

Comment 31

[C.M.Chang[:chunmin]]

Michael,

The code is changed. Does this still happen?

Comment 32

[Michael Froman [:mjf]]

I no longer get a crash going to about:support when the 828mk3 is on. Thank you!

Comment 33

[C.M.Chang[:chunmin]]

(In reply to Michael Froman [:mjf] from comment #32)

I no longer get a crash going to about:support when the 828mk3 is on. Thank you!

I am going to close this bug since it's fixed.