Click Me

The oft-reported click bug that showed up in the last 2 beta releases of the Linux Flash Player 9 Update finally manifested on a machine in our own lab. The problem turns out to be an artifact of the simple fact that no two Unix window managers operate the same way.

Anyway, the next release will have the fix. No, I don’t have any date for the release.

H dot two sixty four

There is a new beta of the Flash Player Update available. That’s right: the beta is even available for Linux (same time as Windows and Mac). Download it here.

This beta is affectionately named Moviestar due to these key new features:

  • H.264 video
  • AAC audio
  • Hardware-accelerated fullscreen video playback (new for Linux in this beta; Win/Mac had it in previous beta)

Yep– fullscreen hardware acceleration during video playback using OpenGL/GLX on Linux, where available… and functional. If you find that it does not work right, you can disable hardware acceleration using the “Settings…” menu from the right-click context menu. Oh, and file a bug with hardware details, video card driver version, GLX version, that sort of stuff.

If you have any questions about the new audio/video stuff, check Tinic’s thorough blog post on the matter.

I would also like to hear if anyone is still experiencing the click bug (where no events are triggered in response to mouse clicks).

New Installation Method

So many ways to do things in Linux, like installation. Some users may be pleased to learn that we now support another method for installation, YUM. Get it on the official Flash Player 9 download page, in addition to the .tar.gz and .rpm packages (this is for the latest release, not the beta update announced yesterday)

Fullscreen Beta

Check out the new Flash Player 9 Update 3 beta, also available in Linux flavor, available here. The most notable features of interest to Linux users: Fullscreen mode works on Linux, and the entire thing has been reworked as a native GTK app that communicates with the hosting web browser using the XEmbed protocol. Hopefully, your favorite Linux web browser also holds up its end of the bargain by hosting XEmbed applications.

Welcome To The Jungle

I have been programming multimedia-type stuff on Linux since 1999. I have long observed that there are many, many, many methods of programming audio. By “programming audio”, I generally refer to the act of programmatically taking an array of numbers that represent an audio wave’s discrete amplitude levels over time, and shoving that array out to a digital-to-analog converter (DAC). This is how a modern computer makes noise, cooling systems notwithstanding.

There are 2 primary methods of sending audio data to a DAC under Linux: OSS and ALSA. OSS came first; ALSA supplanted OSS. Despite this, and as stated above, there are numerous different ways to do the DAC send. There are libraries and frameworks that live at a higher level than OSS and ALSA. In the end, they all just send the data out through OSS or ALSA.

The zaniest part is that some of these higher level libraries can call each other, sometimes in a circular manner. Library A supports sending audio through both OSS and ALSA, and library B does the same. But then library A also has a wrapper to send audio through library B and vice versa. For that matter, OSS and ALSA both have emulation layers for each other. I took the time to map out all of the various libraries that I know of that operate on Linux and are capable of nudging that PCM data out to a DAC:


Click for larger image

graph source, if you’re interested

I love you, Graphviz!

The green cell is the audio data’s final destination. The three colored boxes that live one layer removed from that green box depict the subsystems that actually send data to audio hardware. I admit that this exercise educated me about an output system I had not yet heard of — FFADO, for FireWire-based audio devices. All of the remaining boxes depict the higher layered libraries. I’m pretty sure each has been recommended by blog readers as the Flash audio output system.

Methodology: I downloaded the source code for each library contender; grep’d through the filenames for “alsa” or “oss” based on the assumptions that A) these libraries would all support one or the other, and B) that these libraries tend to be modular and this would lead me to where the output modules congregate; investigated the output modules that lived alongside the OSS and/or ALSA modules.

Why would a higher level library be useful? One oft-cited rationale is to enable playing more than one audio stream out of a device that only supports one audio stream. The library will handle the multi-stream mixing in software and send the final wave out to the device. However, ALSA also handles this.

Another major alleged selling point for many of these libraries is the promise of cross-platform compatibility. I.e., code to one of the libraries and it will make noise on lots of systems, not just Linux. Windows and Mac are often on the list, among many others. However, Flash has longstanding and well-debugged platform-specific code for pushing out that array of audio samples for Windows and Mac, so that’s not exactly a concern for this project.

May 12, 2007 Update: Thanks to all the commenters who have helped me recognize that this web is even more tangled that I had first thought possible. Added libao, added more lines from GStreamer’s box to other boxes; I also know of Phonon but I’m not convinced that it’s designed for the simple purpose that Flash Player would need.


For future releases of the Adobe Flash Player for Unix platforms, we would like to use a better method of integrating with the encapsulating web browser. This method is known as XEmbed. It is supported by some Unix web browsers but not all. Naturally, the best reason for a browser to support this interface would be if the Flash Player supported it. But without a reasonable test plugin, browser authors are a little stuck.

That’s why I threw together such a test plugin. Further, my corporate masters have authorized me to release it as open source! I call the plugin DiamondX. It operates by drawing a diamond in the specified plugin space as such (note that this is a static image and not the actual plugin in action):


The plugin can pop up a few modal dialog boxes which ought to be honored by the browser. There is a better-looking context menu than the one seen in the current Flash Player. Via the standard output, the plugin will also communicate which relevant events it is receiving. And get this: Keyboard focus should not follow the mouse with this example plugin!

There will hopefully be more iterations of this plugin as I plan to use it as a testbench for implementing windowless support (a.k.a. wmode, transparency) in the plugin. This way, Linux can finally be on equal footing with Windows and Mac for displaying the kind of advertisements that take over the entire browser window. And I know Linux users want that. Seriously, there are legitimate uses for said feature as highlighted by the oft-reported “Javascript menus are covered by SWF” bug.

So download DiamondX, compile it, and try it out with your favorite browser. If your favorite browser does not yet have XEmbed support, you may wish to ask the authors to think about implementing it.

Expanded Platform Support

The fact that Flash Player 9 Unix support is presently limited to Linux/x86 has been the source of some consternation to the users of some non-Linux/non-x86 Unix systems. You may be interested to learn that Unix platform support has recently been expanded. There are now beta versions of Flash Player 9 available from Adobe Labs to support Solaris on both x86 and Sparc CPU architectures.

Feedback on the beta version is, as always, welcome.

Building A Better Bug Report

A common exchange in the previous length thread deals with the proper place to enter bug reports. Here it is:

Now that I have posted this information, I will revert to the previous policy of unceremoniously deleting bug reports that are posted as comments to any blog entries.

Let’s look at those fields on the bug report form:

  • Name and email– you may not like to surrender this information but if we can’t reproduce your bug report and we can’t follow up with you for more information about your unique configuration, we have no choice but to dismiss your bug report.
  • Product name: Please be sure to select “Flash Player” so it gets routed to the right place; not “Flash Lite Player” and certainly not plain “Flash”.
  • Remember to select Browser; you can safely disregard web and app server and database fields.
  • The correct OS is also important to select for proper handling.

We’re always particularly interested in crash bugs, especially ones that bring down the browser every time. Obviously, these don’t happen with our many configurations in-house (not even with Firefox 2, which I’m currently using on my Gentoo dev box) or we would fix them before the Player got out the door.


Flash Player 9 For Linux (x86)

This is it. This is the officially blessed version of the Adobe Flash Player 9 for Linux (x86). Not a beta version; the final version. It’s released. Today.

Go get it.

Beta II: The Audio Fix

As indicated, we’ve been working diligently to fix issues that were found in our original Flash Player 9 for Linux beta. Most notable of these problems is audio output. We are eager for users to test this version and see if the myriad sound problems have cleared up.

As before, please log problems through the proper channels (feedback form or support forums). This blog’s comment forum is not appropriate for tracking problems.