503691 - ALSA is required to build media backends on Linux

Status: RESOLVED WONTFIX

(Core :: Audio/Video, defect)

Description

[Andraž Levstik]

User-Agent:       Uzbl (Webkit 1.1.10) (Commit 9a32a5f8c8d18d143cf8b4a89531c866679026c7)
Build Identifier: ftp://ftp.mozilla.org/pub/firefox/releases/3.5/source/firefox-3.5-source.tar.bz2

Not everyone use ALSA on linux so requiring this for Ogg support seems extremly absurd. I run OSS so I don't have ALSA.

Talking about this:
checking for snd_pcm_open in -lasound... no
configure: error: Ogg support on Linux requires the alsa library


Reproducible: Always

Steps to Reproduce:
1. Get sources
2. Build while libogg is installed while no alsa-lib
3. Above error happens
Actual Results:  
Fails as stated above

Expected Results:  
Build with Ogg support no matter what sound system one uses.

Comment 1

[Matthew Gregan [:kinetik]]

> configure: error: Ogg support on Linux requires the alsa library

The message is misleading, what it really means is that ALSA is required to build sydneyaudio, which the media decoders rely on.  We can't build the media decoders without sydneyaudio, and on Linux that requires ALSA.

There's an OSS backend for sydneyaudio, but it's not really supported and I'm not sure what state it's in.  I believe it exists to support non-Linux platforms where OSS is the only option.  On Linux, I recommend using the ALSA sydneyaudio backend with the ALSA OSS plugin installed if you're using OSS drivers.

Comment 2

[Andraž Levstik]

Can't really use alsa-oss if one isn't using alsa. I'm using OSS for a reason. It works nicer for me. Being able to select either one would certainy be a benefit. If the support is there why not make it possible to enable it for those that want to use it?

From what I know OSS seems to be mainly unchanging over the time.

Considering that all media software I've tried over the years always supported OSS(mpg123, ogg123, mplayer) I don't see a reason to just dump it. I doubt the OSS api is much diffrent between the other systems and the linux oss(or oss4 which I actually use).

Comment 3

[Matthew Gregan [:kinetik]]

I'm referring to the OSS plugin from the alsa-plugins package, which allows the  ALSA API to use OSS audio drivers.  It's a bit confusing, as there's also an alsa-oss package, which maps the OSS API to ALSA for applications that only provide OSS support.

That seems like the best solution, as developers can target one API (ALSA), and users can configure the ALSA library to use an OSS, ALSA, or PulseAudio backend plugin depending on their preferences.  Since ALSA (and, in the future, PulseAudio) is the standard audio configuration on all major Linux distributions, that's what makes sense for Firefox to target.

Comment 5

[Shmerl]

> Since ALSA (and, in the future, PulseAudio) is the
> standard audio configuration on all major Linux
> distributions, that's what makes sense for Firefox to target.

I'll argue about that. There is no such thing as standard audio subsystem for Linux. ALSA is commonly provided by default because of historical reasons (OSS stopped being open source for a period of time before, and thus fell into disuse, but it became back open with OSS4), but no one made it "a standard". One can switch at any time, because OSS4 provides certain benefits over ALSA (it's also more cross platform and more Unixes can use it, while ALSA is Linux specific). OSS4 is a valid option for many Linux users because it tends to have better sound quality than ALSA or PulseAudio.

Firefox for Solaris/OpenIndiana for example is currently using Boomer sound subsystem which is based on OSS. So why not to make it a runtime configuration option, rather than requiring one to recompile Firefox to support other sound subsystem?

Sydneyaudio claims to support OSS. So what is the problem?

Comment 6

[Matthew Gregan [:kinetik]]

You're not arguing against what I actually said.  I said that *all major distros* default to ALSA (and, increasingly, PulseAudio).

As I said in comment 1 and comment 3, you can already use the OSS sound backend (with runtime switching) by using the OSS backend plugin for ALSA.

As I have also already said in this bug, the OSS code in sydneyaudio is unsupported and untested.  That, along with a lack of maintainers for that code and a desire to reduce the proliferation of audio APIs on Linux, is the problem.

If someone wants to submit a patch to add a configure flag for OSS (that defaults to ALSA and requires asking for OSS explicitly), they're free to do so.

Comment 7

[Shmerl]

I'll look into making it a configurable dynamic choice. So far (if someone needs it) the workaround with alsa plugins for OSS4 requires this configuration in /etc/asound.conf

pcm.oss {
    type oss
    device /dev/dsp
}

pcm.!default {
    type oss
    device /dev/dsp
}

ctl.oss {
    type oss
    device /dev/mixer
}

ctl.!default {
    type oss
    device /dev/mixer
}

Comment 9

[Sven Müller]

I opened Bug 646009, which is a duplicate of this one. 

I've never heard about sydneyaudio. Wouldn't it be better not to use something exotic like sydneyaudio and switch to a standard lib which is installed on most linux systems like gstreamer or phonon?

In the last months my soundcard wasn't supported by OSS4 yet. So I had to switch to alsa temporarely. After switching back to OSS4 I was shocked by the sound quality improvement. So why do you want to force a low quality system? I don't want to install anything of the alsa stuff.

Comment 10

[cajbir (:cajbir)]

See bug 623444 comment 1 which seems to indicate that PulseAudio is the goal for the Linux audio backend.

Comment 11

[Shmerl]

PulseAudio so far is inferior to other audio backends. It's not reasonable to force users to use a certain backend, and to say that "that's the goal for Linux".

Take Google Voice / Talk plugin example. It is so strongly coupled with ALSA that can't work with OSS4 even with ALSA emulation mode. So it's an example of poor design. For high level applications it makes sense not to use low level audio API at all, in order to avoid to be tied to it. Let user decide what low level backend to plug in, and application should use some higher abstraction level which should take any available backend. That's a normal design.

Comment 12

[Sven Müller]

PulseAudio is the wrong way in my opinion. PulseAudio is a really nice solution to stream audio data over the network. But to use the Ubuntu way to misuse Pulse for the weakness of Alsa (=Software mixing) seems not the right goal. In that case it's just unnecessary overhead. For an ordinary computer user PulseAudio does not give your a single advantage. Worse you have to wrap the sound data through another useless layer.

On a linux machine you need a low-level soundsystem. For that you have: 
- Alsa
- OSS4

One level above you have the abstraction for audio and video data. This is:
- xine
- Gstreamer
- Portaudio
- Phonon
- Libcanberra
- SDL
- libao
- PulseAudio


SDL and libao are used in games, Portaudio I don't know. Phonon is used in Qt and KDE on top of GStreamer. Libcanberra belongs to Gnome and has also GStreamer support. Pulseaudio is for network audio streaming. Xine is deprecated and was replaced by GStreamer too in KDE-4.x. 

So the most logical choice would be GStreamer. In opposite to PulseAudio it's quite stable. It doesn't need another useless daemon to run. It's a high-level-API and quite easy to implement.

Links:
http://www.tuxradar.com/content/how-it-works-linux-audio-explained
Very interesting to read:
http://insanecoding.blogspot.com/2007/05/sorry-state-of-sound-in-linux.html

I really hope you'll think again about your goals. Don't make a fanatic religion of it. Just think about the facts.

Comment 13

[Nikos Chantziaras]

(In reply to comment #12)
> [...]
> SDL and libao are used in games, Portaudio I don't know. Phonon is used in Qt
> and KDE on top of GStreamer. Libcanberra belongs to Gnome and has also
> GStreamer support. Pulseaudio is for network audio streaming. Xine is
> deprecated and was replaced by GStreamer too in KDE-4.x. 
> 
> So the most logical choice would be GStreamer.

Linux audio is a mess :-)  Even you got the above wrong for example.  KDE deprecated Xine *and* GStreamer.  It now uses VLC.

So good luck with making a choice that everybody will like and approve :-P

Comment 14

[Sven Müller]

(In reply to comment #13)
> Linux audio is a mess :-)  Even you got the above wrong for example.  KDE
> deprecated Xine *and* GStreamer.  It now uses VLC.
> 
> So good luck with making a choice that everybody will like and approve :-P

You are right. I was outdated. I didn't use VLC, I even didn't install it yet on my machine. Because of using mplayer as standard video player there was no need to install VLC parallel to it.

But VLC is available on all major platforms (Linux, Mac, Win). So why not use that API for all systems? It sounds a good idea to me. At least it's a lot better than the combination of ALSA + PulseAudio.

Comment 15

[Nikos Chantziaras]

(In reply to comment #14)
> [...]
> But VLC is available on all major platforms (Linux, Mac, Win). So why not use
> that API for all systems?

Because stuff like GStreamer, Xine and VLC are multimedia APIs, not audio APIs.

For something universal, Firefox's choices basically boil down to: PulseAudio, SDL and OpenAL.  I'd go for OpenAL, which supports both ALSA and OSS and is also available on all platforms. OpenAL also supports PulseAudio.

Comment 16

[cajbir (:cajbir)]

(In reply to comment #15) 
> For something universal, Firefox's choices basically boil down to: PulseAudio,
> SDL and OpenAL.  I'd go for OpenAL, which supports both ALSA and OSS and is
> also available on all platforms. OpenAL also supports PulseAudio.

I originally used PulseAudio in the original video element version. I had a number of issues with it and decided to change to something else.

My preference was OpenAL. Unfortunately the license was not suitable (LGPL) and it wasn't clear how to get OpenAL installed on Windows machines since the license of the installer required packaging the binary IIRC. In hindsight it was a good choice not to use it as we also want to move to a callback API where the sound system notifies us when it wants sound to be written rather than us having to poll. OpenAL doesn't have a callback API that I know of.

SDL (and libao for the person who suggested that) doesn't have an API of obtaining the current position of the audio playback buffer. We need this for A/V sync.

libsydneyaudio was used for a browser plugin that emulated the audio/video API which is why we went for that. It was known to work and licensing was compatible.

That's the history of the choices. I'm sure the developer of the new API is considering all the requirements for Firefox. If you want to suggest ideas it would be great if you could take it to the newsgroup mozilla.dev.platform instead of posting in a closed bug. We do appreciate the feedback and ideas. Thanks!

Comment 17

[cajbir (:cajbir)]

(In reply to comment #16)
> I originally used PulseAudio in the original video element version. I had a
> number of issues with it and decided to change to something else.

That should be PortAudio, not PulseAudio. PulseAudio didn't exist then.

Comment 18

[Nikos Chantziaras]

(In reply to comment #16)
> (In reply to comment #15) 
> > For something universal, Firefox's choices basically boil down to: PulseAudio,
> > SDL and OpenAL.  I'd go for OpenAL, which supports both ALSA and OSS and is
> > also available on all platforms. OpenAL also supports PulseAudio.
> 
> I originally used PulseAudio in the original video element version. I had a
> number of issues with it and decided to change to something else.
> 
> My preference was OpenAL. Unfortunately the license was not suitable (LGPL)

Isn't the LGPL pretty much compatible with everything, all the way from open source to proprietary closed source projects?

> and
> it wasn't clear how to get OpenAL installed on Windows machines

Since you're not going to use PulseAudio on Windows, there's no reason to use OpenAL on Windows either!

Comment 19

[Boris Zbarsky [:bzbarsky]]

> Isn't the LGPL pretty much compatible with everything

Please see http://www.mozilla.org/MPL/license-policy.html#Licenses_Compatible_with_the_Tri-License

Comment 20

[Nikos Chantziaras]

(In reply to comment #19)
> > Isn't the LGPL pretty much compatible with everything
> 
> Please see
> http://www.mozilla.org/MPL/license-policy.html#Licenses_Compatible_with_the_Tri-License

Hm. Isn't ALSA LGPL too?  Firefox seems to be using it currently.

Comment 21

[Matthew Gregan [:kinetik]]

Firefox does not ship any ALSA code.

As Chris said in comment 16, please take this discussion to the newsgroups.  Seriously.  Bugzilla is not a discussion forum.

Comment 22

[TAXI]

Attachment: Replaces alsa with oss support

I know, this bug is closed.
But this close isn't good for the users so I will ignore it and post this little patch, based on this one: http://bugs.gentoo.org/show_bug.cgi?id=276354#c5

This patch will disable alsa support and enable oss support in the firefox sources.