padenot
commented
11 months ago I've noticed that when playing audio streams (e.g., Soundcloud) or the samples in the Demos here , that I get clicking/popping or glitching occurring in a fairly regular pattern. I've been on Mozilla support and tried a host of troubleshooting suggested, leading to the discovery shown by about:support#media where the audio backend listed is WASAPI.
Thanks for filing an issue!
Generally, when there's a problem in Firefox, it's best to open a bug in its tracker. If this happens in the future, https://bugzilla.mozilla.org/enter_bug.cgi?product=Core&component=Audio%2FVideo%3A%20cubeb is a direct link that will place the ticket in the correct component. We receive an email here or there, so in the grand scheme of things we'll find it in either location, but cubeb is used by other programs than Firefox, so Firefox-specific issues are best directed to Firefox's own tracker.
I've opened https://bugzilla.mozilla.org/show_bug.cgi?id=1846409 for you, you can simply log in with your GitHub account. I've asked for a number of easy-to-gather information that will help us understand what is going on, please don't hesitate to ask if you have any question.
But in any case, I can answer some of your questions here -- but if possible, it would be best if we would discuss your issue with Firefox on bugzilla.
On the latest version of FF, on my Win10 machine, routing sound in Windows to my MOTU Audio Interface via ASIO at 48kHz is when this happens. Sound is not glitchy on YouTube, or most other video formats. It appears to be related to audio streaming only. What is interesting is that if I set the Windows Sound Control Panel to be 44.1kHz, the glitching stops, the sound plays clean (this requires a page refresh). If I set it back to 48kHz, it glitches again (after a page refresh). I first thought this to be a sample rate mismatch, but then found another app that had the same glitch issues. Further investigation into that app's settings revealede that the default settings was to use WASPI, even though it was still routed to my MOTU (now sure how that works, since it is ASIO - but I'm not real knowledgeable on Windows Audio). In that app, I was able to select ASIO instead of WASPI, set my MOTU device, choose 48kHz, and the sound in that app then played PERFECTLY!
When you say "on the latest version", does it mean it was working well before? Youtube and others use high-latency playback, optimized for robustness, whereas SoundCloud uses a very low latency API that is a bit more glitch prone (but it should generally work well -- I'm not saying there isn't a bug here). I think it must be related to sample-rate conversion somewhere in the chain, thanks for trying a couple of things out.
What I gathered from that is that the issue is not with sample rate mismatch, but with using WASAPI with my ASIO MOTU audio interface. It appears that there is no way to change from WASAPI to ASIO in FF like there is with the other app mentioned.
WASAPI is the native API to do audio input/output on Windows, and ASIO drivers are usually provided by audio equipment manufacturers. It's possible to use WASAPI to output to any sound card, but generally the playback will be more robust against high machine load (or allow achieving lower latency) if using ASIO. There's no general rule, but it's generally recommended to directly use ASIO drivers in music software (e.g. a Digital Audio Workstation, that kind of thing).
Is there a reason for this? And can it be improved? I'm not sure exactly what in the WASAPI to MOTU signal chain that might be causing this glitching to occur, but it is remedied in other apps by utilizing the correct ASIO driver for the output device. Any advice would be appreciated.
Unfortunately, the licence for the ASIO SDK is absolutely incompatible with the free software licence of Firefox. I wish we could use it, but as far as I know, we are not allowed to do so, for legal reasons. It might be possible to make a build of Firefox that can talk to an ASIO driver, but I don't think we'd be allowed to distribute it.
GrizzlyAK
I've noticed that when playing audio streams (e.g., Soundcloud) or the samples in the Demos here , that I get clicking/popping or glitching occurring in a fairly regular pattern. I've been on Mozilla support and tried a host of troubleshooting suggested, leading to the discovery shown by about:support#media where the audio backend listed is WASAPI.
On the latest version of FF, on my Win10 machine, routing sound in Windows to my MOTU Audio Interface via ASIO at 48kHz is when this happens. Sound is not glitchy on YouTube, or most other video formats. It appears to be related to audio streaming only. What is interesting is that if I set the Windows Sound Control Panel to be 44.1kHz, the glitching stops, the sound plays clean (this requires a page refresh). If I set it back to 48kHz, it glitches again (after a page refresh). I first thought this to be a sample rate mismatch, but then found another app that had the same glitch issues. Further investigation into that app's settings revealede that the default settings was to use WASPI, even though it was still routed to my MOTU (now sure how that works, since it is ASIO - but I'm not real knowledgeable on Windows Audio). In that app, I was able to select ASIO instead of WASPI, set my MOTU device, choose 48kHz, and the sound in that app then played PERFECTLY!
What I gathered from that is that the issue is not with sample rate mismatch, but with using WASAPI with my ASIO MOTU audio interface. It appears that there is no way to change from WASAPI to ASIO in FF like there is with the other app mentioned.
Is there a reason for this? And can it be improved? I'm not sure exactly what in the WASAPI to MOTU signal chain that might be causing this glitching to occur, but it is remedied in other apps by utilizing the correct ASIO driver for the output device. Any advice would be appreciated.