There are three places to accumulate latency, the input from the instrument to the computer, the processing of filters, the output to the monitor (headphones/speakers)/recording. Sometimes you can get away with 2 or 3 ms of latency, but anything over 5 ms is super frustrating. Remember, you're fighting the latency between plucking a string or hitting a key and when the computer acknowledging the data and sending it back out to the monitor which you're using as your guide. Best case you go and "massage" the new track to line up with the existing tracks, worst case it sounds like an out of sync high school marching band.
EDIT: The concerns here are primarily with input latency. Between plucking a string and heading it in your monitor it has to go through: your input hardware, the USB interface, the OS, the browser (which doesn't have explicit low latency capabilities), and JS. Most platforms support ASIO which is a low-level driver for reading audio data from devices. About as close to reading the ADCs yourself. Without a low-latency driver working with the OS there's so much latency overhead it's audible.
Not sure why you picked up downvotes on this comment because I think you’re right. 5 ms is not at all a lot of latency. I think even very exacting professional musicians would be hard pressed to detect it. At 128 samples and using the Push 3 as an audio interface on my M1, round trip latency is 13 ms, and even that is not a frustrating amount of latency.
ASIO was just one of the first audio APIs to provide high-quality, low-latency audio. Many people haven't realized that native audio APIs have moved on since then.
macOS has proper audio APIs out of the box, and arguably since the introduction of WASAPI exclusive mode and WaveRT in Windows Vista, Windows has all the needed tools as well. But most of the more "professional" DAW products (in particular those by Steinberg, the author of ASIO) seem to ignore the existence of those. REAPER is one of the exceptions. Even WASAPI shared mode latency is really usable (below 30ms), but not low enough for tightly synchronized real-time recording.
Linux audio can be set up to provide low-latency audio as well, but I cannot comment on the details there as I'm not using it for that purpose.
You're right, it's not natively on Linux, and you wouldn't use it on Linux today since the kernel supports lower latency IO and has better scheduling. Jack has gotten so much better. We didn't have that at the time and I was desperate to use the only interface card I had.
That said, there are plenty of open source implementations of ASIO drivers now that aren't hardware tied.
> you wouldn't use it on Linux today since the kernel supports lower latency IO
Actually you absolutely would use it, in the same way you did back then.
WineASIO is a layer that allows a Wine application to use the ASIO API. Since ASIO is not a part of Windows itself, anything that wants to use ASIO can't do so on "bare Wine", and Wine doesn't allow for the installation of a windows kernel driver layer like ASIO. Hence: WineASIO - an implementation of ASIO for use by Windows applications running inside Wine.
Also, Ubuntu 14 dates to 2014; JACK dates back to 2002. Very little, if anything has changed about JACK since 2014. AFAIR, WineASIO could or did use JACK itself at some point in its development history, since it was a pretty natural fit.
I don't know of any open source ASIO implementations. The only 3rd party one of, ASIO4ALL, is not open source. Then again, I don't track the Windows environment much at all.
EDIT: The concerns here are primarily with input latency. Between plucking a string and heading it in your monitor it has to go through: your input hardware, the USB interface, the OS, the browser (which doesn't have explicit low latency capabilities), and JS. Most platforms support ASIO which is a low-level driver for reading audio data from devices. About as close to reading the ADCs yourself. Without a low-latency driver working with the OS there's so much latency overhead it's audible.