No, it doesn't do what I expect, the list of the default rebindable keybinds is small, can't bind multiple shortcuts to a single function, can't bind without modifiers- if I recall correctly after trying it out a while ago.
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.
To expand a bit on that, the i386 support that was recently deprecated to "partially supported" in Debian refers to project status. Unsupported architecture can not be considered blockers, for example. The packages are still being built, are published on the mirrors, and will be for the forseeable future as long as enough people care to keep it alive.
That's the specific meaning of support that it was my intention to point out. Free software projects usually do not "support" software in the commercial sense, but consider platforms supported when there are enough persons to keep the build alive and up to date with the changing build requirements etc. It was my expectation that Firefox was more like free software project than a commercial product, but perhaps that is not the case?
Commercial products have to care about not spreading their resources thin, but for open source cause and effect are the other way around: The resources available is usually the incoming paramter that decides what is possible to support. Hence my surprise that not enough people are willing to support a platform that has thousands of users and isn't particularly exotic, especially compared to what mainstream distributions like Debian already build.
For a while I have been curious about the intended uses for xAtTime functions (like cancelAndHoldAtTime) in Web Audio. As far as I understand it, calls to them suffer from lag due to main JavaScript thread and audio thread communication, which makes sample precision unachievable—and precision is quite important in music.
Is it mostly for emulating slow-moving changes on fixed timelines, a la automation tracks in traditional DAWs like Logic and Ableton? Is design rationale documented somewhere?
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.
Amusingly, President Macron also said that he was going to swim in it to prove it was safe, but ultimately didn't. According to Wikipedia, "the primary reason cited was the concurrent French general election, but reports also circulated that protestors had planned a mass defecation event to coincide with the swim."
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.
Please don't take this kind of criticism personally. There was a recent blow up from an open source maintainer because he viewed this kind of criticism as a frustration.
Just know that most people understand everything you are saying here. Many things to do, finite amount of time.
I have personal experience of Firefox developers going above and beyond to make high-usage sites work for their users. I know first hand the lengths they will go to when issues affect users. Thank you and keep plugging away.
I'm a long time Firefox user and have no intention of changing. I fully agree but want to make an important distinction. Sometimes people are complaining about development work and sometimes people are complaining about priorities. This is definitely the latter and I do not think it necessarily a developer issue. Firefox does have the opportunity to become so much greater, but it does require a lot of work and time. I'd argue, give the developers the time and resources. I know Mozilla has their hands in a lot of pies, but Firefox is probably the most important one, even if it isn't the most revenue generating one. Firefox is the symbol of Mozilla and it needs to be the best. The developers have proven how much they can change things and make things better. The Rust partial rewrite was nothing short of a success. So I want to see that progress continued and to keep pushing in that direction.
Thank for your work, from a Firefox user.
Also, the OP is probably already aware of this:
"It's not perfect as resuming takes a little bit of time and it may not always resume, as there are multiple paths to starting audio. But it's good enough for me."
For every one person "complaining" there are 999 of us quiet ones out here that use and love your product hours out of every day . I hope devs at firefox can cut through gruff articles with click baity titles and extract nuggets of usefulness from them though.
I think many people would be curious to hear about the additional complexity above and beyond "suspend when silent", if there's an already-written thing you could link to.
(I do know that resume-when-playback-starts sometimes causes the first bit of audio to get lost, or all of the audio for short things like notification sounds.)
I have a record player with bluerooth that doesn't understand 45s exist, even though the manufacturer included the adapter; also Bluetooth drops out during quiet parts, such as those in podcasts or old radio programs or any music made prior to 1997 within reason.
So I ask: define silence. Define sleep. Because you get it wrong you have a $200 device headed for the landfill.
I hope this kind of thing can shoot up the priority queue! Battery-stealing and generally janky behavior is likely the main reason folks stop using a piece of software.
Thanks for your work, and for talking about the issue on a public forum! It's so critically important that Firefox maintains/increases relevancy. I'm sure it's unbelieveably difficult work given the resources behind Chromium & Blink.
On Linux there are weird audio issues that lead to speaker pop, and sometimes opening a new tab can make the audio running from other tabs permanently distorted and static-y until you reboot. (Not a complaint. I've always wondered if it was a browser or audio system issue.)
When I had this issue, it was fixed by disabling and removing the speech-dispatcher. Something to do with text to speech (I never use it but is sure to be a pain if you do need it) automatically doing things that corrupt the audio stream globally.
It might be that nothing is actually being played, but opening an audio session wakes up your systems DAC/amplifier so you can hear the analog noise floor. In that case the noise is actually always there during playback, you're just more likely to notice it during silence.
Computers are a really hostile environment for audio, if possible you're always better off getting an external audio interface to put some distance between the analog signal path and any EMI spewing components.
I knew about OP's problem for years with discord's piece of shit webapp being the most egregious offender. For my system the sound falls into a low power state and there's an audible pop/click when something wakes it up. Even with the tab silenced and all notifications turned off it would still periodically do this. Other sites that used WebRTC had same problem but not as frequent. I think I worked around the issue eventually by disabling the automatic low power state at the expense of some additional battery consumption.
> Computers are a really hostile environment for audio
My first thought was the author should be happy that they don't live back in the bad old days of computing. Audible noise was the norm, even when you were playing audio. At least for PCs with sound cards. I don't recall the situation being quite as bad on other platforms. Modern PCs are much better on this front.
I have vague recollections of a quote from the Computer Chronicles in the mid-1990's. It went to the effect of turning a $2000 computer into a $200 stereo ...
This kind of thing amazes me. Radio is such a simple, yet omnipresent, technology that even something not made to listen to radio can accidentally catch and play the signal like an actual radio player would. I sure hope it's never going away.
When I was growing up, we lived within 6km line of sight from a powerful AM broadcaster on 660KHZ.
By some stroke of fortune, our woodstove smoke pipe and the tinfoil backed insulation of the house,
Along with the grounded base but rusty bolted on top of the woodstove created some kind of resonant receiver at that frequency. It would generate sufficient voltage to deliver the occasional electrical shock, which was very mysterious because we had no idea how this stove could shock you, even when the mains were turned off.
The mystery of the source of the power was shocks when we built a wire drying rack above the stove, which acted as a sound transducer. With the glove rack, we were treated to 24/7 programming, mostly community oriented stuff like “problem corner”(community issue discussion) bush relay messages for remote listeners outside of telephone reach, “tradio” (call in radio Craigslist, basically), news shows, talk shows, and some occasional music.
To me, it was just completely normal, never having known anything else besides electrocution hazard wood stoves and radio show mitten racks lol. It did fuel a fascination for electronics, though, so by the time I was seven I was an avid reader of popular electronics magazine. Forrest Mims. What a treasure of an engineer.
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).
Bless you. I was driven a little mad once trying to figure out why certain websites would steal audio focus away from music playing on my phone, it must have been some clumsy implementation of this.
