Hey cool!  I'll have to take a look at this.  Nice work.

@4:

You can absolutely use this with pure JS. Check out the example directory to find examples of that. Sometimes for larger projects I like to use Node to help glue things together, but it's not required (see my template repository, a work in progress).

@5, keep up the great work. this sounds cool. i love it

@shiftBacktick I sent you a PM.

For what it's worth, you may find in practice that just using a database of impulse responses gives you a much better HRTF implementation than trying to make it configurable.  Almost no one will play with the configuration, and in practice those sorts of mathematical models are actually very poor approximations to the head, so the trade-off very much can become "1% of users configure it, but it's worse for the 99%".  Unfortunately the built-in WebAudio one is highly variable per browser.

The only good configurable one I know of is OpenALSoft, and there's a frankly massive C program which is responsible for taking the impulse responses and the configuration parameters and producing a big data file that gets fed in at runtime.

@12
Synthizer gets double digit sources in debug builds with the boring old non-optimized convolution that you're never supposed to use and I expect upwards of 1000 in practice on a good machine in the microbenchmarks, whenever they happen.  That's partly sarcasm--when deciding to use boring old O(n^2) convolution everyone always misses the bit about the crossover point where the FFT version starts being faster, which is something I persistently see people get wrong.  Sadly it sounds like the WebAudio people missed that too.  Fun.  Admittedly part of that is that I am very clever about packing data appropriately for SSE vectorization, but still.  Every time I think I'm done being disappointed with the implementation quality of it, I find that I was in fact mistaken.

I haven't read your code, but I'm assuming that you're doing a biquad per channel.  The problem with that is that a single biquad isn't actually enough to capture HRTF.  You'll permanently lose out on any vertical effects for one thing.  What I may eventually do in Synthizer is allow an additional lowpass filter for emphasis.  But even that doesn't work out so well in practice: the lowpass filter for behind the player due to HRTF and the lowpass filter for occluded by the wall are effectively the same filter.  It might be possible to construct a more accurate model with 2 or 3 biquads in series, but I haven't tried.  The actual frequency response of those impulses is more like a complicated equalizer, not just a couple filters in series.  The "the head is a sphere and" models throw out a lot of detail.

As a benchmark, check this or any of the other variants of it with different HRTF datasets.  OpenALSoft is kind of the benchmark for this, and it's just convolution plus reintroducing removed interaural time difference that was extracted with magic.  I can go into the specifics of the magic, if you know enough math, or you can read the scripts in Synthizer's repository where I do something in the same general ballpark of it.  The general idea is that you convert the filters to minimum phase, then you do some normalization that lets you select between flat frequency response and "this is Bob's head and only Bob's head" response, and just land somewhere in the middle, enough to emphasize what most people have in common without overindividualizing it.

But in general you're stuck with WebAudio and probably can't do better, at least unless you feel like getting into web assembly.  It might be possible to make a program which determines the low-level coefficients for biquad equivalents, but I don't think WebAudio is big on crossfading that properly for you and the naive thing where you crossfade the coefficients one by one actually produces intermediate unstable filters.

One thing that does really leap out at me is that you say what you do is faster than 2 StereoPannerNodes per source.  What was the motivation there?  As far as I know you should only ever need one per source.

Most of my knowledge is self-taught and practical, so possibly you know more of the DSP math than I do.  But if you want a good starting point that may or may not be a quick improvement, you might port my ITD computations, which will require a clockwise angle in degrees from the front of the head (yes, I know, it's a weird coordinate system. But that's what all the HRTF literature does).  In terms of pieces you can drop in to WebAudio, that's probably a pretty simple one.  That said, I don't promise that all the geometry is right, just that it sounds good when I and some others test it.

You probably just flat out can't get better than a lowpass in WebAudio though.  The specification is fine as regards panning.  It's not fine as regards everything else.  And it's not fine in the sense that all the implementors do a really bad job with it, which really surprises me given how relatively simple audio is as compared to things like WebGl.  In this case, Webasm might save you, but the performance of getting audio into and out of it might not be so great.  The last time I got as far as wanting to use Webasm for custom nodes, I got tired of just fighting WebAudio nonstop, realized that everything I might ever want to do needs a desktop app because most blind people can't download 100MB of sounds every time they started my game, and went and started Synthizer instead.  There's more justification to it than that, namely that we really need an audio library like it that's not thousands of dollars, so it wasn't just me ragequitting WebAudio or anything.  But nonetheless here we are.

In either case, if it's helpful in some fashion, my scripts for HRTF impulse normalization are here.  They're not perfect, in particular they take out too much of the frequency dependent effects, but I'll be improving them and they're like 90% of the way there.

I can't speak for ShiftBacktick, but that's going to highly depend on the mobile device you want to run it on.  In theory it should work.  In practice, WebAudio can't be optimized nearly as much as something like Synthizer can and it can't offload to something like a GPU either, so it's going to heavily depend on the CPU and be expensive no matter how you slice it.  Plus, lots of mobile devices have older browsers.  New iPhones?  Fine.  Cheap Androids?  Maybe not.