Show HN: Jerrica, a 100% scheduled, Web Audio native, MOD player for JavaScript | Hacker News Reader

Show HN: Jerrica, a 100% scheduled, Web Audio native, MOD player for JavaScript

github.com

138 pointsgtrevorjay38 comments

I love the name. Jerrica Benton was the true identity of the rock-star title character of Jem and the Holograms. She had an intelligent computer called Synergy who could put on holographic visual effects, manifest Jerrica's Jem stage persona or other holographic disguises, and had other cyber-powers as the plot demanded. And her archenemy was a ruthless record executive named Eric Raymond.

Fitting name, then, for a JavaScript-based music player program. I love geeky references like this.

Ha. Thanks. Bonus geek/Marvel points if you understand the irony in Jerrica being 100% written on my custom one-handed keyboard named after Ruth Handler.

It's showtime, Synergy!

yesss i was thinking "please let this be a Jem reference" as i was clicking over to github

This is truly outrageous.

I'm using Edge on Windows. If I start playback, then switch to another application window, the player soon starts repeating the last fraction of a second of audio that it played. Then it resumes when I switch back to the Edge window. Presumably this is Edge putting the renderer process to sleep to save power and deal with sites that hog the CPU. The only exception is if I switch to a command prompt (console) window; in that case, the playback keeps going. Anyone know what's going on there?

In case this is the first you've heard of "100% scheduled" and "web audio native":

> By "100% scheduled" we mean that all the timing of audio events is handled using the web audio scheduler. Jerrica doesn't use setTimeout, setInterval, or other timing hacks. It is recommended that its processMusic function is called once per frame via requestAnimationFrame, but that's simply to ensure that sound events are always scheduled well ahead of when they need to occur.

> By "web audio native" we mean that all audio effects are achieved via the web audio API. Many audio players manipulate audio at the sample level, treating web audio as a "dumb pipe" for an audio buffer. Jerrica doesn't do that. After loading the samples from the MOD file, Jerrica only ever uses web audio functions to manipulate the sounds, for example via the playbackRate AudioParam.

To the author's credit, these are both explained near the top of the README. Cheers.

Now -this- is cool http://uploads.ungrounded.net/tmp/1951000/1951512/file/alter...

the numbers are tracker sequences and bars if anybody's wondering.

Very cool indeed! But the canvas really needs `image-rendering: pixelated;` Otherwise it is very blurry on my 4k monitor. (Probably also improves performance?)

Huh, this domain is blocked on my corporate network as something about NSFW content.

Just mentioning for others to be aware of, so you don't get dinged by the corporate filter bots. I pulled up this page on my phone and there was nothing NSFW in the slightest. But must be the ungrounded.net hosts other things that have made it show up on block lists.

Looks like it's hosting files for Newgrounds, so not terribly surprising that it's blocked by a corporate filter.

Didn't think I'd be adding criteria to my resume this late in the game, but what the heck.

Nice! "A Final Hyperbase" by Firefox and Tip was made for the Amiga demo Enigma by Phenomena, which was released in 1991. Oh man, the nostalgia :)

This is how it sounds on a video grab from an Amiga:

https://youtu.be/iGpU3DicbLQ

Sounds quite different from the demo ...

Same notes, but somehow still very different.

That’s really cool! But let’s have a technical discussion about the hiccups some commenters mention.

I’ve experimented with Web Audio stuff in the past, and wasn’t happy with it. It seems to be mainly intended to play back premade music files, not seamlessly playing dynamically generated samples.

Normal audio APIs issue a callback whenever their buffer gets low. This is done in a high-priority thread and has a high chance to work seamlessly even on a very busy system — think computer games. You get called, generate a few more bytes and everything is fine.

Web Audio, unless something changed, requires you to actively, manually schedule sending little audio snippets to the playback queue. You have to use timers for that, which are nondeterministic, and you’re competing with everything else that the JavaScript thread is doing. Any tiny hiccup is an audible artifact, and I had found no completely reliable way to avoid them.

Why is Web Audio like this? Are improvements on the horizon that would make this better?

> Normal audio APIs issue a callback whenever their buffer gets low. This is done in a high-priority thread

Web audio used to do exactly that, and it was abused as a way to get a high priority thread for processing other stuff... So it was removed from the standard...

I recently made a little tool for grabbing and searching mod music from the modland database - https://github.com/Hezkore/Modget

This does some very wonky things in chromium based browsers if you switch to a different tab while it's playing.

It plays normal audio for about 3 seconds, then begins what seems like a very short loop of the last few notes - repeating the same sounds forever (or until you navigate back to the tab)

In a real app you'd definitely want to mute based on losing focus.

I wonder if this is due to how background tab javascript execution is restricted when not in focus

Same in Safari. It's pretty cool actually. In the demo, it does as you say when you switch tabs: plays a few more notes in the right channel, then holds the left in a loop of the last sample.

My guess is that track.processMusic(); isn't being called unless the tab is visible.

Sounds a lot different in firefox and chrome. Not bad in either but don't know what the more accurate one is.

Author here. This is the major drawback of this approach. Since I'm tuning the sound tone by adjusting the playback rate, what algorithm the browser uses for up and down sampling is a major aspect of how playback sounds that I have no control over. I think one browser uses nearest neighbour and the other uses linear interpolation (I forget which uses which). Ironically, NN is more accurate in terms of sounding like an Amiga

Firefox has a lot of "clicking" sounds for me at the start of most samples. Like one instant square wave with no length.

Plays super laggy for me if it's an unfocused tab in firefox.

The lag happens because FF throttles the frame rate that's calling Jerrica when a tab isn't the center of attention. When used in a game, the developer could choose the lazy route I did in the demo or could stop calling Jerrica completely.

In terms of the clicks and pops, if it's not an imposition, could you let me know if you hear similar artefacts in the Newgrounds game listed in the FAQ? That MOD file was specifically modified to try and minimise that issue and I'd be interested in if it sounds better or worse on your setup.

About the clicks in firefox:

I've dealt with this problem in a MIDI webapp I've developed a couple of years ago (midiano.com). If I remember correctly, firefox had some issue when samples were scheduled to immediately start with a gain value above 0. I believe the solution was to schedule them slightly earlier with a gain value of 0 and using "gainNode.setValueAtTime" to make the sound appear at the desired time.

Not entirely sure if that was the exact solution but I do remember firefox causing some problems in that regard. I just recall it being a hacky solution and that I couldn't find a documented explanation of why it happened.

Usually I associate that sort of problem with *stopping* a sample (since the stop will almost never happen at a point where the wave is actually at zero). Interesting that FF might have problems at the beginning, since most samples do indeed start at zero. I'll explore around that. Cheers!

Edit: midiano.com is excellent! Super useful to be able to visualise MIDI's that way.

I just went back and actually found the corresponding issue on my repository. Turns out it was firefox having issues with the setTargetAtTime function. I replaced it with linearRampToValueAtTime to get rid of the clicking sounds. I think for that to work I had to shift each note a little forward and then do a very quick ramp in the beginning. It does alter the sound a little though.

Also: Thank you! The idea is definitely derived from Synthesia but that isn't free anymore and I wanted to make it work in a browser :)

Sorry for late reply. There's clicks in the Newgrounds game too.

No worries. I appreciate it. I'm going to see if I can reproduce the issue and try @Bewelge's solution.

On my machine at least, Firefox seems to clip short audio samples (in general—-not related to this project).

I have bad news for anyone who recognizes the name-reference instantly

You're old

Like me :P

Showtime, cynergi

Impressive! In iOS Safari there are some issues with the timing/rythm of the melody in the mid part and some a the end of the song.

Also, if you switch to a different tab and then switch back, the player doesn’t resume.

I did notice in some cases frames getting delayed in the hyper demo but otherwise it works really well. This is an interesting approach!

Thanks! The demo is dumb stupid in terms of drawing the equalisers (canvas), but that actually makes it a better stress test.

Thanks, what a cool demonstration of WebAudio! Time for my weekly re-listen of space_debris.mod :)

Reply on news.ycombinator.com