Debian has stopped supporting x86 32bits recently, Chrome did so 9 years or so ago.
We've carefully ran some numbers before doing this, and this affects a few hundreds to a few thousand people (hard to say, ballpark), and most of those people are on 64bits CPUs, but are using a 32bits Firefox or 32bits userspace.
The comparatively high ratio of 32bits users on Windows is not naively applicable to the Linux Desktop population, that has migrated ages ago.
Those methods are sub-sample accurate, granted you call them a bit in advance to account for the cross-thread communication, as you say. But yes, in general this was designed (prior to me becoming an editor) with scheduling in mind, not with low-latency interactivity. That said, it goes quite far.
Other systems go further, such as Web Audio Modules (that builds on top of AudioWorklet) implement sample-accurate parameter change from within the rendering thread, using wait-free ring-buffers. That requires `SharedArrayBuffer` but works great, and is the lowest latency possible (since it uses atomic loads and stores from e.g. the main thread to the rendering thread).
`jj commit -i` (or a lot of commands `-i`) and maybe `snapshot.auto-track="none()"` in the config, to a certain extent is what I use. I used to do the same with mercurial. In practice, I also use `absorb` a lot, that leaves unrelated files and chunks alone.
He did last year, alongside mayor Hidalgo and others, such as Tony Estanguet, who is a former athlete and was overseeing the olympics and the minister for sports.
You're out of luck on Safari because it seems that the important APIs aren't implemented yet: https://developer.mozilla.org/en-US/docs/Web/API/AudioContex... (scroll down). This means this cannot be made correct, e.g. there will always be a desynchronization when using high latency audio output devices such as anything wireless. Their handhelds (on which non Safari is not allowed) and their MacBooks, in wired/built-in speaker mode have excellent latency figures and we can get away with not doing anything explicit there, granted the audio is not happening somehow before the visuals, that is jarring for a human. A bit late is a lot more natural if it can't be exact.
lmk if you need further details on tight synchronization of real time audio and visuals, [email protected], happy to help, and congratulations on the delightful websites!
This is planned, and important, and we'll fix it hopefully soon, it's long overdue. I'm sorry this hasn't happened yet, it's always a game of priorities that can never satisfy everybody on time. It however ranks fairly high on my personal list.
As one could imagine it's a bit (read: a lot) more complicated than just pausing the AudioContext after some time of silence, but we'll get it fixed regardless, it's possible because others did it. There are tradeoffs we're willing to do.
Source: Firefox implementer of a lot of things around this, editor of the Web Audio API standard.
It does not, it serves no purpose for only listening to music.
Producing, broadcasting, or any sort of scenario that require reliable low latency can benefit from a real time kernel, but not merely listening to music.
Indeed. I work on the Firefox media stack and we have been grabbing wake locks when video playback is happening for a long time. Occasionally e.g. on some linux desktop variant this has malfunctioned and we're alerted in no time and fix it.
The Wake Lock API is for other use cases, such as recipe websites, or other document for which you don't want the screen to go away / dim, the kind where you happen to need to look at the screen for long period of time without touching it/interacting w/ mouse and keyboard.
Prior to this API being introduced, websites used to play an inaudible/almost invisible looping media file to keep the screen awake. This has power usage implication, a small single digit number of watts (1 to 3.5 depending on os, hardware, mobile or not) is required to keep audio running (because of high priority threads, frequent wakeups, and simply because the audio hardware itself needs power).
3. Worklets are bits or javascript that run on the audio thread directly, where you're supposed to only implement the DSP bits, and only communicate with the main thread using message passing.
An `AudioContext` (which is the object that lets you do non-trivial audio in the browser) does most of its work on a special, high priority thread, off an audio callback.
Having `AudioContext` in a worker does not get you a lot. It's planned, but not prioritized very high. What happens when you're calling methods in JavaScript on an `AudioContext` is that we simply validate the input and queue messages to the audio thread, so this is effectively exactly what the article is talking about. We use some locking, but we've carefully wrote the code so that it's not really an issue. We lock just to swap two pointers in a message queue. This could certainly use atomics, but we have more important things to do first.
That said, the interesting thing developers need and want is `AudioWorklets` [0], and that's what we at the W3C Audio WG is working on more or less full-time, these days. It used to be called `AudioWorker`, but got renamed for a lot of reasons [1].