Media/WebAudio: Difference between revisions

116 bytes removed ,  23 September 2015
update summary
(quick update to bug status -- bigger changes to contents coming soon)
(update summary)
 
Line 1: Line 1:




'''Web Audio Perf meta bug:''' https://bugzilla.mozilla.org/show_bug.cgi?id=webaudioperf <br/>
'''Web Audio Perf Parity meta bug:''' https://bugzilla.mozilla.org/show_bug.cgi?id=webaudioperf_parity <br/>
'''All open Web Audio bugs:''' http://mzl.la/1HQZkmU <br/>
'''All open Web Audio bugs:''' http://mzl.la/1HQZkmU <br/>
'''NOTE:''' If a bug doesn't have a priority (P1 to P5), we are not planning to fix it by the end of Q3.  If anyone thinks it needs to be fixed, please ping padenot and/or mreavy.<br/>
'''NOTE:''' If a bug doesn't have a priority (P1 to P5), we are not planning to fix it by the end of Q3.  If anyone thinks it needs to be fixed, please ping padenot and/or mreavy.<br/>
'''WebRTC and Web Audio plans coming out of Whistler:'''  https://docs.google.com/document/d/1eJLEenV4T5R5uiattNXU4PIy9w7hUvysj3lvkZPJVIM/edit#heading=h.hit4o9naa62o  -- This wiki will be updated to reflect the new info in this doc
'''WebRTC and Web Audio plans coming out of Whistler:'''  https://docs.google.com/document/d/1eJLEenV4T5R5uiattNXU4PIy9w7hUvysj3lvkZPJVIM/edit#heading=h.hit4o9naa62o  -- This wiki will be updated to reflect the new info in this doc
----------------------
== Web Audio API performance improvement, phase 2 (Q3) ==
* Firefox 44 is our target release for "improved web audio performance" (as good or better than our competition)
** Web Audio perf parity bug, everything higher than Rank=14, is the target: {{Bug|1189514}}
** Benchmarks: http://ouija.allizom.org/grafana/index.html#/dashboard/file/webaudio.json 
*** (Mac and Android benchmarks are having trouble running in automation.  Investigating why with dminor.)
----------------------
----------------------
== Web Audio API performance improvement, phase 1 (Q2) ==
== Web Audio API performance improvement, phase 1 (Q2) ==
Line 30: Line 38:
Some comments about the expected difficulty and whether it's blocked is at the end of each point in [brackets].
Some comments about the expected difficulty and whether it's blocked is at the end of each point in [brackets].


*  Web Audio API suspend/resume
** Gaia is hacking around the lack of this API for now, but we need it, there has been around 3-4 high-profile battery consumption regression because of that.<br />
** The spec is now finished, so we are good to implement.
** [Landed in Fx 40]
* Possible audio output device switch fixes for Windows
** We need to add some code to handle audio output device switching in windows/WASAPI. This is driver/windows version dependent, so some testing is needed beforehand.
** [Landed in Fx 38]
* Web Audio API Audio Worker
* Web Audio API Audio Worker
** This is _very_ important to implement quickly and right when the spec is done.
** This is _very_ important to implement quickly and right when the spec is done.
Line 80: Line 81:
** We have an issue where on some platforms, the latency is too high (more than 1000/60ms between callbacks), and we are not able to paint the all the frame  when they are due (we seem to have hacked around it for now). iirc roc has ideas on how to do that. It should also reduce the video latency.
** We have an issue where on some platforms, the latency is too high (more than 1000/60ms between callbacks), and we are not able to paint the all the frame  when they are due (we seem to have hacked around it for now). iirc roc has ideas on how to do that. It should also reduce the video latency.
** [no idea of difficulty yet -- thoughts welcome]
** [no idea of difficulty yet -- thoughts welcome]
* MSG optimizations
** When randomly profiling Firefox during WebRTC calls/gUM applications/Web Audio API applications, I see that the MSG is using too much CPU compared to what it should use. Since the MSG is pretty central to our overall real-time media story, it should logically be something that we optimize. For example, I think that investing around week in optimizing the MSG would be as interesting in CPU usage wins as adding support for an hardware AEC. I have notes somewhere on things we could do (somewhat low-hanging fruits), and the CPU usage gain (of course during a specific scenario, since different scenarios stress the MSG code in different ways).<br />
** [not too hard]
* Sandbox hardening
* Sandbox hardening
** Audio input and output stream are somewhat syscall heavy, and do scary things with buffers all the time. Depending on the technique the security people are going to use/are using, we might need to change some code on our side. Because we have non-traditional requirements on latency, the classic solutions (&quot;just use ipdl&quot;) might not work.  
** Audio input and output stream are somewhat syscall heavy, and do scary things with buffers all the time. Depending on the technique the security people are going to use/are using, we might need to change some code on our side. Because we have non-traditional requirements on latency, the classic solutions (&quot;just use ipdl&quot;) might not work.  
** We should look into mutexes and other synchronization primitives
** We should look into mutexes and other synchronization primitives
** The page we used as a reference, but not sure if it's up to date: &lt;[[Sandbox]]&gt;
** The page we used as a reference, but not sure if it's up to date: &lt;[[Sandbox]]&gt;
* MSG optimizations
** Remove blocking from MSG
** [Landed in Fx 43].<br />
*  Web Audio API suspend/resume
** Gaia is hacking around the lack of this API for now, but we need it, there has been around 3-4 high-profile battery consumption regression because of that.<br />
** The spec is now finished, so we are good to implement.
** [Landed in Fx 40]
* Possible audio output device switch fixes for Windows
** We need to add some code to handle audio output device switching in windows/WASAPI. This is driver/windows version dependent, so some testing is needed beforehand.
** [Landed in Fx 38]
Confirmed users
654

edits