Closed Bug 779297 (webaudio) Opened 12 years ago Closed 11 years ago

Implement and ship Web Audio

Categories

(Core :: Web Audio, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla25
Tracking Status
relnote-firefox --- 25+

People

(Reporter: roc, Assigned: ehsan.akhgari)

References

(Depends on 1 open bug, Blocks 1 open bug, )

Details

(Keywords: feature, meta, Whiteboard: [games:p1][tech-p1])

Alias: webaudio
I have created a MozillaWiki article for the W3C Web Audio API: https://wiki.mozilla.org/Web_Audio_API
Depends on: 788310
Whiteboard: [games:p?]
Whiteboard: [games:p?] → [games:p1]
All the child bugs here are fixed. What's the status of this API implementation?
OS: Windows 7 → All
Hardware: x86_64 → All
(In reply to comment #2)
> All the child bugs here are fixed. What's the status of this API
> implementation?

It's long ways away.  Not all of the actual portions have been filed now.  I've been mostly filing bugs for things that I have in-flight patches for.
Depends on: 792263
Depends on: 792646
Depends on: 792649
Depends on: 797150
Depends on: 802192
Depends on: 803392
Depends on: 804387
Depends on: 807171
Depends on: 807526
Depends on: 807533
Depends on: 808374
Depends on: 808841
Depends on: 808876
Depends on: 809271
Depends on: 809654
Keywords: meta
Depends on: 809882
Depends on: 811369
Just wondering... but when will this be avaliable for Firefox users?
Depends on: 811555
(In reply to Jessica_XY from comment #4)
> Just wondering... but when will this be avaliable for Firefox users?

There's no particular target set at this point. Sometime next year, probably.
(In reply to comment #4)
> Just wondering... but when will this be avaliable for Firefox users?

We're working on it, it's still not clear which version will enable this by default.
Depends on: 811864
Depends on: 812390
Depends on: 812617
Depends on: 813269
Depends on: 814789
Depends on: 815492
Depends on: 815643
Depends on: 816828
Depends on: 822803
Depends on: 827541
Depends on: 833631
Depends on: 834513
Depends on: 834869
Depends on: 834929
Depends on: 836072
Depends on: 836076
Depends on: 836599
Depends on: 837684
Major content use case and needed for competitive parity.
Whiteboard: [games:p1] → [games:p1][tech-p1]
(In reply to comment #8)
> Major content use case and needed for competitive parity.

Do we have a detailed set of requirements for b2g?  Web Audio is a huge API and we're currently working to determine the list of nodes we're going to implement first.  The proposed list is currently available at <https://etherpad.mozilla.org/webaudio> and it would be great if b2g folks could give us feedback on the prioritization proposed there.  Thanks!
Depends on: 845960
The two use cases I know are very simple.  I'm not an expert on this, so I'm going to wave my hands
 - multi-shot API for playing back sounds (bug 674080).  I don't know how this overlaps with WebAudio, or what nodes that would correspond to.

 - generating infinite sine-wave tones, mixing two tones into one channel, and applying ADSR.  This is used to generate key-pad tones.

Beyond that, b2g is shooting for parity with android audio processing APIs, so that's the next place I would look.
In b2g, Music and Videp apps can use WebAudio. The apps can play music with audio effect.
(In reply to comment #10)
> The two use cases I know are very simple.  I'm not an expert on this, so I'm
> going to wave my hands
>  - multi-shot API for playing back sounds (bug 674080).  I don't know how this
> overlaps with WebAudio, or what nodes that would correspond to.

In Web Audio you can decode the audio in a buffer and play it as many times as you like.

>  - generating infinite sine-wave tones, mixing two tones into one channel, and
> applying ADSR.  This is used to generate key-pad tones.

Web Audio lets you do that but I think doing that in software for the key-pad tones is a mistake.  We can just record the audio and play it back from a file.

> Beyond that, b2g is shooting for parity with android audio processing APIs, so
> that's the next place I would look.

Which APIs are those exactly?  I'm not familiar with Android audio APIs at all.
(In reply to comment #11)
> In b2g, Music and Videp apps can use WebAudio. The apps can play music with
> audio effect.

What types of effects?
(In reply to :Ehsan Akhgari from comment #12)
> >  - generating infinite sine-wave tones, mixing two tones into one channel, and
> > applying ADSR.  This is used to generate key-pad tones.
> 
> Web Audio lets you do that but I think doing that in software for the
> key-pad tones is a mistake.  We can just record the audio and play it back
> from a file.

If this is for user feedback, you shouldn't use real DTMF tones in the first place. In e.g., WebRTC, the real DTMF data is conveyed in RFC 4733 RTP packets and any tones that are played are just candidates for double-detection and other confusion on the receiving end. So you could even use the same file for every key.
Depends on: 846329
Yes, the tones are audio played for user feedback, not what's sent over the wire.  I'll have to let the authors of the current code speak to the issues they ran into.
Depends on: 847481
Depends on: 848651
Depends on: 848652
Depends on: 848953
Depends on: 848954
No longer depends on: 848953
Depends on: 849230
Depends on: 849636
Depends on: 849652
Depends on: 849713
Depends on: 849914
Depends on: 849916
Depends on: 849918
Depends on: 850970
Depends on: 851338
Depends on: 851412
Depends on: 851603
I was trying this code snippet with FF Nightly https://gist.github.com/automata/5174277 but I'm getting an error about the number of arguments for mozAudioContext.createBuffer.

Beside this, is anyone working on testing currently Web Audio API spec with the one implemented on FF? Any plans on how to do that? I want to help.

Thanks guys.
Depends on: 851949
(In reply to Vilson Vieira from comment #16)
> I was trying this code snippet with FF Nightly
> https://gist.github.com/automata/5174277 but I'm getting an error about the
> number of arguments for mozAudioContext.createBuffer.

There are two versions of createBuffer, one which just creates a buffer and one that decodes audio on the main thread.  You're trying to use the second version which we have not implemented yet.  Bug 848652 is on file for that. In the mean time, you can rework your sample to use the asynchronous version of this API, decodeAudioData which we implement and is better since it won't block the main thread any way.

> Beside this, is anyone working on testing currently Web Audio API spec with
> the one implemented on FF? Any plans on how to do that? I want to help.

I am actively involved in the spec discussions.  What kinds of things are you interested to help with?  I'm sure we could use more hands here.  :-)
Depends on: 851966
Depends on: 851986
Depends on: 852011
(In reply to :Ehsan Akhgari (needinfo? me!) from comment #17) 
> There are two versions of createBuffer, one which just creates a buffer and
> one that decodes audio on the main thread.  You're trying to use the second
> version which we have not implemented yet.  Bug 848652 is on file for that.

Ehsan, thank you, I'll try decodeAudioData instead.

> I am actively involved in the spec discussions.  What kinds of things are
> you interested to help with?  I'm sure we could use more hands here.  :-)

I can help testing the Web Audio API implementation (I don't know what is the best way to do that, maybe trying available examples like http://chromium.googlecode.com/svn/trunk/samples/audio/index.html and reporting the status?) and try to help on dev as much as I can. Well, use my hands :-)
(In reply to comment #18)
> > I am actively involved in the spec discussions.  What kinds of things are
> > you interested to help with?  I'm sure we could use more hands here.  :-)
> 
> I can help testing the Web Audio API implementation (I don't know what is the
> best way to do that, maybe trying available examples like
> http://chromium.googlecode.com/svn/trunk/samples/audio/index.html and reporting
> the status?) and try to help on dev as much as I can. Well, use my hands :-)

Testing the existing Web IDL implementation will be a _huge_ help!  Note that at this stage there are large parts of the Web Audio APIs that we don't implement yet.  Unfortunately the best way to tell what has been implemented so far is to look in <http://mxr.mozilla.org/mozilla-central/source/dom/webidl/> for files named like [interfaceName].webIDL (for example, <http://mxr.mozilla.org/mozilla-central/source/dom/webidl/AudioContext.webidl>) and look at the properties and methods on those interfaces.  Reporting issues caused by things which we are not implementing yet is generally not very helpful since we're already well aware of those, but reporting issues with the things that we currently implement is extremely helpful (bug 846329 is my favorite example so far!)

As far as different node types, we have the DOM bindings implemented for a whole bunch of them, but most are not hooked up to anything yet.  The node types that are currently implemented and should work fine are AudioBufferSourceNode, AudioDestinationNode and AudioGainNode.  More is coming along shortly, of course, so please continue watching this bug.  :-)

If you're interested in hacking on the implementation itself and have experience writing C++ code, please let me know and I would be happy to help you find a good place to start!  And please ask questions if anything is not clear to you.  Thanks!
Depends on: 852366
Depends on: 852410
(In reply to :Ehsan Akhgari (needinfo? me!) from comment #19)
> (In reply to comment #18)
> > > I am actively involved in the spec discussions.  What kinds of things are
> > > you interested to help with?  I'm sure we could use more hands here.  :-)
> > 
> > I can help testing the Web Audio API implementation (I don't know what is the
> > best way to do that, maybe trying available examples like
> > http://chromium.googlecode.com/svn/trunk/samples/audio/index.html and reporting
> > the status?) and try to help on dev as much as I can. Well, use my hands :-)
> 
> Testing the existing Web IDL implementation will be a _huge_ help!  Note
> that at this stage there are large parts of the Web Audio APIs that we don't
> implement yet.  Unfortunately the best way to tell what has been implemented
> so far is to look in
> <http://mxr.mozilla.org/mozilla-central/source/dom/webidl/> for files named
> like [interfaceName].webIDL (for example,

Are there no mochitests for these APIs? I looked in dom/tests/mochitest/ and could not find anything related to audio.
(In reply to David Dahl :ddahl from comment #20)
> Are there no mochitests for these APIs? I looked in dom/tests/mochitest/ and
> could not find anything related to audio.

content/media/webaudio/test/
(In reply to comment #20)
> > Testing the existing Web IDL implementation will be a _huge_ help!  Note
> > that at this stage there are large parts of the Web Audio APIs that we don't
> > implement yet.  Unfortunately the best way to tell what has been implemented
> > so far is to look in
> > <http://mxr.mozilla.org/mozilla-central/source/dom/webidl/> for files named
> > like [interfaceName].webIDL (for example,
> 
> Are there no mochitests for these APIs? I looked in dom/tests/mochitest/ and
> could not find anything related to audio.

There are some tests in content/media/webaudio/tests, but we don't have an implementation for ScriptPrpcessoprNode yet, which means that we can't write any interesting tests for now (tests that actually see what the audio graph is outputting.)  I plan on working on ScriptProcessorNode very soon.
Depends on: 853076
(In reply to :Ehsan Akhgari (needinfo? me!) from comment #19)
> Testing the existing Web IDL implementation will be a _huge_ help!  ...

Ehsan, I am starting to test the IDL implementations. My initial attempt is at https://github.com/automata/webaudio-tests

Currently I am getting: TypeError: context.decodeAudioData is not a function. But looking at AudioContext.webidl, decodeAudioData was implemented. Any suggestions?

BTW maybe this discussion could be more appropriate by IRC/email, so just tell me. I am automata at #media or I can mail you.

> If you're interested in hacking on the implementation itself and have
> experience writing C++ code, please let me know and I would be happy to help
> you find a good place to start!  And please ask questions if anything is not
> clear to you.  Thanks!

I don't have enough experience writing C++ but I can give a try! Thank you!
Depends on: 853246
Depends on: 852817
Depends on: 852838
Depends on: 853298
I could get context.decodeAudioData to work with ogg files, while it fails to decode wav audio.

(In reply to Vilson Vieira from comment #23)
> (In reply to :Ehsan Akhgari (needinfo? me!) from comment #19)
> > Testing the existing Web IDL implementation will be a _huge_ help!  ...
> 
> Ehsan, I am starting to test the IDL implementations. My initial attempt is
> at https://github.com/automata/webaudio-tests
> 
> Currently I am getting: TypeError: context.decodeAudioData is not a
> function. But looking at AudioContext.webidl, decodeAudioData was
> implemented. Any suggestions?
> 
> BTW maybe this discussion could be more appropriate by IRC/email, so just
> tell me. I am automata at #media or I can mail you.
> 
> > If you're interested in hacking on the implementation itself and have
> > experience writing C++ code, please let me know and I would be happy to help
> > you find a good place to start!  And please ask questions if anything is not
> > clear to you.  Thanks!
> 
> I don't have enough experience writing C++ but I can give a try! Thank you!
boblemarin, if you can give us a testcase (i.e. a page where you can observe the failure to use decodeAudioData on a .wav file), we could fix it faster, I think.
Flags: needinfo?(emeric)
Ooops. My bad, OGG and WAV decoding are working perfectly.
(test case here : http://minimal.be/mozilla/decode/ )
Flags: needinfo?(emeric)
Remember to use FirefoxNightly for your tests. The Live channel features a mozAudioContext object that is not functional, but the Nightly channel uses the unprefixed version which has the decodeAudioData method working.
(See my example here: http://minimal.be/mozilla/decode/ )

(In reply to Vilson Vieira from comment #23)
> (In reply to :Ehsan Akhgari (needinfo? me!) from comment #19)
> > Testing the existing Web IDL implementation will be a _huge_ help!  ...
> 
> Ehsan, I am starting to test the IDL implementations. My initial attempt is
> at https://github.com/automata/webaudio-tests
> 
> Currently I am getting: TypeError: context.decodeAudioData is not a
> function. But looking at AudioContext.webidl, decodeAudioData was
> implemented. Any suggestions?
> 
> BTW maybe this discussion could be more appropriate by IRC/email, so just
> tell me. I am automata at #media or I can mail you.
> 
> > If you're interested in hacking on the implementation itself and have
> > experience writing C++ code, please let me know and I would be happy to help
> > you find a good place to start!  And please ask questions if anything is not
> > clear to you.  Thanks!
> 
> I don't have enough experience writing C++ but I can give a try! Thank you!
Depends on: 853360
Depends on: 853551
Depends on: 853718
Depends on: 853721
(In reply to boblemarin from comment #26)
> Ooops. My bad, OGG and WAV decoding are working perfectly.
> (test case here : http://minimal.be/mozilla/decode/ )

This causes https://crash-stats.mozilla.com/report/pending/cfed53a0-f354-438e-8788-00b2c2130322 for me after a few presses of the ‘play ogg’ or ‘play wav’
(In reply to John Drinkwater (:beta) from comment #28)
> (In reply to boblemarin from comment #26)
> > Ooops. My bad, OGG and WAV decoding are working perfectly.
> > (test case here : http://minimal.be/mozilla/decode/ )
> 
> This causes
> https://crash-stats.mozilla.com/report/pending/cfed53a0-f354-438e-8788-
> 00b2c2130322 for me after a few presses of the ‘play ogg’ or ‘play wav’

Filed Bug 853434 yesterday already about that one.
(In reply to XtC4UaLL [:xtc4uall] from comment #29)
> Filed Bug 853434 yesterday already about that one.

ta
Depends on: 853434
Depends on: 853963
Depends on: 854336
Depends on: 854741
Depends on: 855568
Depends on: 856327
Depends on: 856328
Depends on: 856329
Depends on: 855990
Depends on: 856361
Depends on: 856771
Depends on: 857302
Depends on: 857610
Depends on: 857790
Depends on: 857793
Depends on: 859335
Flags: sec-review?
Depends on: 859594
Depends on: 859595
Depends on: 859597
Depends on: 859600
Depends on: 859602
Depends on: 854319
needs fuzzing
Flags: sec-review? → sec-review?(cdiehl)
(In reply to comment #31)
> needs fuzzing

Jesse has been doing some of that.  Will definitely need more!
Depends on: 861021
Depends on: 861371
Depends on: 861591
Depends on: 861187
Depends on: 862177
Depends on: 863923
Depends on: 863918
Depends on: 864083
Depends on: 864086
Depends on: 864091
Depends on: 864164
Depends on: 864171
Depends on: 864351
Depends on: 864605
Depends on: 864606
Depends on: 864609
Depends on: 864613
Depends on: 864780
Depends on: 864937
Depends on: 865231
Depends on: 865233
Depends on: 865234
Depends on: 865239
Depends on: 865241
Depends on: 865242
Depends on: 865244
Depends on: 865246
Depends on: 865247
Depends on: 865248
Depends on: 865251
Depends on: oscillatornode
Depends on: 865256
Depends on: 865257
Depends on: 865261
Depends on: 864709
Depends on: 865004
Depends on: 865413
Depends on: 865532
Depends on: 865548
Depends on: 865550
Depends on: 865553
Depends on: 865650
Depends on: 865642
Depends on: 862088
Depends on: 866079
Depends on: 866108
Depends on: 866141
Depends on: 866433
Depends on: 866434
Depends on: 866442
Depends on: 866570
Depends on: 866737
Depends on: 866839
Depends on: 867089
Depends on: 867174
Depends on: 867324
Depends on: 867203
Depends on: 867086
Depends on: 867104
Depends on: 867511
Depends on: 867588
It would be great if we could relnote this on Aurora once 23 gets there.
relnote-firefox: --- → ?
Depends on: 867876
Depends on: 868116
Depends on: 868305
Depends on: 868409
Depends on: 868485
Depends on: 868504
Depends on: 868776
Depends on: 868855
Depends on: 868864
Depends on: 869073
No longer depends on: 869073
Depends on: 869224
Depends on: 869257
Depends on: 869682
Depends on: 869684
Depends on: 870065
(In reply to :Ehsan Akhgari (needinfo? me!) from comment #33)
> It would be great if we could relnote this on Aurora once 23 gets there.

Is this coded to be disabled on Beta/Release? Or will the whole feature be ready and enabled in FF23 riding the trains.
Depends on: 870167
Depends on: 870174
(In reply to comment #34)
> (In reply to :Ehsan Akhgari (needinfo? me!) from comment #33)
> > It would be great if we could relnote this on Aurora once 23 gets there.
> 
> Is this coded to be disabled on Beta/Release? Or will the whole feature be
> ready and enabled in FF23 riding the trains.

It's not clear yet, we do have a vehicle for disabling it on Beta/Release if needed, and we'll obviously try to ship it as soon as we can.  But that's besides the point.  What I'm interested in is for this to come up in the list of new things for Aurora 23 so that we can get some developer attention to it.
Depends on: 871201
Depends on: 871577
Depends on: 872208
No longer depends on: 872208
Depends on: 872394
Depends on: 872635
Depends on: 873335
Depends on: 873553
Depends on: 874024
This has been noted in the Aurora 23 release notes:

http://www.mozilla.org/en-US/firefox/23.0a2/auroranotes/

If you would like to make any changes or have questions/concerns please contact me directly.
Depends on: 873858
Depends on: 874508
Depends on: 874540
Depends on: 874869
Depends on: 874915
Depends on: 874934
Depends on: 874952
Depends on: 875144
Depends on: 875152
Depends on: 875221
Depends on: 875277
Depends on: 875402
Depends on: 875529
Depends on: 875596
Depends on: 875617
Depends on: 875911
Depends on: 876118
Depends on: 876207
Depends on: 876215
Depends on: 876249
Depends on: 876273
Depends on: 876338
Depends on: 876252
Depends on: 876834
Depends on: 877039
Depends on: 877125
Depends on: 877231
Depends on: 877523
Depends on: 877527
Depends on: 877662
Depends on: 876024
Depends on: 877695
Depends on: 877820
Depends on: 878014
Depends on: 878015
Depends on: 878328
Depends on: 878407
Depends on: 878478
Depends on: 878497
Depends on: 878875
Depends on: 879014
Component: Video/Audio → Web Audio
Depends on: 880129
Depends on: 880265
Depends on: 880202
Depends on: 880342
Depends on: 880384
Depends on: 880404
Depends on: 880724
Depends on: 881558
Depends on: 881587
Depends on: 881775
No longer depends on: 881775
Depends on: 881959
Depends on: 882171
Depends on: 882956
Depends on: 883010
Depends on: 883011
Hello, I'm getting a sample rate of 48khz in my AudioContext (using the nightly) even if I'm not hooked up to any special audio interfaces. I would expect 44.1... or am I thinking about something wrong? - Charlie
(In reply to bigbadotis from comment #37)
> Hello, I'm getting a sample rate of 48khz in my AudioContext (using the
> nightly) even if I'm not hooked up to any special audio interfaces. I would
> expect 44.1... or am I thinking about something wrong? - Charlie

Why would you expect 44.1kHz?

The spec does not mandate any particular sample rate. You should always use |AudioContext.sampleRate| to make your calculations anyway, you cannot have guarantees about what the samplerate will be on any particular platform, as it is hardware and OS dependent.
I'm guessing I'm misunderstanding something fundamental here, but, if my DAC is running 44.1, and Firefox is processing at 48, where is the downsampling occurring? Isn't it a 10% efficiency hit if Firefox is processing more samples per second than my computer is outputting via the DAC?

Thanks for any clarification.
You are perfectly right, and this is an issue we are going to address in the future, but there is only so many hours in a day.
Depends on: 883591
Depends on: 884459
Depends on: 884632
Depends on: 885496
Just downloaded the Nightly. No createOscillator() ? 

I've been wanting to test this app in FireFox:

http://cloudmusiccompany.appspot.com/

Is there a temporary fix for that to begin testing? Thanks.
Depends on: 885505
(In reply to comment #41)
> Just downloaded the Nightly. No createOscillator() ? 
> 
> I've been wanting to test this app in FireFox:
> 
> http://cloudmusiccompany.appspot.com/
> 
> Is there a temporary fix for that to begin testing? Thanks.

Bug 865253 tracks implementing OscillatorNode.  We hope to land the fix to that bug within the next few days...
Depends on: 886165
Depends on: 886168
Depends on: 886381
Depends on: 885956
Depends on: 886787
Any plans to implement createMediaElementSource ?
(In reply to comment #43)
> Any plans to implement createMediaElementSource ?

Of course!  See bug 855568.
Depends on: 889016
Depends on: 889042
Target Milestone: --- → mozilla24
Depends on: 890023
Depends on: 890072
Depends on: 890369
Depends on: 890371
Depends on: 881092
Depends on: 891254
Depends on: 895196
Depends on: 898962
Summary: Implement Web Audio → Implement and ship Web Audio
This is currently marked as targeted for Firefox 24.  Am I wrong an thinking this should be updated to reflect the new intention to let it bake a bit longer and ship in 25?
QA Contact: manuela.muntean
Target Milestone: mozilla24 → mozilla25
Depends on: 904707
Depends on: 904302
Depends on: 905444
Depends on: 906966
Depends on: 907758
Depends on: 907986
Adding the feature keyword so that this bug is properly picked up by the Release Tracking wiki page.
Keywords: feature
Depends on: 914030
Depends on: 910171
Depends on: 915524
Is everything on track to leave this on in Firefox 25 and have it pulled into Firefox 1.2?  The last answer was yes, but I wanted to confirm before Monday.
I'd say yes, for my blockers. Ralph?
Flags: needinfo?(giles)
It's going to be close, but I still intend to close by blocker before Monday.
Flags: needinfo?(giles)
Did we make it?
(In reply to comment #50)
> Did we make it?

Yeah, we'll try to uplift the patches that missed the deadline.
Ok great, drop in a comment once the last blocker is confirmed as in both Firefox 25 Desktop and Android along with Firefox 1.2.  If either of those release versions changes, please let me know asap.
Depends on: 920987
Depends on: 912474
Depends on: 921695
Let's call this fixed.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Depends on: 923319
In case anyone wants to do some performance tests, my app here is updated to work with FireFox's Web Audio API support (trying to keep consistent with iOS 6's Web Audio API in Safari Mobile and FireFox needs basically two interfaces).

http://cloudmusiccompany.appspot.com/
Depends on: 913854
Depends on: 924286
Depends on: 924288
Depends on: 924289
No longer depends on: 924289
Depends on: 925619
Depends on: 932621
Blocks: gecko-games
Depends on: 956489
I've been testing WebAudio API on firefox 27 (beta as of today) with audio tag as source [createMediaElementSource(audio_tag)], and after doing that binding, setting the audio_tag.playbackrate during audio execution makes no effect anymore... also, timeudate event is not fired, and the audio tag cursor on the controls stops indicating the current time.

Hope this report helps.
(In reply to Sergio from comment #55)
> I've been testing WebAudio API on firefox 27 (beta as of today) with audio
> tag as source [createMediaElementSource(audio_tag)], and after doing that
> binding, setting the audio_tag.playbackrate during audio execution makes no
> effect anymore... also, timeudate event is not fired, and the audio tag
> cursor on the controls stops indicating the current time.
> 
> Hope this report helps.

I think this (apart from the playback rate thing) has been fixed in current Nightly.
(In reply to Paul Adenot (:padenot) from comment #56)

> I think this (apart from the playback rate thing) has been fixed in current
> Nightly.

It sounds like Sergio is reporting more than one bug here.

Paul -- Is there a bug already tracking some of this?  If so, do you have the bug number?  And is there a fix available that should be uplifted (at least to Fx 28)?  Does the playback rate problem (that you think may not be fixed) also have a bug number, and is it a Web Audio bug or Video/Audio (Media Playback) bug?  Thanks.
Flags: needinfo?(paul)
(In reply to Maire Reavy [:mreavy] from comment #57)
> (In reply to Paul Adenot (:padenot) from comment #56)
> 
> > I think this (apart from the playback rate thing) has been fixed in current
> > Nightly.
> 
> It sounds like Sergio is reporting more than one bug here.
> 
> Paul -- Is there a bug already tracking some of this?  If so, do you have
> the bug number?  And is there a fix available that should be uplifted (at
> least to Fx 28)?  Does the playback rate problem (that you think may not be
> fixed) also have a bug number, and is it a Web Audio bug or Video/Audio
> (Media Playback) bug?  Thanks.

That would mean uplifting roc's changes in 938022, if not more.

The playbackRate bug is a bug at the barrier between Media Playback and Web Audio. I opened bug 966247 to track this.
Flags: needinfo?(paul)
(In reply to Paul Adenot (:padenot) from comment #58)
> That would mean uplifting roc's changes in 938022, if not more.

Thanks for the bug number.  The good news is that that fix is already in Fx 28.
> 
> The playbackRate bug is a bug at the barrier between Media Playback and Web 
> Audio. I opened bug 966247 to track this.

Thanks!
Flags: sec-review?(cdiehl) → sec-review+
Depends on: 1020370
No longer depends on: 864780
You need to log in before you can comment on or make changes to this bug.