User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:92.0) Gecko/20100101 Firefox/92.0

Steps to reproduce:

Carefully listen to audio on any website. For example, I listened to past bookmarked videos on YouTube where now there is audio stuttering which is repeatable when backing up and replaying the same video segment. I also tried rebooting my computer to a fresh state. The issue in Firefox persisted, yet does not occur when listening to audio files which are stored on my computer. I suspect that there is a timing issue in FF 92.

Actual results:

Stuttering audio for unknown reasons.

Expected results:

No stuttering audio.

This audio stuttering issue started after upgrading to FF92, and this stuttering issue seems to be centered on specific lower midrange frequencies. I tried disabling all plugins. I also copied and pasted YouTube links into Google Chrome and noted that this audio stuttering issue does no occur in Google Chrome. Possibilities in FF are timing issues or perhaps a flawed audio decoding library for YouTube audio, perhaps? This stuttering or fluttering issue is repeatable when jumping back a few seconds when listening to the audio in YouTube videos, yet does not occur when listening to the same videos in Chrome.

This stuttering issue occurs when using FF92 and with computer audio being sent to my headphone preamp set to 24-bit at 192,000 Hz. I don't recall encountering this issue with FF91. The issue is mitigated if I set computer audio to 24-bit at 96,000 Hz. This issue does not occur when using the 192,000 Hz bit rate for my headphones and computer speakers, nor does it occur when using Chrome or when listening to audio which is stored on my computer. This why I suspect a very slight timing bug in FF92.

Would you mind to profile Firefox by using Media preset?
Thank you!

Paul, do you think if it's related with bug 1730499?
This one is on Windows, not Linux, but I wonder if there is a cubeb changes landed on Fx92 which would affect other platforms as well?

Also, this is another stuttering happens on Windows 10, where opening a new tab would affect the audio playback.

If the stuttering issue is very easy to be reproduced on YT, I think that should be P2/S2.

(In reply to Alastor Wu [:alwu] from comment #3)

Would you mind to profile Firefox by using Media preset?
Thank you!

Hi Alastor,

I will be happy to do this. I will do two captures. One will be with my computer's audio set to 24-bit and 192,000 Hz and record that. This should show the issue. And then I will do the same thing, yet with my computer's audio set to 24-bit and 96,000 Hz which seems to mostly or entirely prevent the issue. I am super busy this week with work. I might not be able to get to this until this weekend.

Best regards,

--Michael

Alrighty. I did a lot more testing. This audio bug occurs when running FF to listen to online audio, regardless of the DAC on my computer's motherboard or the DAC in my headphone preamp, when the DACs are set to 24-bit and 192 KHz. I had to plug in headphones into my computer speakers' headphone port in order to clearly hear this audio issue. I tried disabling all FF plugins in order to make sure that none of the plugins were causing this issue. This issue does not occur when using Google Chrome. This issue in FF is fully mitigated when I set the DACs for my computer speakers and headphones to 24-bit and 96 KHz instead of using 24-bit and 192 KHz. During my extensive testing, I ruled out the chipset DACs (motherboard with Realtek ALC887 DAC and headphone preamp with Cmedia CM6642 DAC) as being the actual issue.

The end result is this: FF92, if this computer audio is configured to 24-bit and 192 KHz bitrate, has this audio frame stuttering issue. Yet if the computer audio is configured to limit the audio to 24-bit and 96 KHz, this issue is completely mitigated. This issue does not occur when listening to the same online videos when using Google Chrome and with the bit rate set to 192 KHz.

I downloaded PDFs for the specifications for my computer's REaltek and Cmedia DACs. After reviewing these PDFs, I still suspect that FF92 has either a timing issue or an audio frame issue in terms of what FF92 delivers to the user's computer, yet only when the audio frame rate for the computer is set to 192 KHz. Again, this issue is completely mitigated if the computer's max audio frame rate for all audio output is set to a max of 96 KHz instead of 192 KHz. The bit depth (16 or 24 bits) was tested and is irrelevant to this issue. Thus, this issue appears to be entirely related to the audio frame rate of 192 KHz, whereas this issue does not occur if the frame rate is set to 96 KHz.

This FF92 bug will likely take some time to investigate and resolve. My recommendation, in order to get around this bug on all platforms, is to simply do this: Configure FF audio to a max limit of 24-bits and 48,000 Hz in terms of what FF passes to a computer. This will definitely avoid all timing issues for the time being. I seriously doubt that any audiophile on the planet will be able to discern the difference between 24-bit at 192 KHz versus 24-bit at 48 KHz.

Thanks for the detailed bug report, this used to work. Can you please take a performance profile with the media preset as shown in those instructions: https://blog.paul.cx/post/profiling-firefox-media-workloads/#the-media-preset (there is a video and a text explanation), and then try to reproduce the audio glitches while capturing? I have put in some special real-time tracing code to diagnose things like this.

If you then upload the profile and give me the link here, or send it to me via email (<padenot@mozilla.com>), I'll be able to understand what's off. In the meantime I'm trying to figure out where my 192kHz devices are, I think they are still in the office, and I'm working from home because of the pandemic.

Additionally, the raw data from about:support would be helpful, to rule out anything else.

Matthew, could this be related to the shmem size fix you did recently ?

(In reply to Paul Adenot (:padenot) from comment #11)

Matthew, could this be related to the shmem size fix you did recently ?

The shmem changes are only in 94 (beta) onwards.

Given the comments about the varying behaviour with varying device sample rate, the fix in bug 1732479 may affect this. Michael, would you mind testing a current Nightly build to see if the problem is still reproducible there?

Redirect needinfos that are pending on inactive users to the triage owner.
:jimm, since the bug has high priority and high severity, could you have a look please?

For more information, please visit auto_nag documentation.