Waud.js: Web audio library | Hacker News Reader

Waud.js: Web audio library

waudjs.com

77 pointsHalienja24 comments

Nice library. The landing page needs some more work. The "features" section contains just keywords that are not explained. I'd like a sentence explaining each feature: what it does and when/why it is useful. For example, at first I didn't understand what "Auto Mute" meant. That was until I played a sound while I switched to another tab, which made the sound stop. When would one want to use auto mute? To me it felt unnatural/unwanted, almost like a bug. Explain why Web Audio API is used when available. What will not work (if applicable) when using the HTML5 Audio fallback? In what kind of web applications would I want to use Waud.js? Games?

Thanks for the feedback. Will try and improve the home page. Auto mute can be helpful in cases like watching a video in one tab and if you don't want audio from another tab interfering, on devices when you press home button or when you receive a call, playing 2 games in 2 tabs, etc. Just there if you need it. Everything will work exactly the same way whether the browser supports web audio api or not. That's the aim anyway and if it doesn't its a bug. Definitely useful for games and any web apps that needs audio playback.

API docs link is a 404. But I'm looking to try this. Have you worked around with any of the audio playback changes (onlick vs. ontouchend vs onmouseup) in iOS 9/10? I'm curious what "audio unlock" on iOS means.

Fixed API link. Audio playback changes in iOS 9/10 are handled in the library. Tested on various devices including iOS 6 and iOS 10 beta. If you notice any issues please report.

strikingly similar to WAD - https://github.com/rserota/wad

I just wish this would work on mobile.

It was tested on all major mobile devices. If you have any issues on mobile, please report it.

Even recording audio?

Web Audio API is all about playback. The media capture API can tackle recording, and it works on mobile: http://simpl.info/mediacapture/

I thought that only works for video? Wouldn't you want navigator.getUserMedia for audio only?

Right, and on iOS, it just leaves the browser and opens the video recording app.

Unless something has changed, getUserMedia still doesn't work on Chrome/Android or iOS/Safari yet.

I believe you're correct - the state of audio recording on the web via browser is still awful. We are just finishing an investigation at work on my team, and find that we cannot avoid the use of Flash to record for IE/Edge/Safari...our only saving grace is that this app is mainly intended for desktop use.

I wish mobile browser vendors didn't avoid this problem - I get that they're all prioriizing different things, but the state of audio/video recording & playback is abysmal.

Have you checked SoundCloud's implementation?

https://developers.soundcloud.com/docs/api/sdks#recording https://github.com/soundcloud/soundcloud-javascript

I'm not sure if they solve the problem you face but I know they support Audio recording via their Javascript SDK and I thought it might be useful to you.

The documentation cautions you to "make sure to check if the user's browser supports all of it (1, 2, 3) before you start recording." All of it being "getUserMedia, Web Workers and the Web Audio API."

Surprisingly, it DOES look like getUserMedia is supported by Android browser and Android Chrome now (with some weird namespace prefix/object).

http://caniuse.com/#feat=stream

Still doesn't work on anything iOS though (until Apple puts it in Safari).

So no dice for HTML5 on mobile still (I've been waiting since 2012 for some way to support in-browser web-based audio recording, sigh). :|

My only complaint is it is written in Haxe instead of ES6. It would make sense to code it in Haxe if it were to be ported to PHP, C++ and the likes but it appears to be strictly for web audio

I don't want to derail this whole submission talking about haxe, but this is the first time I've really ever looked at it.

It's not like haxe is some kind of crazy offshoot language, it looks pretty damn close to typescript and flow (But to me this looks closer to "regular javascript" than most typescript and flow does).

With the exception of the `@:expose` and `@:keep` stuff, there isn't anything i've seen yet just browsing through the source that I don't understand (as a javascript developer), and i've never seen the language before in my life.

Haxe started out as an improved alternative flash compiler, and ActionScript was once slated to become ECMAScript compliant, so that's probably why it looks very close to "regular javascript". :)

Haxe is much older than TS/Flow: it was created in 2006. It's "unsurprising" by design, but there are advanced topics, like pattern matching or macros (AST metaprogramming), and the fact that you're not limited to targeting JS.

It's not as cool (and backed by big Californian co) as JS/TS, but Haxe really grows on you when you start mastering it.

I'm guessing you've already looked into those keywords, but @:expose and @:keep are Haxe compiler metadata. These are tags that are used to provide additional information to the compiler. A full list is here: https://haxe.org/manual/cr-metadata.html

In many cases, compiler metadata is specific to a given target. E.g., they can be quite common on extern definitions. This allows the Haxe language to stay small, while providing flexibility for better target interoperability.

In this case, @:expose will expose certain methods to the global namespace, and @:keep will prevent the compiler from removing code with its dead code elimination functionality. Both of these are very useful for creating and maintaining js libraries, regardless of whether or not the library is also cross-platform.

This project started as a haxe library for projects targeting javascript http://lib.haxe.org/p/waud and later made it available to wider javascript audience as there is no reason to restrict it to only haxe users.

What is going on, why on earth are we now encoding audio in base64?

It's gone beyond getting angry, now I'm just sad for the state of this whole schlamassel.

The only reason for encoding audio in base64 is to reduce the number of requests which in turn reduces the loading time. It's an alternative to audio sprites. Useful when you have a lot of audio files to load.

Hey Adi the link to API Docs seems broken.

http://www.waudjs.com/docs/

Working link: http://www.waudjs.com/api/

Reply on news.ycombinator.com