Closed Bug 999350 Opened 6 years ago Closed 6 years ago
Channel] System app will receive "none" not one of audio channel types when playing audio in first time .
When an app tries to play audio with normal type, the system app may get two possible results from mozChromeEvent - "audio-channel-changed". A. Receive "none" first then "normal". B. Directly receive "normal". The result A will be happened when playing first audio after system boot up. After that, only result B will be received. This will effect audio channel related testcases because we don't this test case will run on result A or B. So we need to fix it.
The root cause is that a. initial values of AudioChannelService::mCurrentHigherChannel and mCurrentVisibleHigherChannel are INT32_MAX. b. the value indicates no audio channels there is -1. c. so the first current value will be different then -1 then "none" is fired. The patch contains a. To change initial values of AudioChannelService::mCurrentHigherChannel and mCurrentVisibleHigherChannel to -1 not INT32_MAX. b. Add test case for mozChromeEvent - audio-channel-change/visible-audio-channel-change. And the rough idea is b1. Use SystemProxy.jsm to relay mozChromeEvent from parent to child process. (because mochitest run on emulator is on child process). b2. file_audio.html is another OOP process which is responsible for playing each types then stopping them one by one. b3. test_audioChannelChange.html tried to launch file_audio.html and control it's visible status so we can verify audio playing in the foreground or background or both.
Assignee: nobody → mchen
Attachment #8410141 - Flags: review?(amarchesini)
Attachment #8410141 - Flags: review?(amarchesini) → review+
Carry reviewer name.
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → 2.0 S1 (9may)
You need to log in before you can comment on or make changes to this bug.