WebRTC alsa support requires libasound 1.0.14; currently our Centos 5 build slaves have 1.0.12 (current Centos 5 libasound is 1.0.17). 1.0.14 was released in June 2007. We either have to update libasound in our build infrastructure and decide that Linux versions/installations older than that aren't supported for WebRTC, or we need to modify the code to bind the symbol optionally, and if it isn't bound to provide a simpler "select a device" interface. This won't be a great experience for users, but would work, especially if they use the "default" sound device. Using headsets and the like might be painful (knowing which device they are) unless you change the OS default first.
Based on the following comment, I think we should update the linux build slaves to at least an up-to-date RHELv5 (or at minimum update libasound). This is going to become a hot issue soon as we start thinking about landing at least part of webrtc on trunk for image capture, and we start looking at alder-based branch builds and demos. Comment from jmvalin on 10/20/2011: I did a quick check for version of Linux distros using alsa versions older than 1.0.14 and here's what I found: Ubuntu: - Oldest supported version (only on server, desktop expired) is 8.04 LTS (Hardy Heron) and includes 1.0.15 ( see http://packages.ubuntu.com/hardy/libasound2/libs/ ). Redhat: - RHEL v5 ships 1.0.17 (see http://rhn.redhat.com/errata/RHBA-2009-0088.html ) and is currently in "End of Production 1" stage. - RHEL v4 ships 1.0.6 (see http://rhn.redhat.com/errata/RHBA-2009-1034.html ) and is currently in "End of Production 2" stage. The "End of Production 3 / End of Regular Life Cycle" stage is (according to Wikipedia) going to happen in Feb 2012, with "Extended Life Cycle" continuing for another 3 years (I assume on machines that don't run a browser!). Debian: - Latest support release is Lenny, released in 2009, so I assume it has a recent enough version of alsa SUSE: - Wasn't able to get useful information -- will try harder if needed. Based on this, it seems to be safe to require 1.0.14 for Firefox and probably not worth working on a "fall back".
So, the alternative to updating libasound is to modify the dynamic loader in webrtc to have "fallback" entries for specific entrypoints, and implement a very dumb set of hints. The problem would be you probably wouldn't know what's attached to each device (or if anything is attached). I strongly prefer moving libasound forward. This is largely a Product decision.
Do it. Those Linux versions are pretty old now.
The version of libasound that we need is 1.0.14 (or greater). 1.0.14 came out in June 2007. Linux kernel 2.6.23 came out in Oct 2007. (Metrics only has info about the Linux kernel names and version numbers.) Based on some raw data from deinspanjer on the metrics team, it looks like about 7% of our linux users (circa 300,000 users) have linux kernel versions that are older than 2.6.23; approximately 200,000 users are on 2.6.18, which came out in Sept 2006 (next highest is about 30,000 users on 2.6.20, which came out in Feb 2007). 7% or 300,000 users should be an upper bound, as users running older kernels may have a newer libasound (1.0.14 or greater).
(In reply to Maire Reavy [:mreavy] from comment #4) > The version of libasound that we need is 1.0.14 (or greater). 1.0.14 came > out in June 2007. Linux kernel 2.6.23 came out in Oct 2007. (Metrics only > has info about the Linux kernel names and version numbers.) Based on some > raw data from deinspanjer on the metrics team, it looks like about 7% of our > linux users (circa 300,000 users) have linux kernel versions that are older > than 2.6.23; approximately 200,000 users are on 2.6.18, which came out in > Sept 2006 (next highest is about 30,000 users on 2.6.20, which came out in > Feb 2007). 7% or 300,000 users should be an upper bound, as users running > older kernels may have a newer libasound (1.0.14 or greater). How many of these users are on recent versions of Firefox?
With help from metrics (thank you again deinspanjer!), it looks like less than 50,000 users with linux kernels older than 2.6.23 have firefox versions older than 4.0.
Sorry, I said it backwards. I meant to say "less than 50,000 users with linux kernels older than 2.6.23 have firefox versions NEWER than 4.0." Less than 10,000 users have Firefox 10.0 or newer.
Considering that FF 10 will (AFAICT) be supported for another year, it seems like the number of people impacted by requiring a newer alsa should be really small. By that time, I assume the number of people affected will be even smaller. RedHat seems to be the distribution with the longest support and the most recent affected release is RHEL4. As noted above, it will reach End of Production Phase at the end of the month. There's another 3 years of "Extended Life Phase" after than but I highly doubt anyone pays for that on a desktop. So it seems like pretty much all desktops running older versions of alsa are already running an unsupported operating system, so having to run an unsupported browser shouldn't be much worse. This is where I got the info on RedHat support: https://access.redhat.com/support/policy/updates/errata/#Extended_Life_Cycle_Phase
Ben, is this another one you can take care of this week?
bhearsum checked in the solution for the build machines, rolled it out and it works; resolving