Google Glass sales halted - <AUTHOR> http://www.bbc.co.uk/news/technology-30831128 <comment><USER2> Google Glass took a good idea for some contexts and mass marketed it to a completely different context where it's primary feature was mostly useless. HUDs and AR make a ton of sense when you need to augment human knowledge, intelligence, and sensory in real time with voice as the primary user interaction. Flying fighter jets, driving race cars, fighting on a battlefield, working in complex and unsafe industrial operations, etc.

AR doesn't significantly augment your experience of riding the bus to work, ordering dinner at a restaurant, taking a walk around the block, or even most forms of labor (manual or otherwise). So not only did Google Glass not have much of a benefit, but it had the drawback of annoying countless people who had to be around the glasshole who never stopped yapping at their glasses.

<comment><USER3> _> AR doesn't significantly augment your experience of riding the bus to work, ordering dinner at a restaurant, taking a walk around the block, or even most forms of labor (manual or otherwise)._

It could. Riding the bus? It could automatically pull up the bio of a person sitting next to you. Ordering dinner? It could approximate calorie counts of the food on your plate. Taking a walk? It could pull up information about the flora and fauna around you, and the history of the buildings.

AR _could_ be amazing, but the tech isn't there yet. Google Glass reminds me of Apple Newton -- an amazing piece of technology that's a decade or two too early.

<comment><USER4> > Riding the bus? It could automatically pull up the bio of a person sitting > next to you.

Jesus Christ please no. Does anyone really think this is a good idea?

Addendum: of all the people replying to my post, saying how great it could be, I'd be willing to guess that none are in positions where they get harassed on the bus on an almost daily basis (eg being a woman).

<comment><USER5> In Japan I believe it's a legal requirement for cameras to emulate a shutter sound for privacy reasons. I want that, too.

Oh, and I that my consent is required before somebody does face recognition on me.

<comment><USER6> And I want my consent required every time someone who overhears my name digs up my facebook.

It's not even remotely enforceable. For better or worse, this is the future.

<comment><USER5> There is a huge difference there. First of all, I don't have facebook, and I barely use my real name on the internet. So I can defend against that. And second, my name is absolutely not unique and if needed I can adopt other identities. My face is and i can't get a new one.

<comment><USER7> Do you wear a mask when walking down the street? Do you ask people to sign a document if you want them to see your face? There is always a way to abuse anything, and at some point we need to address it on a societal level, and not by blocking technological progress.

<comment><USER5> No, I'm not wearing a mask, and I don't want too, that the whole point. The fact that people do need my consent before they film me, or make anonymous is state of the law in may places.

I don't see how a mandatory shutter sound is blocking "technological progress".

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER8> Google Glass was ahead of its time, for a while. They re-engineered the guts of a cellphone to fit into an eyeglass frame. The visual 'cube' that forms the display was a novelty and kept the project within the bounds of whats possible to be manufactured today.

Then Google came across a _fiber optic eye-ball projector_ that made the Glass visual interface look like an 8-Track of the Doobie Brothers. They immediately realized this and dumped a _half billion dollars_ on the project, Magic Leap.

[http://gizmodo.com/how-magic-leap-is-secretly-creating-a- new...](http://gizmodo.com/how-magic-leap-is-secretly-creating-a-new- alternate-rea-1660441103)

Some day, Google will spring a productized version of this on the public and it'll be like nothing before, including Oculus. Its the best shot we've got at 'true' augmented reality.

<comment><USER9> Google will never bring a Glass-like product to market successfully. Period. They are incapable.

<comment><USER10> You need to elaborate. Adding the term 'Period' doesn't magically strengthen your argument.

Genuinely interested in your rationale though.

</comment></comment></comment><comment><USER11> So some speculation (since we on the outside can never be sure, and when I worked at Google it was always interesting to see the difference between what was reported vs the reality inside the company.)

I've always felt that consumer products were going to be really hard for Google to pull off. It reminded me of Intel trying to make an LED wristwatch in the early 80's. Too much consumer 'hands on', too much industrial design. Neither of which Google are strengths.

I expect glass is dead, all the money they might have invested in making it real they spent on Magic Leap, and now its up to the Leap guys to be the 'visual interface to Google.' The small android experience will fold into the IoT part of Google (Nest) and that will be that.

<comment><USER12> One of the most stinging criticisms I've heard of Google is that they just don't get products. They can, in some cases, do services, but the idea that something ever reaches a finished state in which everything is complete doesn't seem to be part of their DNA.

It's as if they are an eventually consistent system that is constantly moving towards a state of consistency that they never completely reach.

<comment><USER13> _It 's as if they are an eventually consistent system that is constantly moving towards a state of consistency that they never completely reach._

They have some products which were nearly perfect. For instance, the Chromecast is more or less finished. It's not intended to be a game console or something to have apps in on a television. It's an extremely cheap device that allows you to stream a tab or from apps. That vision is well-executed, because it is cheap and works well for streaming. Of course, some people will have gripes about the Chromecast, but the fact that a device that looked incredibly boring at the start is now a pretty big success indicates that for many people it's exactly the product that they want.

<comment><USER14> Due to the fact that the chromecast requires an always-on internet connection it's far from finished and entirely useless in many cases.

<comment><USER15> I think you've confused "finished" with "what Mithaldu wants".

<comment><USER14> "Mithaldu and everyone in his cicles of friends, relatives and work acquaintances."

Maybe it's different where you are, but where i live the chromecast is literally useless due to the restriction and nobody has one.

<comment><USER16> A lot of people live in places where a telescope is literally useless (for astronomical purposes, anyway). Does that make it a worthless product?

<comment><USER17> False analogy. First, the parent didn't state that it was, in ask scenarios, a useless product. S/he said out was useless _where s /he lives_ due to a design decision. Secondly, we can't control the atmosphere, but Google can certainly control the design of the Chromecast.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER18> "calls end to" apparently equals "moved to another division for continued development on different timeline". Linkbaitish title.

<comment><USER19> I don't know, if they were simply reorganizing it, _stopping sales_ , period, seems like a very strange move. Not only does it look like killing to the rest of the world (which to some extent is going to be a self-fulfilling prophecy), it also does a lot of damage to uptake since, well, you can't get one anymore.

<comment><USER20> It isn't weird if the explorer design is being retired. I fully expect them to stop selling the current model.

</comment></comment></comment><comment><USER21> It seems to me that Glass wouldn't have suffered half the backlash it got if the original release had excluded the camera. Even if everybody was just grumbling about how useless the product was without a camera, people still would have bought it, and it probably wouldn't have gotten half the bans or negative press it ended up getting.

<comment><USER22> That's always been the problem with glass; it's not an AR application platform, it's just an awkward mini-screen floating in the middle of your face.

Without a camera it would have been so pointless no one would have bothered to look at it.

(seriously, can you imagine the sky diving demo sans camera? 'What was thing thing on his face?' 'No idea, I think it was showing him tweets or something')

</comment></comment><comment><USER23> If Google wanted to sell it to the world, they should have first made it without the camera. Later on when people are comfortable with the form factor: add the camera.

This is how we have ended up with mobile phones with cameras that nobody seems to mind about. Phones only got cameras halfway through their life. By then, it was too late to stop.

<comment><USER24> I think cameras in phones had a lot to do with the limitations of the tech. Even so, it's a conscious action to hold your phone and take a photo, and while there's plenty of idiots on Reddit that don't care, it's not socially acceptable to take photos of strangers without permission. Everytime I've spoken to someone wearing Glass, I was so paranoid that a photo of my mouth in the wrong pose would be used for someone's karma.

<comment><USER23> It's still not socially acceptable to take photos, but it's a lot more acceptable to carry a camera around with you.

What percentage of drug deals do you estimate _both_ buyer and seller are carrying a phone with a camera? 70%? 90%?

I laugh when I imagine how many movie plots are broken now that _everybody_ has an audio recording device in their pocket.

</comment></comment></comment><comment><USER12> Aside from the mismanagement of the software/hardware associated directly with Google Glass the true problem it had was the contradiction between the benefits of the user and those around the user. The single greatest thing about Glass, and it really was brilliant, was the ability to take pictures that almost perfectly captured your field of vision. This is, however, the precise feature those around you might take objection to. Take that feature away and Glass really has no use at all.

The irony of this is it's not hard to conceal cameras on people in order to record their surroundings if you're so inclined, and the reception to Glass just demonstrated how opposed people are to this when it's a visible intrusion, regardless of the actual threat presented.

<comment><USER25> _The irony of this is it 's not hard to conceal cameras on people_

The idea that something is technically possible but socially unacceptable is not irony. Concealing something socially unacceptable is not ironic. Expressing disapproval of someone openly breaking social norms is not inherently ironic. The idea society runs on trust is not ironic!

<comment><USER26> The person you're responding was clearly just saying that it's funny how uncomfortable people were about being recorded by Google Glass, while covert methods of recording are not difficult but rarely worried about.

Take it easy - we know what was meant. No need to get pedantic about the definition of "irony."

<comment><USER27> >while covert methods of recording are not difficult but rarely worried about.

Unless you're a woman who's ever worn a skirt in public, gone to a gym, or used the changing room in a store.

<comment><USER28> ...or a guy who's used the changing room in as store. What's so different about being a woman in that context?

<comment><USER29> Nothing, in theory. In reality, women are the ones who have to worry about change room cameras. There is definitely a disconnect there.

</comment></comment></comment></comment></comment></comment><comment><USER30> I'm not sure what it means for the future of Glass, but doesn't the title and most of the content of the article undermine that it's being moved to an actual product division?

<comment><USER31> The title is sensational and meant to be clickbait. It does not focus on the fact that by moving Glass to an actual product division, Google is expressing commitment to the ecosystem and the product.

Edit: "Glass at Work has been growing and we're seeing incredible developments with Glass in the workplace. As we look to the road ahead, we realize that we've outgrown the lab and so we're officially "graduating" from Google[x] to be our own team here at Google. We're thrilled to be moving even more from concept to reality." [https://plus.google.com/+GoogleGlass/posts/9uiwXY42tvc](https://plus.google.com/+GoogleGlass/posts/9uiwXY42tvc)

<comment><USER32> ::cough:: [http://ourincrediblejourney.tumblr.com](http://ourincrediblejourney.tumblr.com)

</comment></comment></comment><comment><USER33> I see it as something like Google Wave, a bit before the market is ready for it with a terrible form factor. However the technology and intent is correct.

These things will be back, but they won't be Google Glass, they'll be the "GoPro of Google Glass". Probably single function at first, cool looking, wearable/usable, with modders and hobbyists starting to build out functionality piecemeal until they have something really cool.

And back to that form factor, I'm just a regular guy, and I wouldn't be caught dead in these things. When the visual impression of your product is Robert Scoble wearing them in the shower, you know you're doomed.

</comment><comment><USER34> And by "Glass programme" they mean the Explorers program, not the entirity of Glass itself, which is being moved from Google X to something less R&D-y, in the hands of the Nest CEO.

Probably about time - Glass needs to sink or swim already.

<comment><USER35> It's more specific than that: current versions of Google Glass are dead and are planned to be sunset. So, Glass, as we know it, is dead.

<comment><USER36> This is totally not a surprise regarding the current version of Glass. To paraphrase briefly:

Google Glass = ti OMAP 4430 → Texas Instruments axed the OMAP division → no more (closed source) driver updates → no more easy kernel updates → no more Android/system software updates → end-of-life. ☹

<comment><USER37> Exactly. This is like the G1 being discontinued. It's a product EOL, not a product line being killed.

<comment><USER38> If the G1 had been discontinued at 3 days' notice - and without there being a replacement already on the market - I'd have expected people to have some pretty harsh things to say about the future of Android...

</comment></comment></comment></comment></comment><comment><USER39> If I didn't read this line I would feel that it would be a dead product:

> She and the Glass team will report to Tony Fadell, the chief executive of > the home automation business Nest

It sounds like they're just transitioning the responsibility to an Apple vet who has good taste.

</comment><comment><USER40> I think we place too much emphasis on visuals simply because they're more readily at-hand for the individual user, even when doing so forces _those around that individual_ far outside their comfort zone. It creates a barrier, putting both sides on the defensive, at odds with each other.

Meanwhile, we drastically underestimate the potential utility of non-visual sensory augmentation. For instance, a hidden device providing vibrotactile information could provide far subtler, lower-level cues about the world around us, _even to the point of widening the human experience to nearly limitless novel senses_ [0].

That's the direction I'd love to see us move wearables and technology in general: pervasive, yet unobtrusive.

[0]:[http://www.mase.io/tech/wearables/2014/10/23/wearables/](http://www.mase.io/tech/wearables/2014/10/23/wearables/)

</comment><comment><USER41> The glass team sent this email to Explorers:

[https://news.ycombinator.com/item?id=8895743](https://news.ycombinator.com/item?id=8895743)

tldr; all XE development stopped as of Monday

</comment><comment><USER42> It's the camera.

Google made a _massive_ mistake by bundling the Glass with the camera. Camera is _the_ reason for the backlash and the seriously tainted brand ("glassholes" and such). Of course they couldn't launch it as is. Though I wonder if they learned the lesson or if they will just hold a pause and relaunch it with no hardware changes.

</comment><comment><USER43> So, is this good news or bad news for current Glass owners?

If it was me I think I'd be upset to see that my expensive piece of kit had effectively (if not officially) been end-of-lifed. (if not for Google themselves but almost certainly for any 3rd-party developers.)

But, I suspect some people would like the new exclusivity and perhaps the rare collectibility?

<comment><USER44> Disappointed owner here. I'm a developer, but I'm not going to write software for a product that isn't even for sale. There just won't be enough users, and even if I wrote something that justified the cost of buying it, people couldn't. That said, it was very clear last Android update that Google just isn't capable of supporting the TI chip any more. It was horrendous.

<comment><USER45> Me too. Kinda annoying I paid 1500 to be a beta tester for a product that never properly launched. Explorer ... yeah.

</comment></comment></comment><comment><USER46> I was hoping this would be useful at some point for my daughter, who has low vision.

So I am hoping that augmented vision catches on, in more than just niche categories, so that the hardware can evolve more quickly.

It probably needs to be carefully separated from the recording capability, to work around the "creepy" factor.

</comment><comment><USER47> This is a speculation but I think Google is dropping Glass because they are convinced that Magic Leap will be the winner. We have to wait to see what comes out from Magic Leap.

</comment><comment><USER48> "Instead it will focus on 'future versions of Glass' with work carried out by a different division to before."

Is that division made up of people from Magic Leap by any chance? [http://gizmodo.com/how-magic-leap-is-secretly-creating-a- new...](http://gizmodo.com/how-magic-leap-is-secretly-creating-a-new- alternate-rea-1660441103)

The next step is to project 3D images directly into the eyeballs!

</comment><comment><USER49> not a big surprise, they've all but completely disappeared from sight around S. Another Segway, but I doubt Google were ever serious about Glass, it was a demonstration of Google as committed to being a futuristic hi tech company.

The problem with the product is that people like the compartmentalization of the smartphone, you take it out of your pocket to take a photo, nothing surreptitious. And to be honest, the smartphone just does a lot more. This is going to be the challenge that the Apple Watch will also face, it competes with the smartphone for your attention and has to add enough additional value to justify the product segment.

Meanwhile, it's no big deal, products come and go and some end up with much smaller target customer base, although I suspect Glass is (as Segway was) being considered for a few specific markets but over the coming year or two will just vanish only to be revisited in a decade but with holographic projection (a la R2D2) and streetview-like surround-camera and built in plethora of biometric sensors that all feed into the big post-Singularity GoolgleBrain to provide it's eyes, ears and voice...

</comment><comment><USER50> I bought one for dev purposes, and I was never really convinced about the design (even being a prototype). It looks nice, but it is unbalanced on a side, they could have put an extra battery on the other side, the official blog was just talking about Instagram-like uses (who is that had that horrible idea?) and the screen was not great.

</comment><comment><USER51> augmented reality's first home run will be in the mundane industrial sector where it can be used for training, inventory management, logistics, and any number of other things.

i take this as a cautionary tale of product-market fit. as mark andreessen says, where a market exists and a competent but not visionary startup finds itself, the market will often "pull the product out of the startup."

that obviously didn't happen here. i think it is because glass was both narrative AND product. narrative meaning that glass was supposed to be a transformational product, meant to elevate google from a search company to a product company.

they weren't going to let the product find its market (my thesis: industrial). instead, pushed it to the market they wanted it pushed to (consumer), because it fit a narrative they _wanted_ to be true.

</comment><comment><USER52> Google's Lisa. Maybe I can recoup the cost 20 years down the road as a collectors item.

</comment><comment><USER53> What's a narcissistic douchebag to do for attention, now?

[https://www.facebook.com/RobertScoble/posts/1015157966444465...](https://www.facebook.com/RobertScoble/posts/10151579664444655)

<comment><USER53> "7\. On that note, don't give one to Robert Scoble"

[http://www.ibtimes.co.uk/google-glass-2-0-eight-things- addre...](http://www.ibtimes.co.uk/google-glass-2-0-eight-things-address-if- next-generation-headset-succeed-1483755)

</comment></comment><comment><USER54> From the glass-community forums they are not shutting down and will still support existing warranties etc..... My understanding is that there are some exciting things in store for the platform.

</comment><comment><USER55> i would absolutely love to use my glass at my desk when working. would do wonders to clear away all the apps i'm running for notifications and constantly checking my phone to see if i got a text or missed call from a client while i was in a meeting or drafting an email.. the major prob is the product is heavily focused on google services. if they came out swinging with a mac notifications app and ios app - i would use it all day. but they didnt, it sits in my drawer as something i use for show and tell.

</comment><comment><USER56> Wondering if Google had always expected this and Glass was a long-term strategic move or if this was unexpected and should be considered a blunder.

</comment><comment><USER57> Weren't they building some insane barge in San Francisco and New York to be a consumer showcase for Glass? Guess that's sunk now.

</comment><comment><USER58> Sometimes, technology is simply ahead of its time. Honestly, I don't see a fit for Google Glass in society right now. That will likely change in three or five years, but right now, I feel there needs to be some kind of evolution to where Google Glass is considered "normal." It has already started with wearables - smart watches, fitness bands, etc. But it needs to expand in a more logical way before Glass can be included in that list.

<comment><USER59> > Honestly, I don't see a fit for Google Glass in society right now.

There's a huge fit for Google glass. But there is no _high volume_ huge fit. And Google doesn't care about low-volume as they can't move enough ads across it.

</comment></comment><comment><USER60> Glass should not have been pushed at the cellphone consumer-good fashion- accessory market until they had something swanky that actually looked tasteful on a set of glasses.

At the current price-point? Enterprise would be the only market that would pay $1000 in decent quantities for such a niche device. If they could get it down to $200? It could be great for the GoPro set.

</comment><comment><USER35> Based on what Google's implying with this Glass news, seems it wasn't happy with the product and wants to change course. Now that it's an actual product division and they're killing the current iteration, I'd expect we don't hear _anything_ for a long while until there's something new.

<comment><USER30> I don't understand how moving it from (a highly public) R&D to a product division means that we'll be hearing less.

<comment><USER44> This was sort of a public beta, like GMail. A product division won't show it to anyone until it is done. Maybe even hide it in a fake casing like so many phones.

</comment></comment></comment><comment><USER61> Sales halted of something I could never buy even if I had the money.

</comment><comment><USER62> Wow! Who could have anticipated this? Shocking.

<comment><USER63> Yeah, we were planning apps for it too... Sigh.

</comment></comment><comment><USER64> Disclaimer: I never tried glass. But the actual product screens I saw never seemed to come close to the slick marketing demo they showed with the parachuting guys.

</comment><comment><USER65> The sad thing is, many of the problems which sank this incarnation of Glass would have been fixed by the community if only they'd released the source code.

<comment><USER66> But the biggest problem of all with Glass -- _its affect on other people_ around the Glasshole wearing it -- had nothing to do with source code, of course.

</comment></comment><comment><USER67> Why don't they just pivot . GoPro is not a mainstream product but they are very successful

<comment><USER68> I don't think Google needs to pivot this project to be successful.

</comment></comment><comment><USER69> Google should rename Google Glass to "Googly Eyes".

</comment><comment><USER70> yay! no more glassholes. seriosly though, they should have given them away to every popular actor and musician out there and pay them to use at events and concerts.

</comment><comment><USER71> Thank the lord.

</comment><comment><USER72> Glass doesn't add any value to your life

</comment><comment><USER73> let us rejoice ;)

</comment><comment><USER9> "An update on Google Glass..."

</comment><comment><USER74> So what will Scoble do when his pair breaks? How will he live?

</comment><comment><USER75> I don't know what to say about Google glass, but the women at 3:57 of the BBC video is IDDG, intellectually drop dead gorgeous. Capturing her smile with $1500 glasses would be worth it.

</comment><comment><USER76> One of the largest supermarkets in the UK have just released their own Google Glass app.

[http://www.pcpro.co.uk/wearables/1000284/google-glass-app- la...](http://www.pcpro.co.uk/wearables/1000284/google-glass-app-launched-by- tesco)

Nice timing.

</comment><comment><USER77> I remember when it first came out and developers in my area would kind of gloat over it and being one of the chosen "glass explorers". they would wear it to meetups and brag about the apps they were developing for it.

I'm kind of glad that it flopped in its current form and that those days are over.

</comment><comment><USER78> Not really unexpected, the writing was on the wall.

It's a shame though, Glass hate is coming from the old school, technophobe camp. While it _is_ a clunky, underdesigned, underpowered piece of tech, we should aim for sleeker, more powerful, more useful head-mounted computers… instead for no HMC at all.

<comment><USER2> I'm not anywhere near technophobe but I definitely hate Google Glass. It has less to do with the technology than the type of person that gloms onto it and what it enables them to do. Examples: Talking loudly to oneself in a restaurant/bus, not watching where one is walking, elitist or showoff attitudes, lax attitude toward invasion of privacy, etc.

<comment><USER79> Do you remember when we used to say the same about people with cellphones?

<comment><USER80> >Talking loudly to oneself in a restaurant/bus, not watching where one is walking, elitist or showoff attitudes, lax attitude toward invasion of privacy, etc.

Are you implying that doing these things with a cellphone is now alright?

<comment><USER81> No they're saying that we use to (unfairly) attribute poor social behavior to ALL cell phone users. Then we all got cellphones, found out they're neat, no longer felt "left out" or "inferior" and realized hey it's not the cellphone that make people obnoxious it's obnoxious people that make people obnoxious.</comment></comment></comment></comment></comment>


High Sierra still lags heavily on 2014 Macbooks (and other models) - <AUTHOR> https://www.youtube.com/watch?v=nBCPtcfL_Fs <comment><USER2> I think its interesting that Apple release features which show their own older product in a bad light, compared to newer product. You think that a user- experience person would say "hmm.. lets de-tune the settings on the old GPU and hardware" but I guess in nudge theory terms, if you make the old box crawl but they are a fanboi, the outcome is they buy a new box.

I'm going home to de-tune my two old macs now. Thanks!</comment>


How to Do Engineering Estimation in Product Development Process? - <AUTHOR> https://firstname.lastname@example.com/how-to-do-engineering-estimation-in-product-development-process-c1e892d42015 <comment><USER2> I feel like this form of estimation could be overvaluing estimation. It's an ESTIMATE, and it should be ok if you are wrong to some degree.

There is a continuum of estimate accuracy. If you spend 2 minutes on an estimate you will have a wide error band. The more time you spend, the more accurate you can get.

Let's say there is a task that will take 10 hours. If you spend 2 minutes estimating, you can probably tell it will take between 5 and 15 hours. You could conversely spend 2 hours estimating and conclude that it will take between 8 and 12 hours. But is that improved accuracy worth the time investment?

You should balance accuracy against the value you are getting from it. What decisions are being made from these estimates? What is the cost if you are wrong?

YMMV, but generally speaking in my opinion, if your team is spending 4 hours in a room each sprint "estimating", I think you are wasting time.</comment>


What's Holding OpenOffice Back? - <AUTHOR> http://www.linuxinsider.com/rsstory/63684.html <comment><USER2> The short answer: It's not better. It's basically a clone of MS Office pre-2007, which is what everyone is using anyway. When the time comes to change, it'll be to the next version of Office, which will, by that time, be the standard, and OO.o will still not be /better/.</comment>


Infographic: How the average person uses their mobile phone - <AUTHOR> http://bozzie123.blogspot.com/2011/04/infographic-what-does-bob-think-about.html

<comment><USER2> Why not use the source link?

[http://www.esendex.co.uk/blog/post/what-does-bob-think- about...](http://www.esendex.co.uk/blog/post/what-does-bob-think-aboutmobile- marketing/)

</comment><comment><AUTHOR> because i wanted people who view my blog to see it as well</comment>


Linux debugging tools I love - <AUTHOR> http://jvns.ca/blog/2016/07/03/debugging-tools-i-love/ <comment><USER2> Another great suite of debugging tools not mentioned is Valgrind ( [http://valgrind.org/](http://valgrind.org/) ). The default application (Memcheck) can help find memory leaks and off-by-one errors. Cachegrind/callgrind are great supplements to Perf, and Massif can help get a better perspective on memory usage in your programs.

I feel reckless writing C/C++ code if I can't test it with Memcheck.

<comment><USER3> what's the advantage of using perf over valgrind? I've never really managed to get it working (it hooks into the kernel and inevitable some part of it fails for me) - but maybe I'm missing out on something?

I understand it probably handles mutithreading better and probably has a much better performance - but is that really it?

<comment><USER4> valgrind had a bunch of stuff like massif, callgrind and memcheck but none of them (AFAIK) tell you how long a function call took, and point out the area of code taking too much time, which perf does.

<comment><USER5> Years ago I made a little C++ class for this. You could declare

       {
         tracer tr(function, ...)
         timer ti(tr, milliseconds);

the constructor of the timer would sample and record the time. The destructor would sample the time again, and if it was over the specified milliseconds, it would log a diagnostic into the tracer.

</comment></comment></comment></comment><comment><USER6> Instead of strace, check out sysdig. It's significantly more powerful so long as you're willing to install the associated kernel modules: [http://www.sysdig.org/](http://www.sysdig.org/)

<comment><USER7> There's also LTTng which is more mature and, arguably, more powerful too (and it does userspace tracing as well): [http://lttng.org/](http://lttng.org/)

Full disclaimer: I'm am a contributor to the LTTng project.

<comment><USER6> Thanks, I'll check it out!

</comment></comment></comment><comment><USER8> Can someone experienced with SystemTap or dtrace4linux comment on why these tools aren't more popular among Linux professionals?

I recently had to debug a memory usage issue at work, and SystemTap seemed like it would be a lifesaver in those and many other occasions. Unfortunately, both myself and my coworkers were inexperienced with it and there wasn't much documentation about it online, so we ended up using a standard profiler to track down the issue, which turned out to be a much slower process.

<comment><USER9> It's a complex question. For really advanced environments, advanced tools are in use (including ftrace, BPF, etc). If you mean more widespread usage, then there's the need for documentation, marketing, etc. Linux doesn't really have anyone focused on doing that (ie, marketing departments with large budgets).

</comment></comment><comment><USER10> I made an account to say that the person who writes this blog sounds like a great person.

<comment><USER11> I think Julia is probably the most enthusiastic developer I've ever encountered. Which is quite a statement considering a lot of the subject matter is (IMHO) pretty mundane.

<comment><USER12> Did she do a talk at strange loop about system calls? Her Google interview story was hysterical if it was her

Edit not on mobile now. I was randomly looking through strange loop videos and watched one of her. Her enthusiasm and attitude are infectious. Its so fun to watch her be so excited that she gets tripped up trying to decide which awesome thing to tell you. I saw no picture of her on the website i viewied but surmised from the other comments here. Great video and seemingly an amazing person.

The google interview story is superb to hear if anyone hasn't watched yet.

<comment><USER6> Do you have a link?

<comment><USER13> I gave a talk at strange loop called "you can be a kernel hacker!": [https://www.youtube.com/watch?v=0IQlpFWTFbM](https://www.youtube.com/watch?v=0IQlpFWTFbM)

<comment><USER14> Watching this now. I love it. Thanks for you awesome enthusiasm. I wish every high school kid would watch this. You make programming look so cool :)

</comment></comment></comment></comment></comment></comment><comment><USER15> Taking core dumps, heap dumps and traffic dumps are very powerful ways for debugging. The most powerful tool I have seen lately is rr, the replaying debugger from Mozilla. [http://rr-project.org](http://rr-project.org)

Personally I also like to extract data from logs with UNIX tools and feed them into csv/tsv files, then process them with R.

</comment><comment><USER16> I still love DDD ([https://www.gnu.org/software/ddd/](https://www.gnu.org/software/ddd/)). It's really useful for when you want to see what your code is doing to some area in memory.

</comment><comment><USER17> Julia's posts are always high quality! Keep up the good work.

</comment><comment><USER18> I was introduced to Crash, for actual kernel debugging today, you can dump your data and examine it in very detail.

</comment><comment><USER19> opensnoop -> lsof?

<comment><USER20> lsof shows you what's currently open; opensnoopf shows you what's being opened and closed, live, like a system-wide trace. Much handier if you're trying to figure out "what happened right when the bad thing happened?".

</comment></comment><comment><USER21> Julia is the coolest person.

</comment><comment><USER22> Everyone forgets about ltrace: Like strace, but for calls to dynamic libraries.

It gets you something closer to what the program looks like at the source code level: You get calls to printf (well, __printf_chk on a modern Linux) instead of write, for example. The downside is that ltrace doesn't (and can't) know as much about every single function in every single dynamic library, so, while the names are there, the arguments are typically less convenient to work with and may be incorrect. (For example, it doesn't dereference pointers to print out nice strings, and it might not know how many arguments a function takes.)

<comment><USER23> This is anecdotal, and a number of years ago, but I was using ltrace and it managed to kill the process I had attached to. I think ltrace has to get a little more aggressive with how it extracts data from a process. If it's a situation where data-loss is not allowed, consider the risk.</comment></comment>


Wrong thing to say on Jeopardy - <AUTHOR> http://uk.youtube.com/watch?v=_5H5r4_CoJo&feature=related

<comment><USER2> Please let's not start turning into Digg.</comment>


Which California waters are listed as impaired for fish consumption? - <AUTHOR> https://mywaterquality.ca.gov/safe_to_eat/impaired_waters/index.html <comment><USER2> [https://en.wikipedia.org/wiki/Mercury_contamination_in_Calif...](https://en.wikipedia.org/wiki/Mercury_contamination_in_California_waterways)

<comment><USER3> > Historically, 10-30% of mercury was lost in the mining process, resulting in > widespread contamination of river and lake sediments

That is a LOT! That explains the frequency of red areas on the map. What a shame.

Here in BC it's a similar story with the ocean and dioxins from industrial effluents. You can't harvest shellfish around most of southern Vancouver Island. It seems like everyone has a story of poisoning their own food and water.

<comment><USER4> > That is a LOT! That explains the frequency of red areas on the map.

It seems like most the ones I clicked on weren't polluted by mercury (even if my local sources were). Looking closer, the north seems to be mostly mercury pollution (at least inland), and the south seems to be varying sources (chlordane, dieldrin, PCB, DDT).

<comment><USER3> Ah, okay then. Coincidentally I clicked around and mostly saw mercury and a couple seleniums, so it seemed like mercury was the biggest issue. I wonder what the others are caused by... I'm guessing industrial effluents.

</comment></comment></comment></comment><comment><USER4> That's distressing. My own city's creek system is shown to have Mercury.

<comment><USER2> [https://en.wikipedia.org/wiki/Mercury_contamination_in_Calif...](https://en.wikipedia.org/wiki/Mercury_contamination_in_California_waterways)

</comment></comment><comment><USER5> For what it's worth, not all of these areas are totally unsafe. I am familiar with some of the central valley lakes that are highlighted and I grabbed the current consumption flyer for one: [https://oehha.ca.gov/media/downloads/advisories/millertonlak...](https://oehha.ca.gov/media/downloads/advisories/millertonlakeposter.pdf)

The situation is not great but it's not quite so bad as it might seem if you look at that map and think it indicates only areas where fish are completely unsafe to eat.

</comment><comment><USER6> This is neat (and disturbing), but I don't live in California. Does anyone happen to know of similar sources for other states/regions?

</comment><comment><USER7> It looks like much of the water in the Bay Area is listed as impaired, sadly…

<comment><USER8> So the lake next to my house is NOT 'impaired' in that you can catch and eat fish from it but because of algae they have certain times that are impaired.

They actively stock it and encourage fishing. Not sure why it's listed here but makes me skeptical about the rest of the data as I've only looked at one data point and it was wrong.

<comment><USER9> That map is also 20 years old.

Edit: I looked at the wrong map.

<comment><USER4> Which map? The one the link points to, which notes clearly "( Updated 1/4/19 )"?

<comment><USER9> Oh, good point. I looked at the wrong map. I was looking at the mercury contamination map on the Wiki page; which is based on 1999 data.

</comment></comment></comment></comment></comment><comment><USER10> Scenic LA River isn't listed! Woot! /s

</comment><comment><USER11> WARNING: The State of California contains chemicals known to the State of California to cause cancer and birth defects or other reproductive harm.

</comment><comment><USER12> I'm not sure this map is trustworthy given CA's propensity to label everything under the sun as unsafe. I bought a turning signal to fix my grandpa's boat trailer and it had the famous CA cancer advisory. Crying wolf, man.

How about this: is the turning signal more likely to give you cancer than living with an indoor smoker? Unlikely. And yet living with secondhand smoke is associated with a ~20% increase in risk, i.e. from ~6% lifetime risk to ~7.2% lifetime risk</comment>


'Ventilators' donated by Elon Musk can't be used on coronavirus patients - <AUTHOR> https://news.yahoo.com/ventilators-donated-elon-musk-cant-150000445.html <comment><USER2> Via the LA Times Business writer:

'Although sometimes though not usually referred to as "ventilators" even by professionals, BiPap devices are not the high-end highly desired invasive ventilators that hospitals so desperately need. (GM and Ford have partnered up with ventilator makers to manufacture these.)'

[https://twitter.com/russ1mitchell/status/1245502084243263489](https://twitter.com/russ1mitchell/status/1245502084243263489)

</comment><comment><USER3> Could these machines not be used for the patients without a contagious respiratory infection who need help breathing?

That way the proper ventilators are available to people with covid-19.</comment>


CNC Wire Bending Machine. 3D Wire Forms. 14 Axes - <AUTHOR> https://www.youtube.com/watch?v=f2d6hMTFP9w

<comment><AUTHOR> The machine looks impressive, but to be honest when you break it down all the mechanics appear to be relatively straightforward.</comment>


Salesforce Unveils Tools to Help Companies Safely Reopen Offices - <AUTHOR> https://www.bloomberg.com/news/articles/2020-05-04/salesforce-unveils-tools-to-help-companies-safely-reopen-offices <comment><USER2> So shift scheduling and then it seems to dive into some stuff that looks a bit creepy like contact tracing and the rest of the article reads like a copy and paste from a press release.

</comment><comment><USER3> The full playbook [https://c1.sfdcstatic.com/content/dam/web/en_us/www/document...](https://c1.sfdcstatic.com/content/dam/web/en_us/www/documents/e-books/covid-19-response- playbook.pdf)</comment>


Facebook CEO Mark ZuckerBerg's New $7 Million House [Images] - <AUTHOR> http://itechvision.blogspot.com/2011/05/facebook-ceo-mark-zuckerbergs-new-7.html

<comment><USER2> If I could, i'd live in highly equipped bunker

</comment><comment><USER3> Nice, is it really worth $7 million though?

</comment><comment><USER4> This is really dangerous stuff. Zuck already has a stalker who showed up on his doorstep. Invading his privacy like this actually inspires the crazy folks to invade a little more.

The state of tech journalism is just sad.

Wasting journalism resources that could go to covering innovation and struggling founders given to gawking at manicured lawns.

kill yourself.

<comment><USER5> > This is really dangerous stuff.

It looks like one photo off Google StreetView and the rest off the house's MLS listing. It's all public info.

</comment></comment><comment><USER6> Seems surprisingly modest.

5 bathrooms though? America makes me laugh. Apparently a house isn't worth much over there unless you can take a dump in a different room everyday of the week.

<comment><USER7> I don't know, my little rented three bedroom house in a small midland Ireland town has three bathrooms.

<comment><USER6> You mean an actual bathroom or a room with a toilet and sink in? If it were the latter I would understand but three rooms with an actual bath? In a three bedroom house? That is absurd.

<comment><USER7> One bathroom with a toilet, sink and bath/shower combo, one en-suite bathroom with toilet, sink and shower and one toilet + sink. I guess the technical term (as used by property people) is 2 1/2 bathrooms.

When I was young some friends of mine lived in a house where every bedroom (in a 6 bedroom house) had an en-suite bathroom, plus one additional bathroom. While I certainly don't expect every bedroom to have its own bathroom (or even close to it, really), I don't think its strange for a large house to have multiple bathrooms.

<comment><USER6> Sure, if you have a stately home I could imagine the reason for it. No one wants to walk for 10 minutes to go to the loo in the middle of the night. But a normal 3 - 5 bedroom house does seem a bit ridiculous space wise. Especially as (at least in the south east of England) land is the most expensive part of a building. I could think of much, much, much better uses of the space for my house rather than wasting tens of thousands of pounds worth of space (in land and building fees) on bathrooms.

<comment><USER7> Oh, I agree with you. I think the space could be better utilized in other ways, but I also don't find it terribly strange when it is used for bathrooms.

(For the ten minute walk thing, you just need a tiny toilet+sink room, you dont really need that many showers...)

</comment></comment></comment></comment></comment></comment><comment><USER8> Well there goes the myth that he isn't into material things...

<comment><USER9> Come on now, most people have a huge chunk of their net worth tied up into their homes. He's worth billions (supposedly), so his $7 million house is nothing compared to what he _could_ live in. Also, he's getting old so he needs to stop sleeping on a matress on the floor of a rented apartment. Give the guy a break :D

On the other hand, I reallllly don't see how that house is worth $7mm. It's nice, but not _that_ nice...</comment></comment>


Hiri, the desktop snap that lets you use Microsoft Exchange on Linux - <AUTHOR> https://insights.ubuntu.com/2017/07/18/hiri-the-desktop-snap-that-lets-you-use-microsoft-exchange-on-linux/ <comment><USER2> Funnily enough, I was just looking at this today, while on the search for a new email client.

I have moved to Windows for now, while I have to work with KEIL IDE, so Geary wasn't a option anymore.

Currently using Postbox, as I _need_ Gmail support. The post says 90% accounts use Outlook, but for me, both my school and university have used Gmail servers.</comment>


I don't know who the Web Audio API is designed for - <AUTHOR> http://blog.mecheye.net/2017/09/i-dont-know-who-the-web-audio-api-is-designed-for/ <comment><USER2> I've spent quite a lot of time working with the Web Audio API, and I strongly agree with the author.

I got pretty deep into building a modular synthesis environment using it ([https://github.com/rsimmons/plinth](https://github.com/rsimmons/plinth)) before deciding that working within the constraints of the built-in nodes was ultimately futile.

Even building a well-behaved envelope generator (e.g. that handles retriggering correctly) is extremely tricky with what the API provides. How could such a basic use case have been overlooked? I made a library ([https://github.com/rsimmons/fastidious-envelope- generator](https://github.com/rsimmons/fastidious-envelope-generator)) to solve that problem, but it's silly to have to work around the API for basic use cases.

Ultimately we have to hold out for the AudioWorklet API (which itself seems potentially over-complicated) to finally get the ability to do "raw" output.

<comment><USER3> The API is frustrating because it is meant to hide the fact that Android audio sucks giant hairy donkey balls.

If you give Web developers access to raw samples, they are going to expect it to work. When it doesn't on Chrome on Android, lots of people are going to start complaining and filing bugs.

So, instead of fixing the audio path, they decided to bury its crappiness under a "higher-level" API which has fuzzier latency and can be built with hacks in the audio driver stacks themselves.

<comment><USER4> Android audio is truly terrible for instrument apps. I don't understand how it suffices for things like games. I also don't understand why people even bother to make things like pianos and drum set… The latency is so extreme and inconsistent that even on recent phones they are useless. In contrast, iOS has had excellently playable instruments at least as far back as the iPod Touch 4.

<comment><USER5> Here's an interesting video on this topic back from 2013: [https://youtube.com/watch?v=d3kfEeMZ65c](https://youtube.com/watch?v=d3kfEeMZ65c)

</comment></comment></comment></comment><comment><USER6> My first lesson in this was the Roland MPU-401 MIDI interface. It had a "smart mode" which accepted timestamped buffers. It was great... if you wanted a sequencer with exactly the features it supported, like say only 8 tracks. It was well-intentioned, because PCs of that era were slow.

The MPU-401 also had a "dumb" a.k.a. "UART" mode. You had to do everything yourself... and therefore could do anything. It turned out that early PCs were fast enough -- especially because you could install raw interrupt service routines and DOS didn't get in the way. :)

As a sequencer/DAW creator, you really want the system to give you raw hardware buffers and zero latency -- or as close to that as it can -- and let you build what you need on top.

If a system is far from that, it's understandable and well-meaning to try to compensate with some pre-baked engine/framework. It might even meet some folks' needs. But....

<comment><USER7> IIRC games made pretty good use of MPU-401 intelligent mode to drive the MT-32 module. The first really elaborate game scoring work on the IBM platform came through the MT-32(Sierra picked it up and everyone else followed - it was a good target for composers but in practice most people heard the music on Adlib/SB), so I would consider it successful in that niche.

And on that note, what I _think_ Web Audio tried to be was a drop-in kit for game engines. Getting the full functionality of Unreal into the browser motivated the requirement for audio processing. But the actual implementation was muddled from the start: basic audio playback remains challenging(try to stream a BGM loop instead of load+uncompress and discover to your woe that it's not going to loop gaplessly, even when the codec is designed to allow that.) and my hobby stab at an independent implementation ran out of gas when I tried to get their envelope model working. The spec has a lot of features but not enough detail, and my morale sank further when I looked at how Chrome did it(stateful pasta code). I got something half-working, put it aside and never came back.

OTOH I had also tried Mozilla's system. That was very simple, and I got a synth working in no time at all with decent performance and latency. Optimizing from that point would have been the way to do it, but something in browser vendor politics at that time led to it being dropped.

<comment><USER8> _IIRC games made pretty good use of MPU-401 intelligent mode to drive the MT-32 module_

Very few games used the MPU-401's intelligent mode, actually. Never mind how I know, that was a long time ago...

</comment></comment></comment><comment><USER9> Here's my take on the history here: [http://robert.ocallahan.org/2017/09/some- opinions-on-history...](http://robert.ocallahan.org/2017/09/some-opinions-on- history-of-web-audio.html) From the beginning it was obvious that JS sample processing was important, and I tried hard in the WG to make the Web Audio API to focus on that, but I failed.

<comment><USER10> Back there I followed a bit the discussion and your alternative spec, which was really interesting. If I remember it well, that will take lots of work and you were the only one working to get it implemented on FF. Are there any plans to get back to that? Maybe as an independent API for JS sample processing by workers only, in parallel with WA? Congratulations on your past efforts and thanks in advance for your answers.

<comment><USER9> Audio Worklets are the future of JS audio processing.

</comment></comment></comment><comment><USER11> I have to cast a vote in opposition here.

I've been heavily into procedural audio for a year or two, and have had no big issues with using Web Audio. There are solid libraries that abstract it away (Tone.js and Tuna, e.g.), and since I outgrew them working directly with audio nodes and params has been fine too.

The big caveat is, when I first started I set myself the rule that I would not use script processor nodes. Obviously it would be nice to do everything manually, but for all the reasons in the article they're not good enough, so I set them aside, and everything's been smooth since.

So I feel like the answer to the articles headline is, _today as of this moment_ the Web Audio API is made for anyone who doesn't need script nodes. If you can live within that constraint it'll suit you fine; if not it won't.

(Hopefully audio worklets will change this and it'll be for everyone, but I haven't followed them and don't know how they're shaping up.)

<comment><USER12> If you're a creative mind and you constrain yourselves to the effects available in Web Audio, I'm sure you'll be just at home.

The effects are useful in one setting: hobbyist and toy usage, where you really don't have that many constraints and can play with whatever cool things are around. That said, I'm sure you'd actually get a lot more mileage out of a library of user-made script nodes, rather than whatever the browsers have built for you.

If you're trying to build something production-ready, or port an existing system to the web, most of the fun toys seem like just that: toys.

AudioWorklets don't look like they would improve things for me, but that's a topic for another blog post.

<comment><USER11> I didn't say I was making trivial toy that isn't production ready. :| I just said I'm not using script nodes, and I think that's what TFA boils down to - half of it is about script nodes not being usable and the other half is about sample buffers not being suitable replacements for script nodes.

And obviously not having raw script access isn't a _good_ thing. Nonetheless, the other nodes mostly work as advertised, in my limited experience so far, so the stuff that you'd expect to be able to do with them (e.g. FM/AM synthesis) seems to work pretty well.

> AudioWorklets don't look like they would improve things for me, but that's a > topic for another blog post.

AFAIK worklets are supposed to be script processor nodes that work performantly. They wouldn't solve the sample rate problems mentioned in TFA but apart from that I'd think they should be pretty usable if they someday work as advertised.

<comment><USER13> Agreed that you can do much more than "trivial toys" with the current WAAPI! But you can only do a small part of FM without feedback (unless you're just talking about vibrato as opposed to canonical FM synthesis). Look at the modulation paths (aka algorithms) of original Yamaha FM synths...

</comment></comment></comment></comment><comment><USER14> Stopped reading at: "Something like the DynamicsCompressorNode is practically a joke: basic features from a real compressor are basically missing, and the behavior that is there is underspecified such that I can't even trust it to sound correct between browsers. "

Then if you look into it:

        dictionary DynamicsCompressorOptions : AudioNodeOptions {
                 float attack = 0.003;
                 float knee = 30;
                 float ratio = 12;
                 float release = 0.25;
                 float threshold = -24;

Which are indeed the basics that you need and totally enough for most use cases.

Check out a vintage compressor that has a dozen implementation as VST plugins:

[http://media.uaudio.com/assetlibrary/t/e/teletronix_la2a_car...](http://media.uaudio.com/assetlibrary/t/e/teletronix_la2a_carousel_1_1.jpg)

<comment><USER12> Where's the sidechain input?

<comment><USER14> You can access the reduction property and connect it a gain node of anouther source.

[https://developer.mozilla.org/en- US/docs/Web/API/DynamicsCom...](https://developer.mozilla.org/en- US/docs/Web/API/DynamicsCompressorNode/reduction)

<comment><USER12> That's using the output of the compressor to drive another node. A sidechain compressor has two inputs.

<comment><USER14> I know what sidechain compression is, yes, you need to code a little bit more :)

</comment></comment></comment></comment></comment><comment><USER15> Mozilla had a competing api that just worked with sample buffers. Unfortunately it didn't win the standardization battle.

[https://wiki.mozilla.org/Audio_Data_API](https://wiki.mozilla.org/Audio_Data_API)

<comment><USER16> I always thought some browser vendors who own mobile app stores wouldn't appreciate gamers having access to a distribution channel for great games on their platform that they didn't control. You can't have great games without great sound, so their mucking up the Sound API would be a nice way to stall the emergence.

It's a conspiracy theory, I know. Reality is probably far more boring and depressing. :/

Like the blog poster, I cut my teeth on the Mozilla API, and I was able to get passable sound out of a OPL3 emulator in a week's time. Perhaps Mozilla could convince other browser vendors to adopt their API _in addition to_ Web Audio API?

<comment><USER17> My theory is that Google used it's influence to hinder the API so they could work around the problems with Android's audio stack. They pushed for an API they knew they could get to work on Chrome for Android, rather than fixing Android (which is supposedly improved in 8.0).

<comment><USER9> I doubt that theory. Chris Rogers @ Google drove the Web Audio API design, and he was recently ex Apple's Core Audio team, and probably neither knew nor cared about Android. More history: [http://robert.ocallahan.org/2017/09/some- opinions-on-history...](http://robert.ocallahan.org/2017/09/some-opinions-on- history-of-web-audio.html)

<comment><USER18> Some person working at Google didn't know or care about Android? It doesn't seem all too unlikely that while he personally didn't care, his corporate overlords told him to work within the constraints of Android.

<comment><USER9> Chris Rogers started implementing his API in 2009, about three years before Chrome for Android was first released.

And do you seriously think in 2009 some corporate overlord said to Chris Rogers, "Android is going to be big, and so is Chrome for Android, but we've decided Android will have a crappy audio stack for several years, so you need to design around that"?

<comment><USER18> I didn't know it was in 2009. I don't think it would've been too unlikely if he started it in, say, 2014.

</comment></comment></comment></comment></comment></comment></comment><comment><USER19> I tried making a simple Morse code trainer using the Web Audio API, which seemed perfectly suited to the task, but I ran into two major problems:

1\. Firefox always clicks when starting and stopping each tone. I think that's due to a longstanding Firefox bug and not the Web Audio API. I could _mostly_ elminate the clicks by ramping the gain, but the threshold was different for each computer.

2\. This was the deal-breaker. Every mobile device I tested had such terrible timing in JavaScript (off by tens of milliseconds) that it was impossible to produce reasonably correct-sounding Morse code faster than about 5-8 WPM.

I found these _implementation_ problems more frustrating than the API itself. At this point I'm pretty sure the only way to reliably generate Morse code is to record and play audio samples of each character, which wastes bandwidth and can be done more easily without using the Web Audio API at all.

<comment><USER20> > Firefox always clicks when starting and stopping each tone. I think that's > due to a longstanding Firefox bug and not the Web Audio API. I could mostly > elminate the clicks by ramping the gain, but the threshold was different for > each computer.

You sure it is not due to the sound files you are using not having a normalized start?

<comment><USER19> There were no sound files. I used an oscillator and changed the gain with `setTargetAtTime` to briefly fade in and out. That should prevent any clicking, but in Firefox it required an excessive amount of time.

</comment></comment></comment><comment><USER21> This article focuses on emscripten examples and for good reason! The effort to resolve the differences between OpenAL and Web Audio has been on-going and exacerbated by Web Audio's API churn, deprecations and poor support.

That said, this current pull request on emscripten is a fantastic step forward and I'm very excited to see it's completion: [https://github.com/kripken/emscripten/pull/5367](https://github.com/kripken/emscripten/pull/5367)

<comment><USER22> I'm one of the authors of this PR, and yes, WebAudio's baffling lack of proper consecutive buffer queuing has been no small source of frustration. They seem to have put so much effort into adding effects nodes and other such things, but something as simple as scheduling one sound to play gaplessly after another can't be (easily) done. Requests for such support have been batted aside as unnecessary, which is funny considering where all the effort is going instead.

To do it properly would require just giving up on WebAudio's features completely and doing all the mixing in software via WebAssembly. Honestly though, if you're going to do that, you may as well just compile OpenAL-Soft with emscripten and use that, so I opted to just try to get the best out of WebAudio that I could. Hopefully it's good enough.

</comment></comment><comment><USER23> Plus one for sure.

I put some weekends into trying to build a higher-level abstraction framework of sorts for my own sound art projects on top of Web Audio, and it was full of headaches for similar reasons to those mentioned.

The thing that I put the most work into is mentioned here, the lack of proper native support for tightly (but prospectively dynamically) scripted events, with sample accuracy to prevent glitching.

Through digging and prior work I came to a de facto standard solution using two layers of timers, one in WebAudio (which support sample accuracy but gives you hook to e.g. cancel or reschedule events), and one using coarse but flexible JS timers. Fugly, but it worked. But why is this necessary...!?

There's a ton of potential here, and someone like myself looking to implement interactive "art" or play spaces is desperate for a robust cross-platform web solution, it'd truly be a game-changer...

...so far Web Audio isn't there. :/

Other areas I wrestled with: • buffer management, especially with CORS issues and having to write my own stream support (preloading then freeing buffers in series, to get seamless playback of large resources...) • lack of direction on memory management, particularly, what the application is obligated to do, to release resources and prevent memory leaks • the "disposable buffer" model makes perfect sense from an implementation view but could have easily been made a non-issue for clients. This isn't GL; do us some solids yo.

Will keep watching, and likely, wrestling...

</comment><comment><USER24> I had a discussion on Twitter recently about a possible use case for WebAudio - and that was a sound filters - in pretty much the same way as Instagram popularised image filters for popular consumption.

One thing that really irks me at the moment is the huge variation in sound volume of the increasing plethora of videos in my social media feed. If there was some way we could use a real time WebAudio manipulation on the browser to equalise the volume on all these home made videos, so much the better. Not just volume up/down, but things like real time audio compression to make vocals stand out a little.

Add delay and reverb to talk tracks etc. for podcasts.

EQ filters to reduce white noise on outdoor videos etc. also would be better. People with hearing difficulties in particular ranges, or who suffer from tinnitus etc. would be able to reduce certain frequencies via parametric equalisation.

It would be intriguing to see a podcast service or SoundCloud etc. offer real time audio manipulation, or let you add post processing mastering effects on your audio productions before releasing them in the wild.

</comment><comment><USER25> Curiously, reading through Web Audio API bug tracker find items such as [https://github.com/WebAudio/web-audio- api/issues/1305](https://github.com/WebAudio/web-audio-api/issues/1305) and [https://github.com/WebAudio/web-audio- api/issues/938](https://github.com/WebAudio/web-audio-api/issues/938), that echo the point from the article quite well. Oh dear..

<comment><USER26> The huge set of deficiencies in this API were communicated to the designers from the very beginning, and unfortunately most of them went unresolved for a long time (or indefinitely). It's a real bummer.

For a while there was a huge footgun that made it easy to synchronously decode entire mp3 files _on the ui thread_ by accident. Oops (:

Even better, for a while there was no straightforward way to pause playback of a buffer. It took a while for the spec people to come around on that one, because they insisted it wasn't necessary.

</comment></comment><comment><USER27> I'm running a SaaS built on the back of the Web Audio + WebRTC apis. While it isn't perfect at all, it is still pretty impressive what progress has been made in the last few years allowing you to do all kinds of audio synthesis and processing right in the browser. It seems to me that it is a pretty general purpose api in intent. The approach seems to be to do the easy low hanging fruit first and then get to the more complicated things. This doesn't satisfy any single use case quickly but progress is steady. No doubt it would be nice if it was totally capable out of the gate but I'm simply happy that even the existing capabilities are there. Be patient, it will improve vastly over time.

EDIT: I should also add that the teams behind the apis are quite responsive. You can make an impact in the direction of development simply by making your needs/desires known.

<comment><USER28> "Record in Lossless WAV" as feature #2 made me smile. Success to you with your SaaS!

<comment><USER27> Thank you ;)

</comment></comment></comment><comment><USER24> I worked on a (now abandoned) project a while back using Web Audio API, but it was NOT for Audio at all - in fact, it was to build a cross platform MIDI controller for a guitar effects controller.

As someone mentioned elsewhere on this thread Android suffered from a crappy Audio/MIDI library. iOS's CoreMIDI was great, but not transportable outside of iOS/OSX. Web Audio API's MIDI control seemed a great way to go - just build a cross platform interface using Electron App and use the underlying WebAudio to fire off MIDI messages.

Unfortunately, at the time of developing the project, WebAudio's MIDI SYSEX spec was still too fluid or not completely defined, so I had trouble sending/reading SYSEX messages via the API, and thus shelved the project for another day.

<comment><USER29> I think I know what you mean, but in my mind, MIDI is very much Audio.

<comment><USER30> It's more about expressing events in time than audio necessarily... Sometimes it's used just to keep other devices in sync with a tempo, sometimes it's used to control lights, and -sometimes- it tells an actual audio synthesizer when to start and stop making noise.

</comment></comment></comment><comment><USER31> > "16 bits is enough for everybody"

Not really, the full range of human hearing is over 120db. Getting to 120db within 16 bits requires tricks like noise shaping. Otherwise, simple rounding at 16 bits gives about 80db and horrible sounding artifacts around quiet parts.

It's even more complicated in audio production, where 16 bits just doesn't provide enough room for post-production editing.

This is why the API is floating-point. Things like noise shaping need to be encapsulated within the API, or handled at the DAC if it's a high-quality one. (Edit) There's nothing wrong with consumer-grade DACs that are limited to about 80-90db of dynamic range; but the API shouldn't force that limitation on the entire world.

<comment><USER12> In the same vein, sure, the audio production nodes should use floating point, but for simple playback, which I'd argue is the 90% case, it shouldn't require me to use floats. Real-time audio toolkits like fmod and wwise all work in fixed-point formats on device, because the cost of floats is too expensive for realtime audio.

The floats are only required if you have a complex audio graph -- with a sample-based API, you can totally do the production in floats, and then have a final mix pass which does the render to an Int16Array. All in JavaScript.

<comment><USER31> > because the cost of floats is too expensive for realtime audio

Round(Sample * 32767) is really that slow?

If you're doing integer DSP, you still need to deal with 16 -> 24, or 24 -> 16 overhead; and then the DAC still is converting to its own internal resolution. (Granted, 16 <-> 24 can be simple bit shifting if aliasing is acceptable.)

</comment></comment></comment><comment><USER32> I once attempted to do RS232 decoding in WebAudio (A speedstack timer of mine does RS232 over aux) and faced these exact issues before giving up.

</comment><comment><USER33> Isn't Web Audio based off of MacOS'x Audio API?

I think the whole point is that Javascript used to be slow, and using the CPU as a DSP to process samples prevents acceleration. Seems to me what is needed is like "audio shaders" equivalent to compute/pixel shaders, that you farm off to OpenAL-like API which can be compiled to run on native HW.

Even if you grant emscripten produces reasonable code, it's still bloated, and less efficient on mobile devices than leveraging OS level DSP capability.

<comment><USER34> _Isn 't Web Audio based off of MacOS'x Audio API?_

I hadn't heard that, but some of the "processor node" stuff does sound familiar.

What OS X _also_ has, though, is proper low-level low-latency sound APIs. And that's why there are so many Mac (and iOS) music apps.

<comment><USER26> It is more or less based on OS X audio, yes. The author of the Web Audio spec previously was an architect on Core Audio at Apple. He basically moved over to Google, implemented his chosen subset of Core Audio in webkit, and shipped it prefixed. Then the evangelism group got big players like Rovio to ship apps that depended on the half-baked prefixed API so it was the de-facto standard for game SFX on the web.

<comment><USER34> Interesting! It's surprising to me that Apple (or Google?) is behind such a poor API, after Apple did such a good job with both Canvas and CSS animation.

</comment></comment></comment></comment><comment><USER35> How to play a sine wave:

      const audioContext = new AudioContext();
      const osc = audioContext.createOscillator();
      osc.frequency.value = 440;
      osc.connect(audioContext.destination);
      osc.start();

"BufferSourceNode" is intended to play back samples like a sampler would. The method the author proposes of creating buffers one after the other is a bizarre solution.

<comment><USER12> I picked a 440Hz sine wave because I didn't want to write a more complex demo example, knowing full well someone would nitpick this.

Please use your imagination and try to imagine one of infinitely many other streams that I could make at runtime that are not easily made with the built- in toy oscillators.

<comment><USER35> It's a higher level API and you're deliberately ignoring all of its higher level features and concentrating on the part that clearly is underdeveloped. Maybe you should use your imagination instead of putting a square peg in a round hole?

<comment><USER12> > It's a higher level API

As the title of the post asks: "I don't know who the Web Audio API is designed for".

The high-level nodes are not featureful enough for professional audio production, and too slow and underspecified for game engines like FMOD / Wwise.

The low-level bits fall somewhere between impractical, deprecated, and useless.

Who is it designed for?

<comment><USER35> I think you're missing the point entirely. It's like a modular synthesiser. It's not "serious business" but this is the browser after all.

Plug a few oscillators into each other and you have an FM synth. Feed delays into each other, etc, etc. You can do that in a few lines of code with no dependencies.

To me, that's a huge potential audience.

If you want a array of samples and depend on dozens of JS libs for functionality, well, I'm sure the AudioWorkers will catch up eventually.

<comment><USER12> So, the answer to "Who is the Web Audio API designed for", according to you, appears to be "people who want primitive FM synthesizers".

Not game developers, not professional audio production people. It's... not an answer I was expecting, but I suppose it's valid.

<comment><USER36> Talk about damning with faint praise.

</comment></comment></comment></comment></comment></comment></comment><comment><USER37> Just from skimming the spec, the AudioWorklet interface looks very close to what is needed to build sensible, performant frameworks for audio profs and game designers.

So the most important question is: why isn't this interface implemented in any browser yet?

That a BufferSourceNode cannot be abused to generate precision oscillators isn't very enlightening.

<comment><USER2> It's been under development for a very long time in Chromium: [https://bugs.chromium.org/p/chromium/issues/detail?id=469639](https://bugs.chromium.org/p/chromium/issues/detail?id=469639)

I think there were some false starts where previous specs were written and then found to have issues.

<comment><USER26> For bonus points, prep work done for the eventual rollout of AudioWorklet in Chromium shipped a bug to release channel Chrome that breaks all uses of Web Audio. The bug wasn't caught in beta/canary channels because it only affects some user machines, and they can't revert the bug because of architectural dependencies. A basic way to summarize it is that AudioWorklet required the threading structure of Web Audio to change for safety reasons, and this results in a sort of priority inversion that can cause audio mixing to fall behind forever. Even simple test cases where you play a single looping sound buffer will glitch out repeatedly as a result.

So basically, Web Audio is unusable in release Chrome on a measurable subset of user machines, for multiple releases (until the fix makes it out), all because of AudioWorklet. Which isn't available yet.

I am being a little unfair here, because this bug isn't really the fault of any of the people doing the AudioWorklet work. But it sucks, and the blame for this horrible situation lies largely with the people who designed WebAudio initially. :(

<comment><USER37> > But it sucks, and the blame for this horrible situation lies largely with > the people who designed WebAudio initially

Just skimming it a bit, it seems like they tried to make the same kind of "managed" framework for an audio graph that SVG spec does for vector graphics. And even if SVGs are janky the static image still succeeds in serving a purpose. But if you get dropouts or high latency in audio, there isn't much more it can be used for. (Aside from browser fingerprinting :)

</comment></comment></comment></comment><comment><USER38> >> Can the ridiculous overeagerness of Web Audio be reversed? Can we bring back a simple "play audio" API

To be frank, graphics world had some type of standard (OpenGL) long time ago, next to DirectX. So WebGL had a good example. However in the audio world we haven't seen a cross platform quasi-standard spec covering Mac, Linux and Windows. So IMHO, non-web audio lacks also common standards for mixing, sound engineering, music-making. That's why web audio appears to lack a use case. IMHO, that smells opportunity.

I use Web Audio, in canvas-WebGL based games where music making is needed. I understand the issues - we definitely need more than "play" functionality.

<comment><USER39> Whether the API could be used to play MOD files is a good litmus test of its suitability for a variety of purposes. Covers repeatedly playing samples at differing volumes and pitches, simultaneously.

I'd rather have a comprehensive API that someone can dumb down than one that's so crippled as to be unusable beyond very basic functionality.

<comment><USER40> A FastTracker 2 player was discussed on HN quite some time ago (spoiler: uses ScriptProcessorNode): [https://news.ycombinator.com/item?id=10538791](https://news.ycombinator.com/item?id=10538791)

</comment></comment></comment><comment><USER41> So it sounds like the web audio API is every good at modeling audio as the web GUI API is at modeling GUIs.

</comment><comment><USER42> I think things will get a lot better when the underlying enabling technology is in good shape. The audio engine needs to be running in a real-time thread, with all communication with the rest of the world in nonblocking IO. There are lots of ways to do this, but one appealing path is to expose threading and atomics in wasm; then the techniques can be used for lots of things, not just audio. Another possibility is to implement Worker.postMessage() in a nonblocking way. None of this is easy, and will take time.

If we _had_ gone with the Audio Data API, it wouldn't have been satisfying, because the web platform's compute engine simply could not meet the requirement of reliably delivering audio samples on schedule. Fortunately, that is in the process of changing.

Given these constraints, the complexity of building a signal processing graph (with the signal path happening entirely in native code) is justified, if those signal processing units are actually useful. I don't think we've seen the evidence for that.

I'd personally be happy with a much simpler approach based on running wasm in a real-time thread, and removing (or at least deprecating) the in-built behavior. It's very hard to specify the behavior of something like DynamicsCompressorNode precisely enough that people can count on consistent behavior across browsers. To me, that's a sign perhaps it shouldn't be in the spec.

Disclaimer: I've worked on some of this stuff, and have been playing with a port of my DX7 emulator to emscripten. Opinions are my own and not that of my employer.

<comment><USER12> > If we had gone with the Audio Data API, it wouldn't have been satisfying, > because the web platform's compute engine simply could not meet the > requirement of reliably delivering audio samples on schedule.

1\. I'm not convinced this is the case. From what I see, GC pauses constitute the big blockers, rather than event processing and repaints. Introducing an API that's friendlier to GC would be a huge win here.

2\. We have WebWorkers. What would have prevented a WebWorker from calling new global.Audio() for the Audio Data API?

<comment><USER42> 1\. This is going to depend a lot on the app; doing an actual DAW is going to require some pretty heavy processing. It also depends on the performance goal. Truly pro audio would be a 10ms end-to-end latency, which is extremely unforgiving.

2\. Some form of WebWorker is obviously where we're going. But does postMessage() have the potential to cause delay in the worker that receives it? (There are ways to solve this but it requires some pretty heavy engineering)

</comment></comment></comment><comment><USER43> For reference : [https://www.audiotool.com/app](https://www.audiotool.com/app) ( using Flash ).

You just can't do that with the same level of tightness of rhythm on low hardware with web techs today. Flash was bad yet Flash also opened up insane possibilities on the web when it comes to multimedia applications that just can't be matched with Webtechs. ASM.js might fill the gap, but i haven't seen any equivalent yet.

</comment><comment><USER44> I briefly tried Web Audio to implement a Karplus-Strong synthesizer (about the simplest thing in audio synthesis I guess?).

Without using ScriptProcessorNode, there was no way of tuning the synthesizer because of the limitation that any loop in the audio graph has a 128 samples delay at least.

Maybe a more "compilation-oriented" handling of the audio graphs (at the user's choice) could help overcome this?

</comment><comment><USER45> Are there any good audio APIs out there?

Video AND audio? They good you all covered with nice APIs!

Just audio? You're screwed!

<comment><USER46> Audio always seems to be neglected and underfunded, compared with video. BeOS seems like one of the ones that did it right.

</comment></comment><comment><USER47> Now step back and honestly think about which web API is actually powerful and nice to use and makes the impression that it has been carefully crafted by a domain expert.

I cannot think of one.

</comment><comment><USER48> Question: is the "point" of Web Audio to expose the native hardware- accelerated functionality of the underlying audio controller, through a combination of the OS audio driver + shims? Or is it more an attempt to implement everything in userspace, in a way equivalent to any random C++ DSP graph library? I've always thought it was the former.

<comment><USER12> Most consumer-grade audio hardware really only does playback. We've been doing software audio since around the turn of the century.

In Chrome's implementation, none of the mixing, DSP, etc. go through the hardware, and I'm more than certain that's the case for every other browser out there.

<comment><USER48> Audio controllers do at least do hardware-accelerated _decoding_ of audio streams in e.g. H.264, though, yes?

But my question was more like: is Web Audio a mess mostly because it's an attempt to _expose_ the features of the twenty-odd different OS audio backends on Windows/Mac/Linux, where the odd inclusions and exclusions map to the things that all the OS audio backends happen to share that Chrome can then expose?

<comment><USER2> > is Web Audio a mess mostly because it's an attempt to expose the features of > the twenty-odd different OS audio backends

That is a good guess, but no. The main features of the Web Audio API (built-in nodes, etc.) are not backed by any kind of OS-level backend, it's all implemented in software in the browser. The spec design was based on what someone thought were useful units of audio processing. It's not a wrapping/adaptation of some pre-existing functionality.

</comment></comment></comment></comment><comment><USER49> Web api standardization for VR/AR is _currently_ a work in progress. And it's been... less than pretty.

So if you've been wanting to try some intervention to make web standards less poor, or just want to observe how they end up the way they do, here's an opportunity.

</comment><comment><USER50> >you can't directly draw DOM elements to a canvas without awkwardly porting it to an SVG

This is not a wart, this is a security feature. Of course, it wouldn't be a necessary limitation if the web wasn't so complicated, but the web is complicated.

<comment><USER12> What's the security issue in play here?

<comment><USER50> Just one example. The canvas API can grab the image data on the canvas. If you could rasterize arbitrary DOM nodes then you could very easily fingerprint users by, say, checking which fonts are installed. You could also load external resources such as images and iframes bypassing same-origin policy, so if your bank's website was configured incorrectly, a malicious site could steal information by taking screenshots of a canvas.

<comment><USER12> You can already draw non-same-origin images to the canvas using drawImage. This marks a special "origin-clean" flag which is checked when someone tries to call toDataURI or getImageData on the canvas [0] I would be OK if drawing any DOM node to the canvas cleared the origin-clean flag.

[0] [https://html.spec.whatwg.org/multipage/canvas.html](https://html.spec.whatwg.org/multipage/canvas.html)

</comment></comment></comment></comment><comment><USER51> Kinda tagential to the thread, but what's the best book for an introduction to audio programming for an experienced, language agnostic coder (java, c, c++, obj-c, etc)?

<comment><USER52> I'm not sure about "best", but I got a lot out of Will Pirkle's two books on programming synthesizer / effect plugins ([http://www.willpirkle.com/about/books/](http://www.willpirkle.com/about/books/)).

For a more generic guide I've heard a lot of good things about a free (in electronic form) book called DSPGuide ([http://dspguide.com/](http://dspguide.com/)). Haven't had a chance to dive into this one, though.

</comment></comment><comment><USER53> > _It [WebGL] gives you raw access to the GPU ..._

Not to be semantic, but that's technically incorrect. Indeed, if WebGL were to be supplanted by a lower-level graphics API, that would make a lot of people happy.[0]

As far as the author's thesis concerning the Web Audio API: I agree that it's a total piece of shit.

[0] [https://news.ycombinator.com/item?id=14930824](https://news.ycombinator.com/item?id=14930824)

<comment><USER53> Not to be _pedantic_ , rather.

I've come to suspect that my phone's autocorrect functionality, HN's two-hour edit window, and my own brain routinely conspire against me to paint a picture of total idiocy.

</comment></comment><comment><USER54> One word: w3c.

I've said it before, I'll say it again: it exists in a vacuum, and is run by people who have never done any significant work on the web, with titles like "Senior Specifications Specialist". Huge chunks of their work is hugely theoretical (note: not academical, just theoretical) and have no bearing on the real world.

<comment><USER55> The Web Audio API was the work of the Chrome team, not the W3C in isolation. I'm right there with you as far as W3C criticism is concerned, but they don't deserve the blame in this case.

<comment><USER9> It was really the work of Chris Rogers. If more core Chrome people had been involved, I suspect things would have worked out better.

</comment></comment></comment><comment><USER56> I disagree with a lot of the assertions in this blog. You have to suspend some of your expectations since this is all .js. you can't have a js loop feeding single samples to a buffer. Js isn't deterministic to that level of granularity, but overall it's fast enough to generate procedural audio in chunks if you manage the timing. If you check out some of the three.js 3d audio demos you can see some pretty cool stuff being done with all those crazy nodes the auThor is decrying. He'll I wrote a tron game and did the audio using audio node chains and managed to get something really close to the real tron cycle sounds, without resorting to sample level tweaking.. and with > 16 bikes emitting procedural audio.. I think more focus on the strengths than weaknesses is in order.. and if you really want to peg your cpu.. you can still use emscripten/webasm or similar to generate buffers, if that's your thing..

<comment><USER12> > Js isn't deterministic to that level of granularity

Why not? I linked a test app [0] in my post that generates generate PCM data on demand, and fast. It works deterministically on all the browsers. Mozilla certainly implemented AudioData back in 2011 and it was fast enough for them.

> He'll I wrote a tron game and did the audio using audio node chains and > managed to get something really close to the real tron cycle sounds, without > resorting to sample level tweaking

Why couldn't this be a high-level userspace library like three.js? Yes, with a lot of creative energy, you can recreate a lot of sounds, I'm willing to believe that. But I think a low-level API would have been more useful from the getgo.

[0] [http://magcius.github.io/spc.js/spc.html](http://magcius.github.io/spc.js/spc.html)

</comment></comment><comment><USER57> Web audio can be used with this: [https://wavesurfer- js.org/](https://wavesurfer-js.org/)

<comment><USER58> I'm not making the connection between the link and the point you're trying to make. Can you elaborate?

<comment><USER57> I was expressing my excitement over something neat which implicitly answers the query in the title that it was designed for me. People who think wave analysis is neat. There are at least 3 other posts on here describing the basic features of wave analysis are just fine. Thanks for the down votes!

</comment></comment></comment><comment><USER59> The font on this page is insanely thin on my browser (Chrome, OS X).

</comment><comment><USER60> The major problem of this API is that they couldn't just copy something designed by people with actual knowledge, as in WebGL. So it was design by committee that does so much the application should handle but has so deficient core capabilities no application can rectify any of it.

<comment><USER61> Nope. Web Audio was designed almost entirely by a single person, Chris Rogers, an engineer with a long history of working on audio for Google, Apple and Macromedia[1]. Whatever Web Audio's problems, design-by-committee is not their cause.

[1] [https://www.linkedin.com/in/diagonal/](https://www.linkedin.com/in/diagonal/)

<comment><USER3> > Web Audio was designed almost entirely by a single person, Chris Rogers, an > engineer with a long history of working on audio for Google, Apple and > Macromedia[1].

Who at Apple beat him with a stick to get audio right? Can we get that person to design the audio API's for the Web and Android?

(Edit: I realized that this was an unfair comment born of my frustration with Audio APIs from Google.

The real issue driving this is that audio is _still_ a dumpster fire on Android. So, if he gives web developers access to audio samples, everybody is going to expect it to work. And, on Android, it will fail miserably. So, better to isolate audio functions, give them "fuzzy" latency which you can bury in C code drivers, and hide the fact that audio on Android is a flaming pile of poo rather than piss off even more developers and get even more bugs filed against Android's shitty audio.)

</comment></comment></comment><comment><USER62> The Web Audio API is designed for web developers who would want to integrate sound into their web apps. Notifications, etc.

That pre-browser era where we would have sounds for everything. Minimize window, user logged in, logged out, all that crap.

Also the API has good support for visual. Spectrum analysis. This is pretty good for an education course to offer for beginners on sound processing.

I wouldn't use it for anything serious like a DAW.

<comment><USER26> This explanation doesn't fit, because <audio> already solved all the scenarios you're describing. Web Audio attempts to solve other problems, and does a bad job of it.

<comment><USER62> Yes, Audio does work. But the Web Audio API has some things more to offer for the simpler stuff. Simple games, timing, effects, detune, etc.</comment></comment></comment>


Plan Would Let Transgender People Serve Openly in Military - <AUTHOR> http://www.nytimes.com/2015/07/14/us/pentagon-plan-would-let-transgender-people-serve-openly.html

<comment><USER2> I'm pretty shocked by the comments. I was expecting that the majority would be in favor of such an obvious move.

Yet, I had to scroll 3 pages till I found a positive comment. It's sad to think that officials from the Pentagon are more forward-thinkers than the readers of the NYT.

<comment><USER3> _" Positive comment"_ \- one that aligns with your opinion? Why not adjust your mental model to reality? Where would common americans express their true opinion if not anonymously in the internet? Sometimes even a slight disagreement with the official agenda might lead to problems with career nowadays.

<comment><USER2> You're right; I shouldn't have said _positive_. That was my own bias, expecting "the truth" to align with my mental model of the world, which is the same critic I was making against the commenters. I take it back.

The word I should have used is _intelligent_ comments.

The amount of vitriol and ignorance is what repulsed me. From people comparing transgenders to be mentally ill, to others saying that " _terrorists will sit back and watch America defeat itself_ ". Reddit/YouTube-level. Very few were able to intelligently argue why they were against accepting transgenders in the military - despite having thousands already in the ranks.

But hey, I should have known better; don't ever read the comments. Not even on NYT.</comment></comment></comment>


Infographic on QR Codes Statistics (JPEG Image) - <AUTHOR> http://digitalbuzz.s3.amazonaws.com/wp-content/uploads/2011/08/Infographic-QR-Codes-Statistics-Hi-Res.jpg <comment><USER2> Do you know from what country does the respondents come from?

<comment><AUTHOR> Sorry, no. Source: [http://www.digitalbuzzblog.com/infographic-how-people-use- qr...](http://www.digitalbuzzblog.com/infographic-how-people-use-qr-codes/)

The title suggests that it could have been an ad hoc study done at the recent Lollapalooza <http://www.lollapalooza.com/></comment></comment>