Tracking bug.

I have created a MozillaWiki article for the W3C Web Audio API: https://wiki.mozilla.org/Web_Audio_API

All the child bugs here are fixed. What's the status of this API implementation?

(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.

Just wondering... but when will this be avaliable for Firefox users?

(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.

Major content use case and needed for competitive parity.

(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!

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.

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.

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.

(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. :-)

(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!

(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.

(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!

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.

Ooops. My bad, OGG and WAV decoding are working perfectly. (test case here : http://minimal.be/mozilla/decode/ )

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!

(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

needs fuzzing

(In reply to comment #31) > needs fuzzing Jesse has been doing some of that. Will definitely need more!

It would be great if we could relnote this on Aurora once 23 gets there.

(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.

(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.

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.