Solved Problems

On this and other forums, many participants put forth a plethora of possible solutions. Thing is, a lot of these solutions solve problems that we don’t have. I present herewith some of the problems that are quite solved already.

  • Rasterization: This refers to painting all of the graphical objects onto a video frame to prepare it for presentation. The core Flash engine takes care of this. It has performed this duty faithfully since Flash 1, a.k.a. FutureSplash. No need to delegate this task to an external library.
  • Audio/Video Synchronization: This is also something that the core Flash Player worries about, believe it or not. The notorious A/V sync problems with Player 7 on Linux were not a result of some fundamental inability of the Player to maintain sync.
  • Audio Output: Perhaps I tend towards oversimplification, but audio output is a matter of building an array of PCM samples and shoving them out to a kernel-abstracted DAC device. In Linux, the official way to do that is with ALSA.
  • Audio Mixing: Similar to rasterization, the Flash core has been mixing its own sounds for years. No need to sub-contract that to a third party library or “framework” that may or may not perform the task as precisely intended.

pieces of the puzzle

There are still plenty of fascinating problems involved in making the official Flash Player run well on Linux (Tinic writes of one we just discovered). The problems listed above are not among them.

15 Responses to Solved Problems

  1. Alex says:

    What was the cause of the notorious A/V sync issues in the not-so-current player then?

  2. @Alex: The A/V sync problem had to do with the way the OSS code interacted with the Flash core in a less than optimal manner.

  3. Zbigniew L. says:

    To achieve better performance it is sometimes worth to use external libraries. Such system libraries are usually optimized so the troubles with gcc would not be so painful. ALSA has hardware mixing support on my Audigy2 card. Why mixing in software?ALSA can mix in software if hardware is not able to this.The same is with software rasterization, why not using hardware accelerated Xrender extension to make fast high quality drawing?Of course these accelerations, libraries use could be autotriggered inside flash plugin to software fallback if they are not present or old.gcc ‘problem’. Linux software is in general open source. You get the sources and build it for machine you use to get best speed. There is no need to do runtime check because sources are build for given machine and use CPU features without redundand checking/switching overhead.I treat such gcc behaviour as feature and like it very much.I understand that ‘binary developers’ don’t feel comfortable. But opensource is majority so such ‘bug’ is not a problem. The same is with flash. Adobe perceives Linux as minority so we have to wait about half a year to have recent flash plugin.

  4. Daniele says:

    By reading your statements it seems you’re engine won’t have a chance to be hardware accelerated. Have you ever considered that aspect? By the way have you had any improvement with statically linking against libstdc++?

  5. named says:

    We can avoid A/V sync issues in flashplayer 7 installing alsa-oss and runnig firefox in this way: aoss firefox. Alsa-oss “causes the application to access native ALSA device files such as /dev/snd/pcmC0D0c instead of OSS device files”

  6. Carnildo says:

    When you use hardware acceleration or offload processing to a library or driver, you’re at the mercy of the quality of the hardware, driver, or library that the individual has installed. By doing it all yourself, it may be slower, but you know it will be done right.

  7. Ali Sabil says:

    Could you please try to drop the habits of a windows developper ?From what I saw until now, you are really doing a nice job with flash player, but you are wasting you time trying to have a self contained flash player: this is not the way it works here.

  8. Chris Hubick says:

    I have an idea! Bundle the Flash player with a whole custom tailored Linux distribution running inside the freely available VMWare Player! That way you can have control over every last detail of the users system! And while you are at it, convert the whole Adobe site to consist of nothing but large JPG image maps, because there is no telling what Browser or Font’s we have installed, and that too could ruin our user experience.

  9. @Ali Sabil: Making a self-contained Flash player has worked for nine major versions, and is what allows Flash content to be consistent in any version of the player. Are you really saying Adobe should offload all functionality to third-party libraries for Linux, completely reversing the point of building a multiplatform player in the first place?@Daniele: Obviously this is not the case. Flash player is accelerated by OpenGL on the OSX platform. I can’t really speak for other platforms though.@Zbigniew L.: Not everybody wants to compile every piece of software they want to use. It may be sub-optimal, but sometimes it’s just nice to download and use a working binary.

  10. Paul Donnelly says:

    I’m amazed that so many people are suggesting that the existing (working!) code should be replaced. It’s almost as if you guys don’t ever want Flash 9 for Linux to be completed.

  11. miguel says:

    @Flash Dev: Please don’t be discouraged by the semi-nasty comments. There are a lot of people patiently waiting and there are lots of businesses losing business from users with our non-flash-8+ enabled browsers.While I’m not a fan of flash myself, I’m quite impressed by macromedia/adobe’s decision to keep considering us linux users. A big thank you to all of the people who fought for the linux plugin.

  12. It is important to balance all aspects, including milestones, deadlines and technology.I would love to see the Linux Flash Player ASAP, since it is an increasing problem here.However, my opinion is that Adobe should try to delegate the most it can to take full advantage of the platform. It is a difficult task, but it is doable.For example, it might use ALSA’s mixing if available, and decay to internal mixing if ALSA is not available.My recommendation would be to dynamically load required libraries as needed in order to not have underused code loaded in memory.

  13. Tim Okrongli says:

    Of course one way to do it would be to just release the player and work on things like native ALSA sound processing and XRender rendering in the background with a low priority.Once a feature is stable enough to work somewhat reliably you add an “Advanced” tab to the settings dialog and add a checkbox for the feature, right underneath a label saying that “THESE OPTIONS ARE EXPERIMENTAL AND UNSUPPORTED. ENABLE ONLY IF YOU KNOW WHAT YOU’RE DOING AND HAVE READ THE DOCUMENTATION.”Possible candidates would be “Enable native ALSA sound mixing”, “Enable XRender rendering”, “Pipe everything through GStreamer” or “Do all disk I/O by directly accessing libata”.Of course you still end up writing code for things the Flash core already does, but at least it keeps the library advocates somewhat happy (and gives us possible slight speedups, which would be very welcome with those of us who regularly run Flash animations fullscreen).

  14. Segin says:

    One thing I just thought about in terms of the sound. Since the Flash player will still be mutually exclusive on sound, can you at least allow other instances of the Player (which would get told “Device or resource busy” when they tried to use ALSA, due to the first instance) to contact the first instance and send it’s audio there, in which the first instance would process it? That would at least make it partially multithreaded.

  15. Dave says:

    Thanks Mike for remembering the Linux crowd and acknowleging that it’s the platform portability of Flash that makes it great.