Chromium

[Empty comment from Monorail migration]

[Empty comment from Monorail migration]

[Empty comment from Monorail migration]

using just 'audio' doesn't work either: webkitGetUserMedia('audio',...)

Eric do you have the WebRTC flag enabled?

Niklas, I recall also a similar request in chromium-dev about this, can you triage after we get feedback?

thanks

Yes I do. Try http://jsbin.com/unaqir/edit#html,live

Assigning to grunell that can comment on this. I don't think local audio loopback through an audio tag is supported (yet), only to connect to a PeerConnection for remote streaming. Getting a local video preview has much higher priority to get implemented vs getting an audio loopback. Suggesting P3 for this.

[Empty comment from Monorail migration]

FWIW, I'm getting a lot of developer requests to get mic input and pipe it through the web audio api.

Not sure of the internals, but theoretically the rest of the pieces are already there.
See http://updates.html5rocks.com/2012/02/HTML5-audio-and-the-Web-Audio-API-are-BFFs

Can we keep this at a p2? It's already got 16 stars :\

Correct, this is not supported yet.

Is there an ETA for piping the mic input through the web audio api? Is this feature in development or is planned for future releases?

I love to play with this feature, please guy :)
I imagine live microphone capture to be re-injected in audio context. This can be a full interactive experience. http://www.b2bweb.fr/bonus/Braincer/ (working draft)

Yep, can't wait for the feature.
So I can stream it to the server and than stream to the hundreds of connected clients,
live radio in a browser. :)

Eagerly waiting for this!

[Empty comment from Monorail migration]

Is there any news about it?

no news yet. I'll update the bug once we get close.

Another vote for seeing this sooner than later. It's unfortunate to have an API that advertises "audio" not provide audio after this much time. Looking forward to a milestone update.

Would love to hear the use case of using audio without peerconnection. Since no recording API is yet defined, what is the use case you are thinking of for audio?

A few off the top of my head-
- live performance effects (e.g. guitar amp, vocoder)
- live sound analysis (guitar tuner, graphic equalizer)

Additional use cases I can think of:
- games using audio input (think SingStar, etc.)
- audio recording / note-taking application

OK, so it's more of a pipe the local audio into Web Audio API kind of use cases you are thinking about. Not simple mic access.

We are working on this, but  as I have said in the past, our main focus is people talking to each other via browsers.

That being said, local device access mashed up with web technologies open up amazing possibilities... I'll update the bug once there is something to try out, but I do not expect much to happen in the next few weeks. More likely late summer.

At Spreaker (www.spreaker.com) we would like to replace our Flash-based online deejay console with an HTML5 implementation. We've developed a prototype of an HTML5 deejay console and we've been able to compile an MP3 encoder into native client so that we can broadcast mixed audio with WebSocket.

PeerConnection will be a great feature but our encoder+websocket currently works quite good (at least for the scope of the prototype). The real missing feature is the ability to "inject" the microphone into our audio pipeline/graph (we've tried with a Flash-based bridge but there're big performance issues that seem to be caused by external interface).

Just my cent,
Marco

... Karaoké, speech to text, voice command... And a lot of things.... I don't understand the dificulty you have to expose sound input in a browser ??

As with most things, it is not a question of difficulty, but priority and ressources for our small team.

We'll get there soon and it will rock (pun intented) when we get there, promise :)

/S

Would a (small) cash bounty on this bug have any effect on prioritization or alleviate resource pains?

:-) A ton of testing and feedback when things start landing will be even better than cash... thanks for the offer though, made me smile even though I am at work on a sunday :)

Well, consider me an alpha tester then, and thanks so much for your work!

We offer our testing support too. We could also offer a donation, but I've heard you prefer testers ;)

If I want to know how do this work and try a little implementation. What documentation recommend to do it?

Use cases: client-side FFT analysis, speech recognition

Chromium is open source -- if someone wants to jump into WebKit development and follow the stream recording API, I'd imagine the WebKit upstream will let it through.

For more use-cases, there's a bunch of questions on stackoverflow about it: http://stackoverflow.com/search?q=html5+microphone

A few years ago the Adobe Flash community got together and pressured Adobe to add mic recording capability to Flash with the getmicrophone project: https://twitter.com/#!/getMicrophone , which led Adobe to add the mic recording capability in FP 10.1.

Also, Silverlight supports recording from the mic: http://www.kindohm.com/post/838893081/slaudiocaptureplayback.html

Clearly there's a demand for this functionality.  If it's not added to the browser, developers will continue to be dependent on plugins.

I think it's clear that recording is important for a lot of these audio use cases. Unlike video, where a feedback loop to the <video> element is useful for preview, audio is arguably much less likely to be fed directly back to an <audio> element (except in the cases of things like Web Audio API visualizations/real-time effects). In many cases, we want to do something programatically with saved audio input.

That said, it would be nice to see this worked on in parallel with https://crbug.com/chromium/113676 (http://code.google.com/p/chromium/issues/detail?id=113676) - Implement MediaStreamRecorder.

Although I agree that recording/encoding audio would be a nice addition, I think that's far secondary to audio input access - I would not want to gate audio input support on media stream recording.  If I really needed to, I could hack around the lack of recording via a JavaScriptAudioNode; I can't make up for the lack of audio input access, without a plugin.  And a number of these cases really don't need recording, anyway.

Our team at SoundCloud would love to port our recording feature from Flash to native browser APIs: http://blog.soundcloud.com/2010/12/01/record/
The existing issues prevent us even from having basic microphone recording tests.

I totally agree with the soundcloud developer: the existing issues prevent even from having basic microphone recording tests.

Marco Pracucci (Spreaker)

Inviato da iPhone

Il giorno 16/mag/2012, alle ore 11:34, chromium@googlecode.com ha scritto:

I am working on application for content authoring with voice notes to be recorded to the slides.
Can you please explain the workaround using JavaScriptAudioNode.

INPUT: You could use a flash bridge, something like https://github.com/milani/microphone.js. We tried something similar, but we had performance issues mainly caused by the flash-javascript communication via externalinterface. But, again, you're getting microphone audio from Flash, so common sense suggests to do everything with Flash. Obviously we're here cause we would like to do it from javascript, but it seems it's not a priority for browser developers ;)

OUTPUT: In theory, you can attach a JavaScriptAudioNode as last node of your graph and get all "output" samples. In practice, it's up to you what you do with these samples. You could, for example, encode it and send it to server via WebSocket. Obviously the hard part is encode it, since you don't have anything native yet. We did some experiments with Google Chrome Native Client: it works well, but unfortunatly it's disabled unless your application has been installed from Chrome Store (all other applications requires to enable "native client" flag on about:flags).

Is there anyone that tried other approches or tricks?

Marco

The only trick that I know of on the input side is to keep this thread hot :).

On the output side, I did some experiments with using generic compression algorithms like LZJB as a substitute for a codec.  But they work so poorly I wouldn't recommend the approach.  I think a better idea is to breath new life into the MediaStreamRecorder interface as a means of getting the browser to perform the encoding for us.

Would be also interested in a solution to this issue. Particularly an integration with the Web audio API. I think this can solve most of the issues mentioned here. As far as I understood it already exists in the standard (https://dvcs.w3.org/hg/audio/raw-file/tip/webaudio/specification.html#AudioElementIntegration), but has not yet integrated into Chromium. At least I could not get it working together with a AnalyserNode.

I am very keen to see the ability to grab audio input and manipulate in the browser through Web Audio API. Recording the stream would be nice too. But I understand that that is not really what this thread is about.

Why is the WebRTC server a hack? If you want low-latency distribution, that seems like the ideal way to handle this case.

I agree that a WebRTC server is reasonable. It wasn't the point of my use case. What I would like to do is getting the microphone input and put ti into the graph, so that I can minipulate it before sending to the WebRTC server.

One downside of WebRTC is that it assumes an RTP transport.  So while it may be a good fit for realtime applications, a significant number of applications would prefer more reliable and conventional web transports.  Fixing this bug would be a good step in that direction.

Indeed! There are many applications, including ones that need to operate offline, where having mic input and compression for storage to the file system/transfer to worker threads/etc is important and necessary.

Serge, any updates for us? It's been over 5 months since I first filed this bug and 152 other people also think it would be the bees knees to have this working :)

waiting for this...for about 5 month....

The most frustrating thing for me is that we still have to develop on Flash (with its thousands open bugs and limitations), when with few changes in Google Chrome we could deliver an amazing experience on Spreaker to our users.

Just my cent,
Marco Pracucci
Twitter: @pracucci

The reason this is taking so long is because we are refactoring a large part of the underlying audio code. Our goal is to improve audio across the board for all platforms.

I'll update the bug in 3-4 weeks with progress on both this feature and the audio overhaul.

Now that most people are back from vacation, the work here is moving ahead again.

Great! I'm ready to test.

when ready...please let us know...

THX your work~~~~~

@ser

if <audio> can't play mediastream then is there any way to gather mic sample data ? is there any way to print sample data continues ? what i want to do is mention in sample code.

<body>
<audio id="voice" controls autoplay></audio>
<script>
var audioElement = document.querySelector('#voice');
var video = document.querySelector('#video');

navigator.webkitGetUserMedia('video, audio', function(stream) {
  audioElement.src = window.webkitURL.createObjectURL(stream);

/* Sample code */
    stream.addEventListener('onchange',function(s){
        console.log('audio stream is : '+s);
    });
/* Sample code */

}, function(e) {
  alert('Error');
  console.log(e);
});
</script>
</body>

Our HTML5 RDP also need the raw data from Microphone. That would be perfect if browser can provide some native audio encoder, like Alaw, ULaw, Adpcm, GSM etc.

right now, flash support speex codec，BUT all of html5 DO NOT support it. native codec and bitrate is not support or mentions in W3C draft....

so I am very curious about the getUserMedis(), when I got the LocalMedia... what is the codec? PCM? what is the bitrate?

https://dvcs.w3.org/hg/audio/raw-file/tip/streams/StreamProcessing.html

here is a StreamProcessing Draft...

right now ... Audio Recording API is in CHAOS....as I study..

MediaStreamRecorder probably a better place for this purpose.

Any update on this, have been unable to get microphone access working.

bump, any news on when we can expect a fix for this issue?

bump

any update of this ?

It is being worked on. However, it is a significant amount of work.

Update: https://plus.google.com/u/0/113817074606039822053/posts/SiVn4h5Yf3Q

FYI: Canary now has an about:flag for:
Web Audio Input Mac, Windows, Linux, Chrome OS
Enables live audio input using getUserMedia() and the Web Audio API.

Still work to be done, but you can start playing around!

http://chromium.googlecode.com/svn/trunk/samples/audio/visualizer-live.html

Yes, the following have landed and are in Canary:
http://codereview.chromium.org/10830268/
http://codereview.chromium.org/10916105/
http://codereview.chromium.org/10909185/

For now, this is Mac-only and requires enabling "Web Audio Input" in "about:flags"

Just wondering, why enable the flag on all platforms? Since it is currently only implemented on Mac.

Woot - it works! I built a chromatic guitar tuner -> http://phenomnomnominal.github.com/
Runs in Canary obviously, going straight into the standard microphone of my MBP and it is more accurate that the tuner built into my acoustic. Pretty happy!

[Empty comment from Monorail migration]

Nice work Craig.  I'm trying your sample on Ubuntu Chrome Dev (23.0.1271.1) - I realise that it usually takes a week for Canary to get into Dev channel so I'm almost certainly a bit early.  

The status for me (currently) is that the its grabbing usermedia and mediastreamsource, and is receiving audio data into your onaudioprocess method but I'm getting all zeros in the input[2048] array and therefore 'no peaks' and subsequently no frequency detection.

I'm hoping that in the next week or so your sample will start to work as Canary changes are pushed into dev.  

A couple of console.log() from javascript would be useful to help debugging.  I'm concerned that it might try to grab wrong microphone (I have loads of microphone devices but only one that actually works).

Live input in Web Audio is only supported on OSX right now (in Canary).  We're working on other platforms, but they're not live yet (ha).

Live input in Web Audio is only supported on OSX right now (in Canary).  We're working on other platforms, but they're not live yet (ha).

I'm running Mountain Lion, and I haven't been able to get the tuner to work, either.  I'm trying to do it via the Rocksmith cable, which is pretty much a USB mic that plugs into an electric guitar output.

Did you set the Rocksmith as your default audio input device?

Yeah.  And the device registers when I hit the strings, just no action on the page.  I've also tried just using my onboard laptop mic, and pointing my guitar at it, no go there, either.

I don't have a Rocksmith device (not released in NZ yet) so I have no way of testing it with it - all I know is that it works from the microphone. I tired to get it working through an MBox, but without any luck. This is a small proof of concept that this works for a university project - obviously there's lots of things that still need to be considered! I do hope someone else can get it working though! One thing worth noting though is that microphone input doesn't work from a local file, which is why I ended up putting it on github.

Of course - Anyone may feel free to email me (craigspence0@gmail.com) if it does or doesn't work for you!

Looking forward to a Windows release.

This is an extremely important feature that has wide ranging disruptive economy for Internet communications.  Don't be evil.  Implement this feature, please!

Sorry for the massive chain of emails, everyone!  To followup, I agree that this feature would be an amazing influence in the world.  However, not doing something good is not necessarily the same as being evil.

Please, take your time to ensure the quality of this feature, instead of rushing out things.  Thanks!

Live-audio input (i.e., getUserMedia hooked up with Web Audio) is now supported in latest Chrome Canary (24.0.1288.0) on Windows. The Web Audio Input flag must be enabled and both audio devices (play & rec) must use the same sample rate and channel count. Windows XP is not supported.

Try this demo as an example: http://webaudiodemos.appspot.com/input/index.html

Thanks for the great work, does this mean it will go to Chrome 24 (Stable version) finally? We'll have to schedule our software release accordingly.

If it works well on trunk, a merge request for M23 will be done. If the request is not approved, M24 will contain this feature instead.

To clarify, M25 seems like the most realistic release where we can see it without a flag.

To support live-audio input on Windows, both default audio devices (playout
and recording) must use the same channel configuration and sample rate.
Check Properties->Advanced for your default devices and verify that
settings are the same for both directions.

will this restriction (same sample rate for play and recording device) be removed in final version? I found most of the time, they are not same.

We will do our best to make it as user friendly as possible before
releasing without a flag.

Thanks, its really quick picky with those settings. Any idea when the feature will come out on chrome for android?

Canary for Mac is working great. The same can't be said for the windows version. The same code running on both gives excellent results for Mac, but recordings for windows buzz and hiss. Be great when this is fixed!

Note: same hardware for each OS - so not a hardware problem.

[Comment Deleted]

Can you describe your hardware setup and add a link to the script you are running so we can try to reproduce.

[Comment Deleted]

MacBook Pro
Mac OS X v10.7.4
Intel Core i7

Dell Inspiron N4117
Windows 7 Home Premium
Intel Core i5-2430m
x64 based.

I notice that my previous comment implied that the computing hardware was consistent. What I meant was that the audio capture hardware (external microphone) was the same for both.

Do you experience bad audio using this demo as well http://webaudiodemos.appspot.com/input/index.html?

I have noticed a small issue with Chrome Canary Mac OS 10.6.8.    There are options for all of my input devices, but no matter which one I select it still defaults to using whichever one is defined in System Preferences.

When I select Scarlett 2i2 here and "Internal microphone" is selected in System Preferences / Sound / Input it uses the internal microphone in Chrome.

This was tested using http://webaudiodemos.appspot.com/input/index.html

It is a known limitation that the device selection is ignored. We are working on this issue and the goal is to have full support once released without a flag.

I have an issue with the security settings. It appears that you have to allow the microphone every time you reload the page, or presumably load any other page that uses it. This will be a major problem for the language learning app we want to build, because when a user goes to the next exercise, they will have to re-allow the mic, every single time.
There needs to be an option to allow the mic for the current domain (rather than just the current page) for the current session to stop this hassle.

[Empty comment from Monorail migration]

If the site is hosted by https://, the user will be allowed to remember the use of the microphone.

OK thanks, thats a help. Any idea when that will be implemented, and has a decision been made about http sites? As you probably know, flash lets you remember settings for those etc.

Persistent consent for HTTP sites will not be supported.

RE: Do you experience bad audio using this demo as well http://webaudiodemos.appspot.com/input/index.html?

No I don't. However when I create a javascriptnode, and obtain the channel data, the resulting buffer is very buzzy.

Again this works fine on Mac.

Brendan, I looked at audioProcessing.js and noticed you're using a "JavaScriptAudioNode" with a very low buffer size of 256.  This will not work on Windows:
    jsnode = con.createJavaScriptNode(256,1,1); // We could change this to stereo

I know the Web Audio spec says this is a possible value, in practice these small buffer sizes are not practical for use on the main JavaScript thread.

Please try 1024 or higher and see if that helps

Any changes here with new beta in repository?

With audio recording issues in Pepper Flash in the M23 (http://code.google.com/p/chromium/issues/detail?id=157613), it seems to me that this should be a high priority release. Sure hope this comes to M24.

any news about actually storing the recorded audio?

Does anyone have working code for getUserMedia({audio:true},function(stream) { /* get stream.audioTracks as buffer, byte array, or anything? */ });  I swear I saw blob = createObjectURL(stream); new FileReader().readAsArrayBuffer(blob);  somewhere.  

I just need bytes!!!  :)

I really really want this WebRTC audio only to work.  Does anyone have any idea when that might happen?  I just want to see a simple "Hello World" example.  Something along the lines of 2 PCs with 2 People with 2 Headsets and mics.  All of a sudden "Watson come here . . . " and the rest is history!

When might this be possible?  We were planning development 6 months ago that anticipated this simple task would be working by now.  We had already seen the interactive video/audio working example from the Google folks.

Does anyone have a timeframe of when this simple "Hello World" example might be available?

Henrik, dupe if needed.

I've got this flying on Windows 7 Canary, with a little comet server magic and alot of patience you can read raw PCM data from WebAudioAPI, process it with Speex compiled to javascript with emascripten and bobs your uncle. I integrated a working, low latency version into our HTML5 web conference software in little more than a day.

All the bits are there, as the api matures less 'hacky' ways of doing this will inevitably emerge, but works great for now. Just need widespread browser adoption now :)

[Empty comment from Monorail migration]

I am waiting

nikrofilizm: The requested functionality originally asked for in this thread has been added to Chrome and exists in Canary.

clayrongulick@: The most probable reason why it does not work for you on
Win 7 is that the USB webcam uses a different capture sample rate than your
output device (that's my theory at least). The current implementation of
live-audio on Windows requires that both sides uses the same sample rate.
If possible; try changing  sample rate(s) and ensure that they are the same
in both directions.

Hello,
thank you!

I used not a webcam mic, actually. I have a studio microphone with M-Audio
Fast Track Pro audio card, maybe this will be helpful?

Hello,

I have tried all kind of examples (also http://chromium.googlecode.com/svn/trunk/samples/audio/visualizer-live.html) non of them work on my Chrome 24.0.1312.52 and Chrome Canary 26.0.1382.0 on Win 7. I have successfully added stream and send through peer connection and sound is very good, but the problem I can't analyze the sound using Web Audio API with MediaTrack. I am sure that my mic is working good using WebRTC. Tried on 4 different computers with same specifications and versions. What can be the problem? Thank you!

Can you check what sample rate (and channel configuration) you are using in
both directions and report back?
Thanks.

I am using 2 channel, 16 bit, 44100 Hz [CD Quality] sample rate. For mic and for speaker. Thanks!

не понимаю
 14 Січ. 2013 15:48, <chromium@googlecode.com> напис.

Note that any usage of live-audio input requires that the experimental flag Web Audio Input is enabled (see chrome://flags).

With that enabled, and in combination with identical sample rates for in and out, demos like http://chromium.googlecode.com/svn/trunk/samples/audio/visualizer-live.html should work.

I have already enabled this:

Web Audio Input Mac, Windows, Linux, Chrome OS
Enables live audio input using getUserMedia() and the Web Audio API.

It enables getUserMedia and Web Audio API , so there is no need to enable Web Audio Input separately.

I am really stuck..

The flag does not "enable getUserMedia and Web Audio API", it enables "live audio input using getUserMedia() and the Web Audio API" and that is not the same thing.

Let me check again:

- you are on Windows 7;
- with the Web Auido Input flag enabled;
- and using http://chromium.googlecode.com/svn/trunk/samples/audio/visualizer-live.html

Next, you grant access to the default microphone which is configured to run at the same sample rate as the default output device.

Then what happens?

Nothing happens, no graphic changes on the visualizer even I scream to the mic. Thanks!

Please note that the mic and camera you approve using chrome://settings/content and the Media section is not the one that will be utilized in this demo. Instead, the default microphone will always be used. Just checking to ensure that this is the one you have verified having the same sample rate and channel config as the default output device.

Yes I pick the mic from the list in the Options when Allow/Deny toolbar is comming.

By the way, I can't find any information about my mic and webcamera here: chrome://settings/content , it is only giving security option to ask or deny accessing my webcam and mic.

It is supported in latest Canary but what I am trying to say is that your selection is ignored in combination with live audio input. I.e., the default microphone will always be utilized. All you do with getUserMedia is to allow access to any microphone.

Using same Chrome Canary I have successfully connected with a peer connection to other Chrome browser and the sound can be heard very well, but using the same stream with webkitContext and analyser it is not giving anything. Using the same Chrome Canary and same mic settings I used demo http://chromium.googlecode.com/svn/trunk/samples/audio/visualizer-live.html , nothing happend. So in conclusion, the audio is transmitting within the stream, but it is not taken by web audio api for some reason.

I might be doing a bad job explaining here but what I mean is that the two cases you describe have very few parts in common. Hence saying that #1 works gives no clues to why #2 does not. The live audio part is under a flag and experimental only. That's why there are restrictions on things like sample rate and a non perfect device selection.

Yes I understand that it is experimental, just want to know what should I do to make it work, because the demo is not working on non of my 4 pc with windows 7 and 1 mac.

Can you experiment with another (USB) headset and use that as default
device?

All pc's have different headsets, MacBook have builtin one, other ones are using headsets with audio jacks (not usb).

I have tried Chrome 26.0.1382.0 (Official Build 176602) canary with enable-webaudio-input flag set and can run the demo on my Windows 7 machine. Using a USB headset, 2 channels at 48kHz in both directions.

I am currently unable to say why it does not work for you.

Ok I will continue my investigations and will let you know if I find any problem, let me know also if you remember anything and think it can solve this problem, thanks!

+crogers:

Let me start with an admin issue. This thread is actually about adding support for local rendering in combination with getUserMedia. The issue is solved and marked as fixed in 157142. Any input added here also affects 157142 which can be confusing. To break this dependency, I will mark this issue as Fixed instead and then continue the discussion.

Marked as Fixed. See https://code.google.com/p/chromium/issues/detail?id=157142 for more details.

claytongulick@: I understand your concern and would like to provide a clear answer but feel that Chris Rogers is more suitable since he is the main developer and editor of the Web Audio spec (https://dvcs.w3.org/hg/audio/raw-file/tip/webaudio/specification.html).

henrika: Like claytongulick, I am also trying to get something working through basic webcams on windows 7.  My focus has been widely available webcams I can find at big box retail outlets.  I started with Logitech, but I'll pick up some HP and Microsoft devices today, too.  So far, Logitech C920 works on Mac, but not on Windows, assuming it's set as default (as the thread suggests).  C525 doesn't work on either Mac or Windows, but I'm suspicious of how well the UVC drivers support C525.  C920 doesn't have much in the way of sampling rate (only 32kHz), so given MS default playback, I couldn't match.  C525 was set to 48kHz, both directions.  Also of note, on Windows 7, when I disabled the primary output device, I got aw shucks. From what I can tell, looks like that's where you pull you sample rate. I can feedback my findings on other webcams if you'd like.

This thread is moving forward well -- let's get this working!

The discussion has drifted too much from the original topic (which is now
solved). All input is appreciated but could you (e.g. jason.a@ or
clytongulick@) start a fresh issue report and re-apply the last input? A
more suitable heading could be "Issues with the experimental live-audio
implementation (MediaStreamSource)". It would allow us to provide feedback
that would make sense to more users who search for answers to their
questions.

Thanks.

Thank you.  I have created a fresh issue report, titled as suggested:

https://code.google.com/p/chromium/issues/detail?id=170384

ackise@: please elaborate; exactly which functionality are you waiting for?

*

Gilles,

I assume you are on Windows and rely on Canary. Live-audio has been broken for a while on Windows but it was fixed last Friday and should work in latest Canary.

Please try again and report back.

Try http://webaudiodemos.appspot.com/input/index.html

and ensure that the Web Audio Input flag is enabled.

I'm having the same problem as Gilles.  Seemed to just start happening.  Not working in Canary.  

Should have read above.  Web Audio Input has to be enabled in about:flags.

tsargent@: could you please check which version and platform you are
running using chrome://version.

Chrome version: 24.0.1312.57 (Official Build 178923)
Platform: OS X 10.8.2

henrika@: Chrome version: 24.0.1312.57 (Official Build 178923)
Platform: OS X 10.8.2