There are plenty of nifty new features covered in the labs link. More interesting for Linux users is that we have been addressing the graphical performance issues that manifesting starting in 9r115, the version where we had to rework the graphical system due to the new XEmbed support (trying to remember what that bought us... oh yeah: context menus consistent with the desktop). The key to performance? Move away from recommended APIs and use unrecommended ones (without resorting to deprecated APIs).

Anyway, I can certify that this version is notably faster. I have been testing the FP10 beta on my special profiling tool, a.k.a. Asus Eee PC. But I would still like to hear whether you experience measurable performance improvements as well.

• Removing restrictions on use of the SWF and FLV/F4V specifications
• Publishing the Adobe Flash® Cast™ protocol and the AMF protocol for robust data services

Note that this is not about open sourcing the Flash Player (although a non-negligible portion of the Flash Player code is already open source). However, the previous restriction that anyone who looks at the spec technically isn't allowed to create an independent SWF decoder (if documentation EULAs are to be believed) was a point of contention among many open source types. No more click-through EULA embedded in the actual PDF, or so I've been reliably informed.

And if I can find the new documents (there's the traditional SWF spec, while the FLV and new F4V formats have been split out into a new document) on the vast corporate website, I will be sure to link to them. I'm not even sure if they're posted yet. But I'm sure my loyal readers will post links in the comments if they can locate them first.

As many are already aware, there is a new version of Flash Player 9 available. This version is designated 9.0.124 and is available here (standalone Player available here). There are no major features to announce with this release; it's a security fix. This is for your protection, cyber-citizen.

Also, I apologize that this release once again broke package management cryptographic checksums because the filename is the same as the previous release. I will rectify that for future releases.

You may be interested to learn that we just rolled out a new bug base: https://bugs.adobe.com/flashplayer/. This replaces the old wish form. Flash Player Project Manager Justin Everett-Church has more details about the new system. You can vote for your favorite bugs!

This version includes the new Flash support for the standard H.264 and AAC codecs as well as hardware-accelerated fullscreen support (where supported by video hardware and drivers, and specified by a site's SWF). This is also the first official Linux release to support the new XEmbed browser protocol which simply allows a browser plugin on Unix to behave better in a modern desktop environment.

Improvement over the string of beta releases: This new XEmbed-enabled plugin should work with Opera now.

Get it here (.tar.gz, .rpm, and YUM available).

Oh please, click bug, please be be gone!

Go get it. If you find problems, remember that this blog's comment section is not the best place to report them. This is. Also, there are the forums.

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

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).

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.

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.

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

http://www.adobe.com/go/wish

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.

Go get it.