Changesets: 0e10388 audiounit: create aggregate device only on different devices 9e96784 audiounit: don't unnecessarily set drift compensation on device acting as master clock. 9ccde3b wasapi: Handle GetMixFormat returning non-WAVEFORMATEXTENSIBLE pointers. (#343) 16f9ccc Fix build on FreeBSD (#344) 2e68530 mixer: Fix typo in output_buffer_length.
Created attachment 8893230 [details] [diff] [review] bug1386957.patch Already reviewed upstream, so really just needs a rubber stamp. Alex, please link the bugs (if any) for the two AudioUnit changes.
Attachment #8893230 - Flags: review?(achronop)
Attachment #8893230 - Flags: review?(achronop) → review+
No bugs for AudioUnit changes.
Pushed by email@example.com: https://hg.mozilla.org/integration/mozilla-inbound/rev/6bf5e9b6be4c Update libcubeb to revision 0e103884. r=achronop
Status: ASSIGNED → RESOLVED
Last Resolved: a year ago
status-firefox57: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla57
Please nominate this for Beta approval when you get a chance.
status-firefox56: --- → affected
Yeah, we want to uplift 9ccde3b at least. Alex, do you want your AudioUnit changes uplifted or should they ride the trains?
No, it's not necessary to uplift my bit. Thanks.
Created attachment 8894705 [details] [diff] [review] bug1386957_beta.patch Approval Request Comment [Feature/Bug causing the regression]: bug 1357683 (specifically https://github.com/kinetiknz/cubeb/commit/2bb3e25537042ad113f02f36bd1080dc8abeb3b4) [User impact if declined]: [Is this code covered by automated tests?]: partially (not exercised due to hardware on the test machines) [Has the fix been verified in Nightly?]: yes [Needs manual test from QE? If yes, steps to reproduce]: test audio/media playback and WebRTC calls on 32 and 64 bit Windows builds with Duet PCS speaker/mic combo device [List of other uplifts needed for the feature/fix]: none [Is the change risky?]: no [Why is the change risky/not risky?]: simple fix once the cause of the bug was understood [String changes made/needed]: none
Hi Brindusa, could you help find someone to test as suggested in comment #8 on the latest Nightly build?
What exactly am I looking for here for a verification?
(In reply to Justin [:JW_SoftvisionQA] from comment #10) > What exactly am I looking for here for a verification? Normal audio playback with no crash. For background, the uplift is fixing bug 1362764 and bug 1380775. With the Duet PCS (http://www.phnxaudio.com/duet/mt202-pcs/) set as the output device in Windows 10, I was able to reproduce bug 1362764 by just playing a random YouTube video in a 64-bit Windows build and seeking a few times while playing. Bug 1380775 I could repro in both 32 bit and 64 bit builds by joining a call on appear.in. Note that the bug is specific to certain sound hardware that seem to trigger a legacy codepath in Windows' audio stack, of which the Duet PCS is one. I don't know how to identify which other devices trigger that codepath without inspecting their behaviour in a debugger, so that's the only device I can confirm the bug is triggered by.
Comment on attachment 8894705 [details] [diff] [review] bug1386957_beta.patch Let's uplift this for beta 6. Looks like it will fix some crashes and other issues with user impact. Justin, can you verify this with a beta build once the changes land on mozilla-beta? Thanks.
Attachment #8894705 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
status-firefox56: affected → fixed
Normal audio playback was verified at beta validation testing, on latest beta 56.0b7-build2, but we don't have the Duet PCS device, so cannot confirm the fix with this device.
I can confirm for 56.0b6 (64-Bit) that I don't get crashes anymore when my Jabra Pro 9450 device is selected. This apparently was the same issue as with the Duet PCS.
You need to log in before you can comment on or make changes to this bug.