Bug 117079

Firefox is using ESD for sound output but neither Flashplayer nor Realplayer
does use Firefox' sound output at all. So why is this a Firefox bug?
I would suggest to file bugs for Realplayer and Flashplayer then. If you agree
please change the component for this bug or close it as INVALID.

I see otherwise:

# lsof /dev/dsp
COMMAND    PID     USER   FD   TYPE DEVICE SIZE  NODE NAME
firefox-b 7042 cmeadors   37u   CHR   14,3      10830 /dev/dsp

That to me indicates that Firefox is using OSS, because esd uses alsa now.  And
the aoss hack would be most convenietly added Firefox because it would trickle
down to the apps that it spawns and to the plugins.

There are rumours that Realplay will optionaly use alsa in the next release
which would solve that problem.  However I am unaware of how to add an
LD_PRELOAD hack to a plugin without adding it to Firefox.  Flash is closed
source so we have limited options there.

> That to me indicates that Firefox is using OSS, because esd uses alsa now.

Plugins run in the browser process, so that could just indicate Flash or Real
are in use.

I see.  I thought what I was testing was not flash or real, but it turns out to
be flash.  What would be an appropriate test determinig the sound device that
Firefox uses to play sounds?

Try moving the plugins out of the /opt/MozillaFirefox/plugins directory (check
about:plugins to ensure they're gone) and then make a sound?

As said Firefox itself does only use ESD:
http://lxr.mozilla.org/aviary101branch/source/widget/src/gtk2/nsSound.cpp

We can't do anything here for Flash or Realplayer.
But maybe Firefox should use Alsa directly in the future. But this can be only a enhancement request.

Anyone: Does it make sense to start Firefox with LD_PRELOAD=/usr/lib/libaoss.so ?
Will it fix all problems?

hmm, I just ran XMMS (alsa output) together with a flash within Firefox and I was able to hear both sounds. I'm not sure if we still have a problem here?
Or does it only interfere between two OSS device users?

AFAIK, many sound cards support hardware mixing, it can use more streams nativelly. Cheap onboard cards can use only one stream, but most of these devices is covered by ALSA dmix software mixer. This work for ALSA devices, but not for alsa-oss. If you use aoss, all OSS calls are redirected to ALSA and dmix works. We use aoss for RealPlayer in 10.1, too.


Please use correct aoss (e. g. \$LIB, not lib) preloader code to support bi-arch (or use aoss binary). Current aoss wrapper is:

prefix=/usr
exec_prefix=${prefix}
LD_PRELOAD="$LD_PRELOAD ${exec_prefix}/\$LIB/libaoss.so" exec "$@"

hmm, I've tested and it seems to work, though I don't know what \$LIB means exactly. At least I've tested with 32bit Firefox on a x86-64 system and it used the 32bit libaoss.so which is correct.

Reopening. Bug appears again in 10.3.

LD_PRELOAD in the firefox wrapper is inccorrect and does not work with nspluginwrapper

ERROR: ld.so: object '/usr/lib64/libaoss.so' from LD_PRELOAD cannot be preloaded: ignored.

Proposed fix (firefox):

remove these lines:

LIB=lib
echo $mozilla_lib | grep -q -E 'x86-64|s390x|ppc64' && LIB=lib64

And fix this line:
export LD_PRELOAD=/usr/$LIB/libaoss.so${LD_PRELOAD:+:$LD_PRELOAD}
to
export LD_PRELOAD=/usr/\$LIB/libaoss.so${LD_PRELOAD:+:$LD_PRELOAD}

It would be nice to release this with the next security fix.

Additionally, you have to ensure, that both 32 and 64 bit versions of this library are installed.

As \$LIB is not a SuSE specific feature, this bug should be upstreamed.

Related: bug 208817, bug 119413

Oops: Variable $LIB is used also by firefox itself for searching for plugins.

So here is a fixed version of the fix:

change
export LD_PRELOAD=/usr/$LIB/libaoss.so${LD_PRELOAD:+:$LD_PRELOAD}
to
export LD_PRELOAD=/usr/\$LIB/libaoss.so${LD_PRELOAD:+:$LD_PRELOAD}
and nothing else

It's fixed in Factory, but the fix is not fully correct:

  if [ -d /proc/asound -a -e /usr/$LIB/libaoss.so ]; then
    export LD_PRELOAD=/usr/\$LIB/libaoss.so${LD_PRELOAD:+:$LD_PRELOAD}
  fi

It will cause errors, if alsa-lib and alsa-oss-32bit is not installed and nspluginwrapper is in use.

I wonder if that is still that important? Flash is using ALSA since version 9. So the most common used application shouldn't cause issues anymore.

At least it causes ugly error messages.

Fixed in the correct place:

aoss.changes:

Fri Mar  7 10:37:39 CET 2008 - sbrabec@suse.cz

- Added bi-arch counterpart Requires to prevent arch clashes
  (bnc#117079#c14).