Fitting name, then, for a JavaScript-based music player program. I love geeky references like this.
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)
Plays super laggy for me if it's an unfocused tab in firefox.
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.
the numbers are tracker sequences and bars if anybody's wondering.
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.
This is how it sounds on a video grab from an Amiga:
Same notes, but somehow still very different.
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?
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...
> 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.
You're old
Like me :P
Showtime, cynergi
