1218235 - HTML5 media with certain audio codecs have no sound with ALSA/dmix at 96khz

Status: NEW

(Core :: Audio/Video: cubeb, defect, P5)

Description

[Christian Birchinger]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:42.0) Gecko/20100101 Firefox/42.0
Build ID: 20151024014506

Steps to reproduce:

Summary:
========

Certain HTML5 media has no sound on ALSA with dmix and 96 Khz

On http://www.jwplayer.com/html5/formats/ it's the
"VP9/OPUS IN WEBM" and "OPUS IN OGG". All others
work.

In general everything on YouTube works while everything on Vimeo
fails. Details on how to switch or workaround the behaviour is 
below.

The same ALSA config has been used for many years now and no
audio software ever had issues with it. This doesn't rule out
ALSA bugs, but at least makes triggering the bug really rare.

Tested with: 
Firefox 41.0.2 binary release from mozilla.org
Firefox 41.0.2 source built on Gentoo
Firefox 42beta8 source built on Gentoo

Basic info and assumptions:
===========================

I'm listing videos i've used here but it affected all the videos
from either YouTube or Vimeo all the time.

Test URL for YouTube: https://www.youtube.com/watch?v=sGbxmsDFVnE
Test URL for vimeo:   https://vimeo.com/channels/staffpicks/142600751

Format Test URL: http://www.jwplayer.com/html5/formats/

Test have been repeated with 2 other sound hardware devices with
exactly the same result to rule out hardware issues.
One is a HDMI AMD Card and the other an USB 2.0 audio device. 

I found a very similar issue on the Chromium bug list:
https://code.google.com/p/chromium/issues/detail?id=453193
(This makes it even more strange, because all other audio players
have never issues for the past years, but 2 browsers)

Basic asoundrc:
----->8-------------->8--------------->8--------------->8-----------
pcm.xonar-hw {
  type hw
  card D2X
  device 1
}

pcm.xonar-dmix {
  type plug
  slave.pcm {
    type dmix
    ipc_key 1024
    slave {
      pcm "xonar-hw"
      period_size 1024
      buffer_size 4096
      format S32_LE
      rate 96000
    }
    bindings {
      0 0
      1 1
    }
  }
  hint {
    description "Dmix Xonar X2D Digital S/PDIF Output"
    show on
  }
}
----->8-------------->8--------------->8--------------->8-----------

1)
YouTube                                     -> WORKS
Vimeo                                         -> NO SOUND
jwplayer Test (AAC IN MP4)        -> WORKS
jwplayer Test (VORBIS IN OGG)  -> WORKS
jwplayer Tes  (MP3 RAW AUDIO) -> WORKS
jwplayer Test (OPUS IN OGG)     -> NO SOUND *

* Player remains stuck at "0:00", also strace
shows the thread opening sound (/dev/snd/*)
exists immediately.
---

2)
Lines commeted out:

#period_size 1024
#buffer_size 4096
(other/higher values for those do not change anything)

Complete opposite behaviour of situation "1"

YouTube   -> NO SOUND
vimeo       -> WORKS
...

---

3)
Initial configuration again with the following changes:

rate 96000 -> rate 48000

Everything works, all videos and sounds have audio.
---

4)
Those are the "rate" values that tested and their result:

rate 44100  -> WORKS
rate 48000  -> WORKS
rate 88200  -> WORKS
rate 96000  -> FAIL
rate 176400 -> WORKS
rate 192000 -> FAIL

The pattern here seems multiples of 48000 (96000 + 192000)
and not an upper limit because 176400 also works.

I assume it's something resampling releated but it's really hard
to narrow down since i don't really get ALSA output from Firefox
like from other software.

Comment 1

[Gingerbread Man]

Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:42.0) Gecko/20100101 Firefox/42.0
20151022152545

Works for me. Setting platform to Linux.

Comment 2

[Christian Birchinger]

I just ruled out a possible ALSA user config issue by removing ~/.asoundrc
and replacing it with a single line of:

   "defaults.pcm.dmix.rate 96000" 

The the basic ALSA default config is active with just a single option to
dmix at 96khz.

Maybe this also makes it easier for other to reproduce the issue on their system.

Comment 3

[Christian Birchinger]

The following steps makes it easy to reproduce the issue
It should rule out most possible user configuration issues:

OK:
1) Empty/default ~/.asoundrc
2) http://www.jwplayer.com/html5/formats/
3) "OPUS IN OGG"
4) Sound plays everything is fine

FAIL:
1) "defaults.pcm.dmix.rate 96000" set in _otherwise empty_ ~/.asoundrc
2) http://www.jwplayer.com/html5/formats/
3) "OPUS IN OGG"
4) Player hangs at 0:00 no sound being played

OK values for defaults.pcm.dmix.rate: 44100 48000 88200 176400
FAIL values for defaults.pcm.dmix.rate: 96000 192000

Comment 4

[Matthew Gregan [:kinetik]]

Can you please retest with a current Nightly build?

Comment 5

[Christian Birchinger]

I've just retested with firefox-51.0a1.en-US.linux-x86_64.tar.bz2 (downloaded 20 minutes ago)
and a completely fresh profile (~/.mozilla removed)

Same broken behaviour, nothing has changed.

I've used the following URL to test this time:
http://www.indexcom.com/streaming/codec/opus/html5.html

~/.asoundrc with _only_ one line "defaults.pcm.dmix.rate 96000" --> Player hangs, no sound.
~/.asoundrc empty --> Music plays, everything working

To make it clear. This is strictly an issue that happens only with raw ALSA usage.
pulseaudio etc. will not run into this problem. However i've looked into the ALSA
backend a bit and noticed quite some magic going on looking at sample rates before
opening the ALSA device. A lot more than the average player, that opens the ALSA device
and let's the sound system (usualy plugin interface) take care of resampling etc.

Comment 6

[tzone]

Since it has an audio processor, why do you even need dmix? Actually ALSA should then use hardware mixing by default.

Anyway, in my case I need it and found also two frequencies (88200, 176400) not working. For me that seems to be a limitation of snd_hda_intel though. Switching into USB mode the usb driver outputs to those frequencies.

But back to where Firefox fails: If any rate conversion above 48000 is required, there won’t be sound. You can hear a crack, when the playback tries to start.
I didn’t experience playback hangs though. Just no sound. Actually Alsa would handle it, but Firefox accesses it obviously in unintended ways. speaker-test works flawlessly, even though it outputs as 48000 mono. This would be also the default rate of Youtube, so I can’t see any valid reason, why it would fail.

Anyway, this whole Linux audio output mess from Firefox would be fixed by a simple change. Don’t try to output to card 0 or the pulseaudio server, but to pcm "default", which can be changed arbitrarily by users. This covers all cases:
If pulseaudio is installed, the alsa-plugin “pulse” would handle piping to pulseaudio. If not alsa users are happy. If jack is used, the plugin “jack” would handle it and so on. Why is it so hard using the single kernel interface handling all Linux sound since kernel 2.4? Its userspace software is completely stable and can handle piping to anything else as required. Trying to do this the other way round is insane/completely unstable.

Comment 7

[Bulk Bug Changes for mreavy's org]

Mass change P2->P3 to align with new Mozilla triage process.

Comment 8

[Byron Campen [:bwc]]

Reporter answered needinfo in comment 5.

Paul, what do you think about this?

Comment 9

[C.M.Chang[:chunmin]]

Hmm...we don't support ALSA anymore. On the linux platforms, officially we only support PulseAudio now.

Comment 10

[Paul Adenot (:padenot)]

Yeah, we don't support Alsa. As usual, if someone wants to fix this and provide a patch, I'll review and merge it.