[Linux] OpenSUSE: malformed sound Topic is solved

[MakeTopSite]

Interesting... I got the "slow down sound" which I've not come across before but changing 'Prefs -> Advanced -> Compatability' to "Firefox", cured it. I always use "Native" and haven't seen this before.

Changing User Agent Mode from Gecko to Firefox solved the problem in openSUSE Leap.

[Moonchild]

Our default UA is Firefox for a reason. There's no telling what fallback code websites use when it doesn't recognise the browser and uses user-agent sniffing. Who knows it may fall back to something dumb like IE5 -- it may even just be broken for "unknown" and serve physically incorrect media.

[MakeTopSite]

Our default UA is Firefox for a reason. There's no telling what fallback code websites use when it doesn't recognise the browser and uses user-agent sniffing. Who knows it may fall back to something dumb like IE5 -- it may even just be broken for "unknown" and serve physically incorrect media.

Well thank you.
(I suppose there is no need to test this issue in openSUSE Tumbleweed)

[Birdy]

I'm experiencing the same sound issue here while using "Native" or "Gecko Compatibility": https://www.cbsnews.com/live/ (or the live video on the https://www.cbsnews.com/ front page)

I'm running the Pale Moon 32.5.2 (64-bit) mainline binary on Debian 13.

The live video plays fine but audio plays at an extremely low pitch with crackling, while videos on most other websites like YouTube and Twitch continue to play perfectly fine. As suggested earlier, the live video plays fine only while using "Firefox Compatibility".

I even tried watching the live video on an Ubuntu 22.04.3 LTS VM, and I was also able to replicate the sound issue there if I'm not on Firefox Compatibility mode (although I did have to have FFmpeg installed in order to get the live video playback to work on both Ubuntu and Debian).

I don't have a Windows machine, but this does make me wonder if the same issue happens there while using the native user agent...

[athenian200]

It's worth noting that we don't really test the ALSA backend very much. I was playing around with OpenSUSE recently, and I couldn't get the sound to work properly with ALSA at all... I had to install PulseAudio and mess with mixer settings to get everything working properly. For whatever reason, OpenSUSE doesn't install PulseAudio and forces us to fallback to ALSA by default, though you can fix it by installing PulseAudio usually. I didn't really think much of it, because I believe I saw the same issue with older Firefox, and just thought of it as one of those "Linux quirks."

[Night Wing]

I'm experiencing the same sound issue here while using "Native" or "Gecko Compatibility": https://www.cbsnews.com/live/ (or the live video on the https://www.cbsnews.com/ front page)

I'm running the Pale Moon 32.5.2 (64-bit) mainline binary on Debian 13.

The live video plays fine but audio plays at an extremely low pitch with crackling, while videos on most other websites like YouTube and Twitch continue to play perfectly fine. As suggested earlier, the live video plays fine only while using "Firefox Compatibility".

Debian 13 has not been released yet to my knowledge. It is still a work in progress. A "beta" in my opinion.

I I clicked on the link you provided (cbs.news) and the sound plays fine in both 64 bit Debian 12.4 (Bookworm) Xfce and also in 64 bit MX Linux 21.3 (Libretto) Xfce using 64 bit linux Pale Moon (32.5.2) in Firefox Compatibility agent mode.

[Moonchild]

The root problem seems to be that websites send audio in a different format to "unknown" browsers than to "Firefox" browsers, based on the user-agent. This different format may be using a sample rate or sample format that ALSA doesn't natively support, and because it's a simple interface it will also not do any on-the-fly conversion and just sends the data to the sound hardware as-is.

[ron_1]

I'm experiencing the same sound issue here while using "Native" or "Gecko Compatibility": https://www.cbsnews.com/live/ (or the live video on the https://www.cbsnews.com/ front page)

As Night Wing has said, it works just fine using Firefox Compatibility Mode. So it needs switched to that if you want to watch videos from this site. The problem is with the website, not Pale Moon.

[random]

Debian 13 has not been released yet to my knowledge. It is still a work in progress. A "beta" in my opinion.

Debian 13 is the current testing distribution. I don't believe it's more beta than any other rolling release distro. Anyway, I can reproduce the audio problem with Debian 12 i386 too.

The root problem seems to be that websites send audio in a different format to "unknown" browsers than to "Firefox" browsers, based on the user-agent. This different format may be using a sample rate or sample format that ALSA doesn't natively support, and because it's a simple interface it will also not do any on-the-fly conversion and just sends the data to the sound hardware as-is.

I don't think that is the problem. I downloaded the sequence_*.ts files and I cannot see a difference regarding size, codec or container format with Firefox Compatibility mode or Native mode. It seems to stream and play the exact same files. It plays flawlessly in VLC. If I convert the ts file to an mp4 file it also plays correctly in Palemoon.

Code: Select all

$ ffmpeg  -i sequence_284103927.ts -c:a copy -c:v copy sequence_284103927.mp4
[...]
Input #0, mpegts, from 'sequence_284103927.ts':
  Duration: 00:00:06.00, start: 52485.161322, bitrate: 6017 kb/s
  Program 1 
    Stream #0:0[0x65]: Video: h264 (High) ([27][0][0][0] / 0x001B), yuv420p(tv, bt709, progressive), 1920x1080 [SAR 1:1 DAR 16:9], 50 fps, 50 tbr, 90k tbn, 100 tbc
    Stream #0:1[0xc9](ENG): Audio: aac (LC) ([15][0][0][0] / 0x000F), 48000 Hz, stereo, fltp, 192 kb/s
Output #0, mp4, to 'sequence_284103927.mp4':
  Metadata:
    encoder         : Lavf58.45.100
    Stream #0:0: Video: h264 (High) (avc1 / 0x31637661), yuv420p(tv, bt709, progressive), 1920x1080 [SAR 1:1 DAR 16:9], q=2-31, 50 fps, 50 tbr, 90k tbn, 90k tbc
    Stream #0:1(ENG): Audio: aac (LC) (mp4a / 0x6134706D), 48000 Hz, stereo, fltp, 192 kb/s
[...]

As this is 48000 Hz audio sampling rate, any sound device and ALSA should be able to play it.

As Night Wing has said, it works just fine using Firefox Compatibility Mode. So it needs switched to that if you want to watch videos from this site. The problem is with the website, not Pale Moon.

Is it though?

And what exactly is the cause of problem? I doubt it is the stream itself. Maybe it's a problem with the javascript? AFAIK most browser (including Palemoon) don't support playing ts (video/MP2T) files or HLS streams directly, so you need some javascript. But whatever User-Agent I choose, the web server always provides the exact same js files.

It's really weird.

[Moonchild]

Is it though?

And what exactly is the cause of problem? I doubt it is the stream itself.

See my previous reply in this thread.

By definition, the fact that different media is presented to different user-agents is already telling us that something is being done server-side.
".ts" files are, iirc, much more restricted in what codec/compressions it allows, and i don't think h.264/aac is a widely-supported combination for that container (if at all allowed -- I thought they were always mpeg-2?)

[Birdy]

One thing that wasn't addressed in my original post was whether or not this issue also manifests itself using non-Firefox mode in Windows.

If we can figure that out, we can probably further deduce this as an OS issue, like with ALSA or FFmpeg.

[Moonchild]

whether or not this issue also manifests itself using non-Firefox mode in Windows

No issue on Windows.

we can probably further deduce this as an OS issue, like with ALSA or FFmpeg

We'd already seen that it's specifically an issue with using ALSA, but installing PulseAudio (which we also support and preferentially use on Linux) fixes the issue. So it specifically is an issue with the interop between Linux+ALSA and what the website in question sends when not seeing "Firefox".

[Birdy]

I'm experiencing the same sound issue here while using "Native" or "Gecko Compatibility": https://www.cbsnews.com/live/ (or the live video on the https://www.cbsnews.com/ front page)

I'm running the Pale Moon 32.5.2 (64-bit) mainline binary on Debian 13.

The live video plays fine but audio plays at an extremely low pitch with crackling, while videos on most other websites like YouTube and Twitch continue to play perfectly fine. As suggested earlier, the live video plays fine only while using "Firefox Compatibility".

Debian 13 has not been released yet to my knowledge. It is still a work in progress. A "beta" in my opinion.

I'm aware that I'm using more of a rolling-release distro, which is why, to random's point, I had also mentioned "I even tried watching the live video on an Ubuntu 22.04.3 LTS VM, and I was also able to replicate the sound issue there" in my original post, to dispel the notion that this is only an issue with a so-called "beta" OS.

whether or not this issue also manifests itself using non-Firefox mode in Windows

No issue on Windows.

we can probably further deduce this as an OS issue, like with ALSA or FFmpeg

We'd already seen that it's specifically an issue with using ALSA, but installing PulseAudio (which we also support and preferentially use on Linux) fixes the issue. So it specifically is an issue with the interop between Linux+ALSA and what the website in question sends when not seeing "Firefox".

Interestingly, if I look at about:support, I do see "pulse" (PulseAudio) being used as my audio backend, and I'm still seeing the issue there on a 64-bit Debian 12 Xfce VM:

Code: Select all

$ pactl info | grep '^Server '
Server String: /run/user/1000/pulse/native
Server Protocol Version: 35
Server Name: pulseaudio
Server Version: 16.1

[Moonchild]

Interestingly, if I look at about:support, I do see "pulse" (PulseAudio) being used as my audio backend, and I'm still seeing the issue there on a 64-bit Debian 12 Xfce VM:

Interesting - so it would be a deeper issue with whatever audio driver is being used then

[random]

Is it though?

And what exactly is the cause of problem? I doubt it is the stream itself.

See my previous reply in this thread.

By definition, the fact that different media is presented to different user-agents is already telling us that something is being done server-side.

That was my point, I don't see any different media. It is exactly the same, regardless of User-Agent. It's also unlikely that there are sample rates below 48000 Hz or 44100 Hz in video streams nowadays.

".ts" files are, iirc, much more restricted in what codec/compressions it allows, and i don't think h.264/aac is a widely-supported combination for that container (if at all allowed -- I thought they were always mpeg-2?)

I guess h.264/aac is are one of the most commonly used codecs in MPEG transport streams. It even supports HEVC (h.265) and VVC (h.266) in the newest specification of the standard (which is around 300 pages). Which all doesn't really matter, because browsers don't support .ts directly and some javascript is required (AFAIK). So maybe the js is doing something funky ...

[Moonchild]

That was my point, I don't see any different media. It is exactly the same, regardless of User-Agent.

but that directly conflicts with:

As Night Wing has said, it works just fine using Firefox Compatibility Mode.

The user-agent string is literally the only difference between Native/Gecko/Firefox compatibility mode...

[Birdy]

".ts" files are, iirc, much more restricted in what codec/compressions it allows, and i don't think h.264/aac is a widely-supported combination for that container (if at all allowed -- I thought they were always mpeg-2?)

I guess h.264/aac is are one of the most commonly used codecs in MPEG transport streams. It even supports HEVC (h.265) and VVC (h.266) in the newest specification of the standard (which is around 300 pages). Which all doesn't really matter, because browsers don't support .ts directly and some javascript is required (AFAIK). So maybe the js is doing something funky ...

You're probably right...

I did a quick search and found at least one popular JS library (HLS.js) that allows browsers to play .ts files (including live streams with H.264 video and AAC audio, apparently) by using MSE to transmux them "on the fly" into MP4 fragments.

That said, I can hear the same issue happening when playing both of the Big Buck Bunny videos (the "adaptive qualities" and the "480p only" ones) on their demo page: https://hlsjs.video-dev.org/demo/ (and whenever I do hear the videos' sound playing normally on Linux, I keep forgetting every now and then that it's because I've re-enabled "Firefox Compatibility" mode to work around the issue )

[Birdy]

For sites that use HLS.js, I pushed out a fix for Pale Moon (just updating an old Firefox workaround for now) that should be released on an upcoming version. It ends up resolving the sound issue on my end.

Further discussions here:

• https://github.com/video-dev/hls.js/issues/6110
• https://github.com/video-dev/hls.js/pull/6111