...and unfortunately having dabbled with professional software drum kits and sampling 
software, I can guarantee complaints of audio fidelity.

So what are we going to do about this bug?  I see 3 options
1. try to get site to switch to mp3, aac or ogg
2. add wav support to chromium
3. do nothing and not support this site.

I haven't reached out to them yet, but they should do Vorbis + MP3.

I understand your concerns about pcm_s16le in RIFF/WAV becoming the defacto standard 
for HTML5 audio but for an application like this it seems to make a lot of sense. Using 
a lossy transform codec when properties like masking ratio are going to change based on  
the chosen output composition seems more than a little silly. 

In an ideal world where webapps can do anything that desktop apps can, PCM support 
seems critical for a variety of audio applications.

I recently ported a Commodore 64 SIDPlayer to Javascript and PCM support is critical. 
Either audio/wave or some JS API that allows raw samples to be passed in. Right now 
generate data URIs in audio/wave PCM format and pass them to an Audio object, but 
this doesn't work on Chrome, only Firefox and Safari. MP3/OGG is way way too 
expensive for real time synthesis.

The idea situation would be to avoid Wave and data URIs, and have a 'canvas-like' 
interface where raw audio samples can be passed to the browser, much like raw 
pixels in the canvas API. Barring that, please support Wave w/PCM.

We added support for data URIs not too long ago, but unfortunately that still won't 
make wave/pcm work :\

A few other people have suggested an "audio canvas" interface and I believe that's the 
proper solution.

+1 for audio canvas. Being able to grab decoded buffers as their about to be played 
would allow 'visualizations' to be done, software graphic equalizers, and other effects, 
and being able to write to buffers for playback would enable lots of synthesis style apps.

However, this seems like something that won't make HTML5, so supporting PCM in the 
mean time sounds like a good fallback.  PCM is practically a 'no-op' codec so it 
shouldn't be too hard to support.

If your C64 concern is that you'll be doing many channels of audio and the CPU adds up 
to too much, then PCM is also prohibitive, from a streaming point of view.
A decompression cache, as done for JPG, might be the best solution.
But AAC/MP3 is relatively low on our CPU profiles, so no effort has been put into 
optimizing it.  If you can find a use case where <audio> bogs down the CPU, we'd be 
very interested to see that.

The C64 emulator already mixes channels in JS, the issue isn't really the expense of 
generating PCM or even data URL encoded PCM, the issue is, Chrome doesn't support 
Wave PCM. This means, the only possibility for synthesizing audio-on-the-fly is to 
have Javascript perform AAC/MP3 compression on the fly, which obviously is 
extremely inefficient to say the least. Basically, a SID player is impossible to realize in 
Chrome because of this unless you run it in non-realtime, generate the entire song, 
encode it, and play it back (which is tricky with SID music since you often don't know 
where the end of the song since your blindly emulating a 6502 CPU playing back an 
app)

The idea of an AudioCanvas, or at least a method like audio.getSampleArray(), is to 
go beyond efficient playback of synthesized sample buffers, but to also allow 
applications to process audio data, either for special effects, equalizers, or the 
common music visualizations you see in almost every music player out there. The 
<video> and <canvas> elements allow access to pixels, but the <audio> element 
allows no access to samples.

But I'm not suggesting there's any real timeframe for doing that for HTML5. I just 
want to be able to generate an <audio src="data:audio/wave;base64,...."> URL out of 
a JS array of 16-bit 44Khz samples, and have Chrome play it. This works today in 
Firefox and Safari on all platforms.

(No comment was entered for this change.)

(No comment was entered for this change.)

(No comment was entered for this change.)

cromwellian, would you have an example of this you can point to?

Check out http://acko.net/files/audiosynth/index.html which has JavaScript
dynamically generating Wave format data, base 64 encoding it, making new audio
elements with data URIs, and playing them.

I'm trying to do the same thing with MIDI files which John Resig discusses here:
http://ejohn.org/blog/embedding-and-encoding-in-javascript/

To generate some static data to cut and paste try a command line like this (in Linux):
> base64 --wrap=0 sound.wav

My particular concern is to have the same audio application work on the major smart
phones and the widest range of desktops. Right now (and for the foreseeable future)
HTML5 and JavaScript covers the widest market, and for basic real-ime client-side
generated audio Firefox and Safari are okay but Chrome is not. I'll be developing for
Safari and Firefox with my fingers cross that Chrome and Android will catch up soon,
(before I buy next phone).

Please don't forget this problem also matters for generated MIDI as well as raw audio.  

New experimental APIs are being developed to properly address dynamically generated 
audio.

My personal feeling is using base64 encoded data URLs via <audio> is somewhat of a 
neat trick but we'd all be better off with a dedicated API.

(No comment was entered for this change.)

Renaming bug for clarity.

 Issue 42687  has been merged into this issue.

1. Firefox and Safari support wav files, including their data URI variants. Chrome 
shouldn't lag behind.
2. Dynamic browser-side audio generation will always lead to a simple sample-by-
sample lossless format, thus ruling out any of the mentioned lossy/CPU-intensive 
audio-representation candidates like MP3, Ogg!
3. Speech technology companies want browser-based applications too - server 
roundtrips for every audio manipulation in the browser are simply prohibitive. 
Professional audio is always in a lossless format. Random access inside such audio is 
crucial. Note that the above comments seem to be restricted to hobbyist/consumer/non-
commercial apps, hence this plea to not overlook the professional sector.
4. We can't wait years for "audio canvas" (I was the author of that term in the 
WHATWG mailing list) to be standardized. WAV can to be supported now, since it fits 
the spec as it currently stands. In its PCM variant it is an extremely simple format; 
it is not clear to this commenter why it's not in Chrome already!
5. Base-64 audio manipulation can be done real-time, I have extensive experience in a 
commercial settings with that. Chrome is way faster than other browser on the display 
side (<canvas> element), but currently unusable for professional audio. From my point 
of view, therefore, this bug has high priority.

Wait, Chrome doesn't support WAV PCM?!  WHAT. THE. CRAP.

Geez, OGG vorbis doesn't work in Safari, MP3 doesn't work in Firefox, and WAV doesn't work in Chrome.

*#%%$!

.wav seems a reasonable choice for some use cases (e.g. a dictionary playing audio samples). I don't think preventing an uncompressed audio format from becoming a cross-browser standard is a good rationale. On the plus side, it seems like a reasonable assumption that any program that supports a lossy format also supports some non-lossy format. Unless there are technical (i.e. non-political) reasons against it, Chormium should follow its peers in supporting .WAV.

If a raw Audio canvas API is added,  it will alleviate some of the pressure to have this, although some apps might still want *lossless* audio loading/saving, which we do have with image support.  Moreover, if WAV support isn't added, people will resort to workarounds, like serializing the WAV as JSON which is far worse for network consumption.

For the simple purpose of having a standard audio format that works in MORE THAN 2 BROWSERS. Please up the priority on this one! 

^^^Actually 3 browsers.  Even Safari supposedly supports WAV.

Yes, Safari like IE9, supports audio and video tags via the system media playback systems (quicktime in safari's case), and so safari supports anything quicktime does, including mov, wav, aiff, alac, sorenson squish, and even things like flv, avi, ogg vorbis/theora, and mkv if you have the appropriate codecs installed.

I just realized, I cannot think of a single program/device/whatever that can play audio that cannot play WAV PCM.

...except Chrome.

I am writing a web-based demo and I was shocked when my first attempt did not work in Chrome. My app loads a few small base64 encoded chunks of audio data, and then manipulates them in several ways client-side to produce a soundtrack in sync with the visual elements.

Wav may seem impractical for browsers, but if we're able to generate them client-side, it is the ultimate compression scheme. I could generate an endless, never repeating audio track in a 40kb page. There's no way I'm going to implement an compression encoder client-side, just to have the browser decode it again, so, for now "Not supported by Chrome".

I was surprised that WAV files were not supported as well. I am writing a professional sound quality testing app that requires lossless audio playback, specifically .wav. I could realistically require users move away from IE but because of this issue in Chrome I will have to resort to writing a flash or java player to embed in the app. There is a real need for WAV playback! Lossy, compressed formats are unacceptable for many applications!

Apparently falling back to the embed tag works in Chrome, but surely this is not the kind of thing the chromium team would like to see as a practical solution. 

http://www.phon.ucl.ac.uk/home/mark/audio/play.htm

As far as I can tell, this doesn't work in chrome with base64 strings, and so "on the fly" JavaScript audio generators still aren't going to work. I've tried it with mime types audio/wav, audio/wave, audio/x-wav; all of which work in Safari/Firefox.

I am developing a Flash HTML5 web application with audio and I share the frustrations of other comments posted here. There is NO single format that is supported across all modern browsers. WAV has the most support--if Chrome purports to support HTML5, it MUST play WAV audio, plain and simple, or developers are going to be wary of realizing some of the web apps that HTML5 could open the doors for. If they don't just resort to using Flash instead, a developer would have to transcode every single audio file (which in my case is tens of thousands) into multiple formats, possibly losing audio quality in the process, making their application run slower, and wasting disk space.

Why is Chrome lagging behind Safari and Firefox? When will WAV support finally be implemented in chromium? 

I Agree.  Chrome should support WAV.  We automatically generate web sites for users from a windows app.  The user selects sounds to play when certain conditions occur.  We do not want the user to have to select multiple file types so it works in Chrome.  We also should not have to automatically convert and keep two files around just for Chrome.  HTML 5 should mean that we can count on a standard behavior accross browsers.

FireFox, Safari, and Opera all currently support WAV.  I suspect Internet Explorer will as well.

(No comment was entered for this change.)

I understand the concerns about WAV becoming a de-facto standard, but I think in reality that's extremely unlikely -- web developers know that using WAV takes up lots of bandwidth, and web users are unlikely to stick around waiting for sites that serve up huge downloads on every visit. It's survival of the fittest: sites that distribute large numbers of uncompressed audio files will quickly collapse under their own weight.

Also, while I applaud the idea of an "audio canvas" (which would be great for some of the sound synthesis stuff I've been doing), I don't think it's a replacement for WAV support. There are times when uncompressed audio is exactly what you want, despite its drawbacks, and it would be wonderful if Chrome users could hear those sounds, too.

I guess in the end I just don't see how this is different than, say, the BMP format: another uncompressed file format which is (rightly) supported by all major browsers, but is not widely used in practice due to its large file size. The web is a free market; it will regulate itself on an issue like this. In the meanwhile, Chrome users unfortunately have impaired access to uncompressed audio/in-browser sound synthesis.

I also vote on adding WAV support to Chrome, especially via src="data:...". I've recently played with audio generation on-the-fly and was suprised that only major browser that doesn't support WAV files (which are easiest to generate in JS) is Chrome. Please add this, and I'm not talking about whole WAV spec (which is huge), but maybe only Format & Data chunks (no compressions) for starters. Oh, and while at it, please make it so the gapless playback is possible (as described here: http://forestmist.org/2010/04/html5-audio-loops/)

Note, that WAV support only solves half the problem. The other is precision
timing. Currently, HTML5 media elements lack the rugged timing
specifications that SMIL had, so you can't, for example, arrange for 5
<audio> tags to place one after another in serial with no gaps, or play in
unison at exactly the same start time. You can't seek to a particular
millisecond or frame, among the many limitations. It would be nice to add
WAV support, but even better would be to fix the audio/video/mediaelement
stuff.

There is a W3C Incubator group for that called the Audio Incubator Group. Their aim is to provide an interoperable way to edit audiostreams in various browsers. For more information about that you can read the following three links:

http://www.w3.org/2010/04/audio/audio-incubator-charter.html
http://chromium.googlecode.com/svn/trunk/samples/audio/specification/specification.html
http://peter.sh/audio

This is, however, not directly related to the playback of WAV files. To cite fbarchard from  bug 42687 : "We dont want to see an uncompressed format becoming the web standard."

That's not a very good reason compared to ones such as "I want to generate audio data on the fly from JavaScript" imo.  And as someone else pointed out, the uncompressed nature of WAVs will in fact ensure that it will be used properly, thanks to a hoster's bandwidth and disk space limits.

I've built a notification sound effect into my extension and my options page allows you to select a url or a local file.  However, on Windows at least, sound effects are usually stored in WAV format.  Not being able to use WAV files could be unintuitive.  Worst case I can just throw up an error dialog with a link to this thread and a suggestion to star if the user wants to see WAV playback in Chrome. :)

I'd love to see an Audio Canvas API, but its clearly not going to be available any time soon. The idea of not implementing something that is available in every other browser, preventing people from synthesizing and processing sounds in Javascript, just to try to prevent a particular file format from becoming popular on the web seems ridiculous. Especially so, when WAV has had plenty of time to become a (terrible) standard on the web, and has not.

Please don't make us wait (potentially) years for something we could have right now.

This is a minimal testcase for the (hopefully) upcoming WAV support:

<audio src="data:audio/x-wav;base64,UklGRiIAAABXQVZFZm10IBAAAAABAAEAIlYAAESsAAACABAAZGF0Yf7///8AAAAANwA6AD0APwBCAEUARwBJAEwATgBQAFEAUwBVAFcAWABZAFsAXABdAF8AYABfAF4AXQBcAFwAWwBaAFgAVQBTAFEATwBNAEkARQBCAD8AOwA4ADUAMwAwAC4AKwAnACMAIAAcABkAFgARAAwABwADAP//+//3//L/7f/o/+P/3//b/9f/0//P/8z/yf/G/8P/wP+9/5r/ev9b/0L/Lf8a/wr///71/uz+6f7l/uT+5P7l/un+7/71/v3+Bv8O/xj/JP8z/z//Tf9b/2j/df+E/5D/nf+q/7j/xf/U/+L/8f/+/wsAGgArADwATgBeAG0AfQCOAJ4AsADCANQA5gD4AAkBGwEqATgBSgFZAWcBeAGGAZYBowGvAboBxQHQAdoB4wHqAfMB+QH/AQUCCAILAg8CEAIOAg4CCQICAvwB9AHrAeIB1wHLAbwBrAGaAYgBdAFgAUoBNAEdAQMB6ADPALUAmAB7AF4AQAAhAP7/2/+4/5X/c/9R/y//D//u/s3+rf6N/m/+U/41/hz+A/7s/df9xP2y/aP9lv2M/Yb9gf1F/RL95vzC/KP8iPx0/GX8XPxY/Fj8YPxr/Hr8ivyd/LP8y/zl/AP9If1A/WX9i/20/d39Bv4x/lv+iP62/uj+Gf9J/3v/rf/i/xgATwCIAL8A9gAuAWcBmwHPAQICNgJqAp0C0QIDAzADXQOIA7ED2QMABCYESQRqBIcEpQTBBNoE8AQEBRYFJQUzBT8FRwVMBU4FTwVLBUYFQQU4BSoFFwUABecEzgSvBI8EagRFBBwE8QPEA5QDYAMsA/UCugKAAkICBALHAYgBSQEGAcIAfAA2AO3/ov9Y/w3/wf54/iz+4v2Z/VH9DP3G/IL8QvwE/Mr7k/te+y77Afvb+rb6lvp++mv6/fmc+Uz5BPnL+Jv4dfhX+ET4Ovg0+Db4OvhE+FP4a/iG+Kb4yfjz+CL5V/mR+dL5G/pq+rz6E/tv+877L/yS/Pv8ZP3R/UH+tf4j/5T/BAB3AOgAWwHNATwCqAIUA30D5QNJBLAEFgV3BdMFKgZ9BtAGGAdhB6cH5QceCFYIiQi4COAIBwknCUQJWgltCXkJgAmACXsJcQljCVIJOwkcCfgIzQihCHEIOwj/B8MHgQc6B+8GpAZRBvoFogVHBegEiAQlBL0DVQPsAoACFAKqAT4BzwBbAOj/dv8E/5D+Gv6i/Sj9rvw1/Lr7P/vF+kv60flZ+eP4c/gH+J/3P/fm9pr2VfYf9nv16fRq9PvzmfNI8wHzx/KU8m3yTvI48ijyJ/It8jzyVvJ78qfy4fIj83Tz0vM89LX0OPXC9VH27vaT9z/48vio+WP6J/vu+7j8hv1X/in//f/UAKkBegJGAxIE3ASZBVcGFAfNB34IJAnICWQK9wqICw0MiQz+DGsNzA0hDm0Otg73DikPTw9qD30PgQ9+D28PWQ84DxcP6g6yDnUOMQ7mDZINOg3dDHoMEwynCzcLwQpJCs0JUgnTCFIIzAc/B64GHAaGBesEUwS4AxkDdwLWATIBkQDu/0v/pP75/U79o/z0+0D7jfrT+Rv5Yvil9+32OfaM9eP0R/S58z3z9/HN8Nfv7e4F7iXtOOxW63nquOkC6Wfo1+dZ5+zmm+Zo5lDmZ+aa5v/mgOcf6ODoy+nc6g/sZu3V7mTw//Gq81f1EffR+Iz6N/zd/XX//gB7AuIDQgWSBtsHFAlDCmkLiAycDaMOpA+UEH0RThITE7oTSRTMFDYViRW7Fd8V6hXkFc0VohVzFTUV+hSzFHUULhTnE6MTYxMqE+wSuRJ7EkISBBK/EXwRLBHdEHYQEhCXDxsPhQ7gDTwNiQzfCxwLVwqBCawIygfhBvsFDwUoBCgDMwItATIANv9A/kr9RPxC+yX6Efno9832nPVs9C7z4fGR8DHv8u3I7LjqMuhu5qfkpOK44KTet9zW2ivZmdd91jjVr9Qg1PPTR9So1LjV0taj2E3auNwG3+LhweTU59rqCu418Sz0dvcZ+gf9gv/4ASIEIQbjB4AJGQtnDKQNxA7RD9gQ6BHVErATpxReFTsW4RaHFwcYcBjFGO0YABnoGMgYmhhaGBIYuxdlFxoX6ha6Fp0WoBa0FusWTBexFxQYrxhCGfUZqhovG/cbfBz3HGwdmB25HdQdiB0zHZgclxvSGo4ZRxi2FugUDhMPEf4OugynCj8IggYcBFACPQBk/vf8OPvB+Ur4nPYv9Qf0nvHI8B3uVOx46lvn/OQ14krfvtud2OnT89GtzS7L+sgnxmbE6MJKwlHBq8I5wmbEMsavyNTL/87X0mLWWtv03uXj++ch7IfwdfQy+Fv75/7ZAFME5gUQCL8JJAuODJkNvw5KD7sQKxF9EgMT3BOiFHAVQxamFjUXThe9F8cXzRd8FzAXvhZNFtkVHxWlFDwU1xO6E7MTxhNVFD4VXRbSF30ZThvCHSMgpyJDJcEnKyprLKAu7y9BMdUxNjLPMfUwjC9ELQcrESjVJAwhsB2jGf4VVBK1DjsLIwhPBSIDlwDs/q39bvto+5b5Lflh9yf3F/WY8/7wyu506qnnLORI3VXalNPezyzIE8Vlvk67PrgbtSi0z7K8sw+1SbhvuSbAqsFuyP/M59Cg1iLbdd8o44bnQums7J3ug/Bk8vHzIfX69qn42Pny/L394gAnBPkFpgkIDMQObxF2FJwVcBc/GIMYOxhBF00VFhMDEa8NHgttB3kELwL7/5r+DP4V/i//VAG/AwQHKQuhD58U9RkRH+AjhCj5LNUwTzT1Nhg5pjp+Oyc8gjvdOkQ6VTnoN9U27zRXMyEyyDBgL5wtLyxPKu8oCSVPJKMfexzfGvUSZRI9ClQH5gEY/X758fS98hLuYO+L6SvsnOlo6jXq/+jJ6CrnDOVN48/f6Npz2J7Qg84OxHTBLLsqt821m7H2sdqwILPRtVy5Pr2xxMzHOtBo1H/YS9+A4SHoAelq7NDt+O2f8Avw3vH38nb0P/eR+aj7OwB3AjkIuQy3D7oUYRaeGYEahRuvGrYYqxamEm4OoAlfBCMAffz0+Aj3IvU69cn2+vgV/XMBVgYNDI0R1xauG1wglST7J/gqtyyxLcAuxC/UMJEyIjMENV02ATjNOgM8gz52QOBBw0LcQutAPD+3OyA5hTMhL00owyGJG58Uuw4cCVkDIAA6/Kz59Pc+9Zj2XfZh90D59Phw+c/6m/mc+ub1HvQ47cnocOEy2DPRu8c9wNq6A7PtrR6scKhprUOu5LLLte+8nMEoxoXMws4Z0e/VrtRc1X7U9tCY0/rRYtRD1RTYVNwU49Hp1vFL+dEB5QiTEbcV7BeQG/gasxoxGEITjQ0mCK8Dx/5M+mD3ufR+9Lz0iPVI92P5L/3WAAMDlgW3BsAHUglKCqYK3wr1C3oNnw/ZEqEWuhuCIrkpBDHhNwM+TkSySRBOjlD8UI5QIk7QStZGuEE3Pe84BzUBMmst9ioNKRsn/yWcJS8jvSAuHhQbVhXbEasMCwchAiL95fiA8/HzHfBk8hvyr/Zc+RH9FP9nBUEEFwN/BIn3s/SO57ngQtFpyKe6m7Tqqxim9KT8oqGr8K19uW+5DcWExTvOEtDwz+3Q5s4CzofIychAxG7JcMpi02ra6uI67Q737QLwCu0U/hdMGwoctBjxE9UN6QajATn/H/r89/P1pvaP+JL5bf1R/joBLAG6AIP9lvkZ9uDyDvF28PHwdfKM9hn8FgR/DZEXyyE5K+Ez3zlePZY/TEBOQNw+izzaOe832Df3OEE6LTwPPwhB5UNLRWZFBUO7Pzo79DPcLOAjtxugFHUOYAsWCPYF+wbxB/cJag2dDc4OpQ26DacIdgalA9X+1//q/of9BP7AAdwBmw0TCnALrgXj+GjzQ+SG2WnIAsBQr5moL566l/WX6KDTqCKy+bz2u//FYcdTyzXMVMsszGbKQck=" autoplay>

I can't understand the resistance on adding support for WAV. It's one of the basic resources that we need to develop simple audio apps, even if it's not dynamic. And so, PLEASE, FORGET about the bandwidth issue. We really have other interfaces to access WAV files, e.g. http://dev.w3.org/2006/webapi/FileAPI/. I really expect that we have support for WAV on Chrome before Internet Explorer 9 arrives.

(No comment was entered for this change.)

The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=59411

------------------------------------------------------------------------
r59411 | fbarchard@chromium.org | Tue Sep 14 12:10:22 PDT 2010

Changed paths:
 M http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/ffmpeg/source/config/ChromiumOS/linux/x64/config.h?r1=59411&r2=59410&pathrev=59411
 M http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/ffmpeg/source/config/Chrome/win/ia32/config.h?r1=59411&r2=59410&pathrev=59411
 M http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/ffmpeg/source/config/Chrome/linux/ia32/config.h?r1=59411&r2=59410&pathrev=59411
 M http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/ffmpeg/source/config/Chrome/mac/ia32/config.h?r1=59411&r2=59410&pathrev=59411
 M http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/ffmpeg/source/config/ChromeOS/linux/ia32/config.h?r1=59411&r2=59410&pathrev=59411
 M http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/ffmpeg/source/config/Chromium/win/ia32/config.h?r1=59411&r2=59410&pathrev=59411
 M http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/ffmpeg/source/config/Chromium/linux/ia32/config.h?r1=59411&r2=59410&pathrev=59411
 M http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/ffmpeg/source/config/Chromium/mac/ia32/config.h?r1=59411&r2=59410&pathrev=59411
 M http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/ffmpeg/source/config/ChromiumOS/linux/ia32/config.h?r1=59411&r2=59410&pathrev=59411
 M http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/ffmpeg/source/config/Chrome/linux/arm-neon/config.h?r1=59411&r2=59410&pathrev=59411
 M http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/ffmpeg/source/config/ChromeOS/linux/arm-neon/config.h?r1=59411&r2=59410&pathrev=59411
 M http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/ffmpeg/source/config/Chrome/linux/arm/config.h?r1=59411&r2=59410&pathrev=59411
 M http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/ffmpeg/source/config/ChromeOS/linux/arm/config.h?r1=59411&r2=59410&pathrev=59411
 M http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/ffmpeg/source/config/Chrome/linux/x64/config.h?r1=59411&r2=59410&pathrev=59411
 M http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/ffmpeg/source/config/Chromium/linux/arm-neon/config.h?r1=59411&r2=59410&pathrev=59411
 M http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/ffmpeg/source/config/ChromeOS/linux/x64/config.h?r1=59411&r2=59410&pathrev=59411
 M http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/ffmpeg/source/config/ChromiumOS/linux/arm-neon/config.h?r1=59411&r2=59410&pathrev=59411
 M http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/ffmpeg/source/config/Chromium/linux/arm/config.h?r1=59411&r2=59410&pathrev=59411
 M http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/ffmpeg/source/config/Chromium/linux/x64/config.h?r1=59411&r2=59410&pathrev=59411
 M http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/ffmpeg/source/config/ChromiumOS/linux/arm/config.h?r1=59411&r2=59410&pathrev=59411

ffmpeg config files for sept 09 ffmpeg and enable wav and vp8 encode
BUG=23916,55562
TEST=none

Review URL: http://codereview.chromium.org/3390002
------------------------------------------------------------------------

The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=60246

------------------------------------------------------------------------
r60246 | fbarchard@chromium.org | Wed Sep 22 17:36:13 PDT 2010

Changed paths:
 M http://src.chromium.org/viewvc/chrome/trunk/src/DEPS?r1=60246&r2=60245&pathrev=60246

roll ffmpeg to sept 09 version for Chrome 8. Includes wav decoder and vp8 encoder for all x86 configurations.
BUG=23916, 55562
TEST=wav should play with <audio> tag

Review URL: http://codereview.chromium.org/3393010
------------------------------------------------------------------------

The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=60248

------------------------------------------------------------------------
r60248 | thakis@chromium.org | Wed Sep 22 17:48:57 PDT 2010

Changed paths:
 M http://src.chromium.org/viewvc/chrome/trunk/src/DEPS?r1=60248&r2=60247&pathrev=60248

Revert 60246 - roll ffmpeg to sept 09 version for Chrome 8. Includes wav decoder and vp8 encoder for all x86 configurations.
BUG=23916, 55562
TEST=wav should play with <audio> tag

Review URL: http://codereview.chromium.org/3393010

TBR=fbarchard@chromium.org
------------------------------------------------------------------------

The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=60267

------------------------------------------------------------------------
r60267 | fbarchard@chromium.org | Thu Sep 23 00:19:09 PDT 2010

Changed paths:
 M http://src.chromium.org/viewvc/chrome/trunk/src/DEPS?r1=60267&r2=60266&pathrev=60267

ffmpeg roll for chromium
BUG=23916,55562,56561
TEST=none

Review URL: http://codereview.chromium.org/3496003
------------------------------------------------------------------------

The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=60269

------------------------------------------------------------------------
r60269 | phajdan.jr@chromium.org | Thu Sep 23 01:17:26 PDT 2010

Changed paths:
 M http://src.chromium.org/viewvc/chrome/trunk/src/DEPS?r1=60269&r2=60268&pathrev=60269

Revert 60267 - ffmpeg roll for chromium
BUG=23916,55562,56561
TEST=none

Review URL: http://codereview.chromium.org/3496003

TBR=fbarchard@chromium.org
Review URL: http://codereview.chromium.org/3455017
------------------------------------------------------------------------

The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=60533

------------------------------------------------------------------------
r60533 | fbarchard@chromium.org | Fri Sep 24 15:07:49 PDT 2010

Changed paths:
 M http://src.chromium.org/viewvc/chrome/trunk/src/DEPS?r1=60533&r2=60532&pathrev=60533

ffmpeg roll for chromium
BUG=23916, 55562, 56561
TEST=should build with clang & freebsd

Review URL: http://codereview.chromium.org/3417020
------------------------------------------------------------------------

First step is in.  WAV+PCM are added to FFmpeg.  Should work with <audio> tag in trunk now.
Just need to add mimetype

Horray!!! :D:D:D

Hello, I apologize, but does this mean WAV support is going to be part of official Chrome release? That would be just great. 

@matt
Yes, tentatively planned for the Chrome8 release.
This site tests mimetypes and will be a good one to test against:
http://beta.html5test.com/

 Issue 53564  has been merged into this issue.

The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=60856

------------------------------------------------------------------------
r60856 | fbarchard@chromium.org | Tue Sep 28 15:25:20 PDT 2010

Changed paths:
 M http://src.chromium.org/viewvc/chrome/trunk/src/net/base/mime_util.cc?r1=60856&r2=60855&pathrev=60856

add audio/wav mimetype
BUG=23916
TEST=http://beta.html5test.com/
Review URL: http://codereview.chromium.org/3474015
------------------------------------------------------------------------

The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=60859

------------------------------------------------------------------------
r60859 | fbarchard@chromium.org | Tue Sep 28 15:41:46 PDT 2010

Changed paths:
 M http://src.chromium.org/viewvc/chrome/trunk/src/net/base/mime_util.cc?r1=60859&r2=60858&pathrev=60859

add audio/x-wav mimetype for apache
BUG=23916
TEST=http://fbarchard0-w.ad.corp.google.com/mediatests/2ch_test_folded_16int.wav

Review URL: http://codereview.chromium.org/3554001
------------------------------------------------------------------------

@dr.marikos your test case works in chromium trunk now.
http://www.randomthink.net/labs/html5drums/ plays but the timing seems off

7.0.538.0 (60891) Vista Ultimate SP2

WAV files play in chromium. see http://www-eng-x.llnl.gov/documents/a_sound.wav

There are issues with the built-in "player" as far as refreshing/repainting go. E.g., open the above URL and then resize the browser window. Or, click wrench > About Chromium > OK button. Attached is the player controls I see when opening a WAV file. Should this problem be opened in a new issue?

As for the test case mentioned in comment 56, it may have a problem playing multiple files at once. If you just check one effect, slow the tempo down to 30, and space it out enough, it will play them all & at the right time. Too close together (either by close placement in the columns or by faster tempo) and it won't play all samples as it should. If you add a second effect, even at the same time, it only plays one of them (most of the time - occasionally it will play both). 

Also, shouldn't the handling of WAV files show up in about:plugins? I notice that it overrides, for example, the Quicktime plugin that is enabled and set to handle WAV files sent as audio/x-wav or audio/wav. The URL above sends as audio/x-wav. 

	playback_controls_WAV.png 1.3 KB   View   Download

can someone detach comment 60 and add as an attachment so that we don't have a super-long horizontal scrollbar on this issue? :)

fbarchard: that page also supports playback using OGG audio-files, making the page work fine in the dev (and presumably beta/stable) channel. Timing is off there as well, so it's likely to be a separate issue.

Playing the wav file in comment 57 works fine, however, the tab crashes after I reload the page. The volume icon also indicates that the audio player is entirely muted, but it's perfectly audible.

Chromium 60909 on Windows Vista Business SP2.

Using Gooel Chrome 7.0.540.0 (Official Build 61029) canary build - I cannot listen to any WAV file. They do not play. They seem to be supported (they show the player when you browse there), but not listenable.
Example from the W3Schools (codec - pcm_u8) -
http://www.w3schools.com/media/liar.wav
Example from another website (codec - pcm_s16le) -
http://ws.d.co.il/PhoneReader/Default.aspx?custId=18938250&RandomFileName=8711285951441&headingCode=38010

Both of them are recognized by FFMPEG.

Also, both of them cannot be played with Chrome 7.0.536.2 (Official Build 60818) dev (which is supposed to support them, but not their MIME type, like you mentioned).

(If it matters, I use these command lines, some come from about:labs and some are derived from --enable-nacl -
--enable-gpu-rendering --enable-remoting --enable-experimental-extension-apis --enable-accelerated-2d-canvas --enable-nacl --enable-video-fullscreen --enable-file-system --internal-nacl --enable-gpu-plugin --enable-match-preview --enable-tabbed-options --enable-vertical-tabs)

http://junk.mzzt.net/monk_rant04.wav

Doesn't play.  Attempting to reload the page after trying to play it crashes the renderer.

@comment 60: 7.0.538.0 (60900) & 7.0.541.0 (61296) Ubuntu 9.10, I can play the w3schools WAV. The older build had problems with the "playing" tab & other tabs crashing when either refreshing or closing the "playing" tab.

A player was shown for the co.il URL, but the play button was not operable.

@comment 61: I had no problem playing that file, either. Refreshing the tab (during playback or after playback has stopped) crashes the tab, although a 2nd refresh loads the file w/ no problem.

http://www-eng-x.llnl.gov/documents/a_sound.wav
http://www.w3schools.com/media/liar.wav
http://junk.mzzt.net/monk_rant04.wav
all work for me on 7.0.549.0 (Developer Build 61784)

Note that only 3 formats are supported: pcm_u8 pcm_s16le and pcm_f32le

A crash to do with graphics was fixed recently, that was affecting controls.  This affected all audio formats.
WAV is added to mimetypes, so http://beta.html5test.com/ shows PCM audio support.
If there are new bugs/feature requests, please open a new crbug.

Do you seriously want me to open a new issue for something that never worked?

With Chrome 8.0.549.0 (Official Build 61915) canary build on Windows XP Professional SP 3 and on Windows Vista Home Premium SP 2 - all of these samples do not work.
This OGG sample does work -
http://upload.wikimedia.org/wikipedia/commons/a/a9/Tromboon-sample.ogg
But these do not work -
http://www-eng-x.llnl.gov/documents/a_sound.wav
http://www.w3schools.com/media/liar.wav
http://junk.mzzt.net/monk_rant04.wav

Maybe you should try it with a canary\official build and see for yourself. The sound does not play, the play button gets greyed out when you try to hit it after the file has (supposedly) loaded.

Confirmed, Canary 8.0.549.0 won't play these samples. It's not in 8?..

I too still can't play these files. in 549.0 canary or the latest dev.  Perhaps it's an OS specific issue, or some other factor that only breaks it for some people and not others?  I'm running Windows 7 64-bit.

Works for me on Linux: 8.0.550.0 (62060) Ubuntu 10.10

Canary 8.0.549.0 doesn't play for me either on Windows XP Professional SP3:

http://www-eng-x.llnl.gov/documents/a_sound.wav

gets curiously enough wrapped in <video> instead of <audio> according to Chrome's own web developer tools (elements view), and shows these log messages in the same, together with some kind of -1 return code for a_sound.wav:

Resource interpreted as document but transferred with MIME type audio/x-wav.
Resource interpreted as document but transferred with MIME type .
Failed to load resource

Same for all other examples given.

Hth, Markus

My js gameboy color emulator tries to default to WAV PCM data uri generation when mozilla's proprietary extension isn't available. Unfortunately the WAV PCM sound is getting chopped off, even though the simultaneous instances of WAV PCM data playing should not interfere with each other.

GBC emu: http://www.grantgalitz.org/gameboy/

peepo.com uses wav and at least on os x play audio in Safari, Opera and Mozilla,
but not Chrome....

it's a guess, but surely even IE9 beta plays wav...

Related issue 78452 (alaw compressed WAV files are not supported).

This issue has been closed for some time. No one will pay attention to new comments.
If you are seeing this bug or have new data, please click New Issue to start a new bug.

(No comment was entered for this change.)

(No comment was entered for this change.)

(No comment was entered for this change.)

(No comment was entered for this change.)