Hear This

The Advanced Linux Sound Architecture (ALSA) is the standard choice for audio output under Linux these days. Thus, that is the audio API we will be coding to for Flash Player 9.

My question is: Is there a compelling reason to support Open Sound System (OSS) from here on out? There are other areas we’d like to work on and if we can avoid having to invest resources maintaining the legacy OSS module, that’s one less item on our list of things to validate.

Some have suggested that we use one of the multimedia framework solutions available for Linux. Recommended candidates include GStreamer and xine. I know xine quite intimately and I seriously don’t believe that this approach makes sense. GStreamer might be more plausible, based on my reading of their literature. However, this approach seems to add more layers than is really necessary. I know I tend towards oversimplification, but audio programming is generally a matter of opening and configuring the audio interface and then either writing a buffer of samples (audio playback) or reading a buffer of samples (audio recording). That’s not especially complicated.

33 Responses to Hear This

  1. Kyle Brantley says:

    First off, THANK YOU SO VERY MUCH FOR ALSA SUPPORT. It means the world to many linux users :)Second, OSS is marked in the kernel as depreciated. Or, “don’t use this, we’ll remove it soon.” When is “soon”? I couldn’t tell you, but note that as far as the offical linux kernel is concerned, don’t use OSS.On gstreamer and xine: don’t waste your time. Really, do you want to bundle a browser plugin that requires external libraries? I really think that would be a first for the flash viewer. The flash viewer exists to play .swf files, easily and in a simple manner. Adding deps (gstreamer or xine) is almost counter-productive.

  2. TTimo says:

    Using SDL and SDL_mixer would make sense. They will do the lower level work talking to Alsa or OSS for you. The added layer of dependency would be worth it.I have to maintain OSS and Alsa backends for my own projects, if you have to pick a single one, you want to go with Alsa.From a technical standpoint however, I like OSS API better than Alsa. Some will argue that Alsa “does more”, and use that as an excuse for it’s crappy API design 🙂

  3. Have you considered OpenAL? Or does flash have its own 3D audio functionality?

  4. Sterling Christensen says:

    I’m reading http://www.opensound.com, and it looks like OSS now has an ALSA compatibility layer.

  5. Frank Daley says:

    I would highly recommend corresponding with some of the long time Linux audio hackers such as Paul Davis, Ingo Molnar and Lee Revell.Also check out the Proceedings from the 4th International Audio Conference here >http://lac.zkm.de/2006/papers/lac2006_proceedings.pdf> including a paper by Lee Revell on Linux and Real Time Audio. It is pretty clear that support for at least ALSA is essential.frank

  6. Lapo Luchini says:

    Why using an higher-level API?Well, as an example a good reason is to be more easily compatible with different platforms.I guess SDL would do (it’s small and available more or less everywhere), but anything “higher” can do.Please do not forget about the 1830 petition signers asking for Flash support on FreeBSD: right now it is barely usable (using Linux ABI emulation), using ALSA it would be definitely out of question. That would be a sad thing indeed.

  7. Kai F. Lahmann says:

    Just forget OSS, it’s quite dead. Biggest problem: it needs hardware support for mixing (which more or less no hardware has, as Windows doesn’t need it). But do not add dependencies on libs, which still have living alternatives (gstreamer vs. xine). Or do you mean the other way arround – like allowing all gstreamer-based video apps to play flash files? 😉

  8. Janez Komac says:

    Thank you for this great news about using ALSA in Flash for Linux. As far as I know everyone is using ALSA this days. I’ve only seen it once that someone used OSS. It was my coworker who had an extremely old soundcard and ALSA didn’t have the driver for it. Well even he has upgraded his system now and uses ALSA for the new soundcard. So I think OSS. I think OSS support should be dropped and the time saved spent on more important things like 64-bit binary for AMD64 computers.

  9. John Koleszar says:

    ALSA is probably the way to go on linux only platforms, but using it does tie you pretty closely to linux as a kernel. OSS is much friendlier to those who would hope to use the linux binary under Solaris or FreeBSD (via the linux ABI wrapper) and to Solaris users (do you still support that?) that use non-Sun audio hardware. ALSA emulates OSS quite well, so the fact that it may disappear in the kernel probably isn’t a big deal.If you’re committed to going ahead with ALSA now, I’d continue OSS support as a fallback. If I got to choose, I’d fix OSS first, and add ALSA later.

  10. David Chait says:

    I was actually going to ask if you’d looked at OpenAL as well. It certainly gets you closer to the hardware — and closer to the top hardware manufacturer (Creative, since they are still the core maintainers…).-d

  11. TTimo says:

    I didn’t mention OpenAL assuming all you wanted was sound output.But I agree with Jeff, if you have needs mixing and 3D positional sound , then OpenAL is a great choice. Would cover all platforms as well, not just Linux.Also worth mentioning that Creative announced they will be releasing closed source hardware accelerated drivers supporting OpenAL for their hardware. The API still has a good amount of support out there.

  12. Mikael Eriksson says:

    Keep OSS since it can be used under other OSes using linux emulation.Or you might want to take a look at libao which has support for:# OSS (Open Sound System, used on Linux and FreeBSD# ALSA (Advanced Linux Sound Architecture)# polypaudio (next generation GNOME sound server)# esd (EsounD or Enlightened Sound Daemon)http://www.xiph.org/ao/

  13. Xiph’s libao seems like an interesting solution. However, is there an analogous libai for audio input? Flash Player also needs to be able to record audio.

  14. Ilya Konstantinov says:

    Using GStreamer makes sense if you want to leverage its codecs and pipeline — e.g. if you’ll design your graphics code as a GStreamer component. Obviously you won’t be doing that, as you probably already have your on SWFish concepts of things and I’m not sure how well they fit into GStreamer’s pipeline, and also since you’d be shipping with an MP3 decoder and video decoders licensed by Macromedia for the Flash Player’s sake. As to simply shoving your PCM stream down the sound device, I don’t think GStreamer does anything overly smart in that regard. As long as you use ALSA’s libasound, you already have userspace software mixing and an option to redirect to an external sound daemon.I think it’s too late at this point to redesign your Flash Plugin around the GStreamer architecture… and do I hope you have enough code already to justify my claim 🙂

  15. James C says:

    Well, SDL supports almost all OSes out there natively, has ALSA support on Linux (most importantly)(has OSS also) and does input as well as output with video too: http://www.libsdl.orgPlenty of games have been ported using SDL so it seems powerful enough to handle anything.

  16. Given the fact that OSS has indeed been deprecated, and the overwhelming lack of format standards in the linux world I think you should forget about OSS suupport. When you have to produce a real-world product sacrifices have to made.

  17. djurban says:

    note also that gstream has a very unstable api

  18. I can’t see any reason for an oss support of flash player.But one *big* wish: Please consider that there are users with two or more soundcards. This is one of the most anoying things of Flashplayer 7: I can’t change the device, so it plays on the wrong soundcard. It would be great to choose which ALSA device Flash is using (a simple configfile hack in Flash 9 would be enough for me :->).

  19. Ilya Konstantinov says:

    Markus, on ALSA, it’ll simply output to the “default” device, and you can map it to anything in your /etc/asound.conf or ~/.asoundrc.

  20. Oded Arbel says:

    Most important for me would be to have ALSA dmix supported, so I can play many things at once (i.e. – not have flash sound muted just because I have a song playing in amaroK, or worse – the other way around).OSS emulated by ALSA works fine for me with dmix so I think thats a valid option, while some ALSA supporting players (notably mplayer) fail to open the card when another app is playing – so please be careful to make sure Flash plays nicely with other ALSA using apps.

  21. bloody says:

    Ok two things :1. It has already been said OSS emulation through ALSA is a hack and leads to random browser crashes. And I have experienced it.2. Using SDL is more than probably not an option as it’s licensing is not compatible with theirs and furthermore it’s a big external dependency.

  22. Tobu says:

    I think you need to consider sound servers.Sound servers are a desktop-oriented technology that handle several audio streams, mix them using hardware acceleration if available, and allow the user to control the volume of individual streams. The state-of the art in this domain is polypaudio. It is portable, can output to any hardware on any platform (ALSA, OSS, Jack, windows, BSD, mac), takes input from almost anything (gstreamer, libao, mplayer, OSS emulation, the legacy esd sound-server), and is well-maintained.Writing audio to a sound-server is like writing audio to the OSS API, it is low-level and quite simple. The polypaudio plugin to libao is barely 140 SLOC.You can also target libao (which is a lightweight, portable, low level output library), it can output to Polypaudio, OSS, ALSA and more, works on any UNIX (BSD, solaris, linux) as well as windows.You could target libSDL, but I don’t think it has any benefits to libao (it can do mixing and mp3 playback too, but it’s a software implementation).You could target ALSA, but sound servers won’t be aware of your streams; the ALSA API has some high-level parts that mean it can’t be emulated by a sound server.Finally you could target the OSS API. Even though OSS is deprecated in linux, the ALSA implementation of OSS is entirely supported, and it’s a sensible API to support. In this case, you should target the OSS library (I’m unsure about that, but I think using the DSP has some limitations). This solution is still compatible with sound-servers, because sound-servers are able to emulate the OSS API, just as ALSA does.I think your best option is to target libao, although targeting polypaudio, OSS, or SDL aren’t bad options. But I don’t think targeting the ALSA _API_ option is interesting, because you don’t need the high-level parts and you would cut yourself from sound-servers. If ALSA dmix isn’t enabled (which would be stupid, granted), you could even be barred access to the audio hardware.http://www.xiph.org/ao/doc/overview.htmlhttp://0pointer.de/lennart/projects/polypaudio/

  23. Tobu says:

    Mmmh, I’ve found out there /is/ a way to make alsa use polypaudio (now pulseaudio); it’s an alsa sink plugin, and it is in ALSA CVS. So ALSA is OK after all :)http://alsa.cvs.sourceforge.net/alsa/alsa-plugins/polyp/polyp.c?view=log

  24. Ygor Lemos says:

    Hi!!First of all, congratulations for the work. Personally I know some hundreds of linux people desperate for a decent flash plugin, and we are surely following your work! Thanks!I think that the defacto solution is to use ALSA.ALSA is far better and used than OSS. OSS is almost off-specs and should be avoided for development.Please!! Don’t use audio frameworks. It will require the users to install x or y audio-frameworks and this sux. After all, many of us uses Linux because we want freedom… and the most global solution that will attend the vast majority is indeed ALSA.xine, gstreammer, fest, etc… should be avoided on this specific case.Some might mention the ESD, as it is the default on some Linux distros. But even with that, you should keep ALSA as the MAJORITY of people use it.Perhaps you could implement a solution for support multiple audio engines, perhaps classes inside the system to support at least the most common sound servers and architectures, for this I recommend: ALSA, ESD, OSS, Arts (directly play on Arts for KDE users), GStreamer and Xine.Developing a plugin that automatically detect (or have a configure file somewhere) those sound systems will surely make all penguinists happy forever!Cheers and Good Luck!

  25. liquidat says:

    Well, my two cents:First of all: nice done – I really waited for that for mainly one reason: the only real and stable option to use flash at the moment is for me to wrap it with arts – but that introduces horrible delays.So I will like a alsa output because it will work nice together with all the other apps.About other here mentioned things:- sound servers are a bad idea because they add delays – every watched a movie in flash with half a second delay? That’s not usable.- OSS: it would be cool to have this as a fallback plugin – that would help the non-Linux guys – although I sometimes wonder why they do not take care of improving their OSS…About other plugins like frameworks (gstreamer, phonon) and this stuff: sure, would be cool, but start with ALSA. If you have time after it, well, do it…

  26. jayKayEss says:

    Beware: aRts is deprecated and unmaintained (plus it kinda sucks.)I would love to see either ALSA or SDL support._SO_ happy to see Adobe bringing Flash for Linux back up to speed– thanks!!!

  27. Anonymous says:

    as several people have said before, using ALSA would make flash player unuseable on freebsd.i’d recommend SDL, but i haven’t looked at whether there would be licensing issues as someone else suggested… other than that, your best option would probably be OSS…

  28. Micha says:

    Please do not use ALSA. It is a Linux only solution and breaks the Flash plugin on other platforms. (*BSD and perhaps even Solaris users ARE using the current Linux plugins!)If you have to use alsa, use it via some portable framework that really *is* available on all the platforms.

  29. Jon says:

    I also would really like to see SDL support instead of ALSA (even though I’m a Linux user and have an ALSA card).

  30. Jon says:

    Oh and please please please allow for the selection between multiple sound cards for microphone input in Flash player’s right click Settings page (like is possible in the Mac and Windows version of the Flash player) instead of defaulting to /dev/dsp.

  31. Shish says:

    Personally, I find audio output is *far* more important than input. As such I request you use something like libao or SDL, which both have a load of fallbacks so sound output pretty much never fails.If sound input is that important, would you consider using one of the abstraction layers for output and pure-alsa for input?

  32. there is a major difference between (deprecated) OSS in the kernel and http://www.opensound.com‘s driver. The latter outpewrforms on almost any area what alsa does.Asla may be used with a compatibility layer eventually. So far I haven’t heard any sound from flash 9 if http://www.opensound.com‘s software is installed. Alsa works fine but fails in several other areas. It seems that opensound support is dropped?

  33. Silvan says:

    Was anybody able to run alsa with jack audio server? Setting pcm.!default with jack as slave.pcm will result in opening an indefinite number of connections to jack until the browser (firefox or konqueror) crashes with a lot of “cannot deliver port registration request” messages and a final “too many open files”, segmentation fault. I’m not satisfied with the chioce of just supporting ALSA in flash, is it supposed thaton Linux we should hear sound from just an application at a time?