On 10/22/2011 2:04 PM, Colin Guthrie wrote:

'Twas brillig, and Randell Jesup at 21/10/11 04:28 did gyre and gimble:

...

[ I initially posted this to the -users list, but it may be more appropriate here ]

At Mozilla, we're in the process of adding support for WebRTC (http://webrtc.org/), which is being standardized by the IETF (their part is 'rtcweb'), and the W3C. This adds real-time audio and video (and data) communication to browsers, peer-to-peer over encrypted channels.

We have a sound library that can load either Pulse or Alsa. However, for Alsa, it wants to look at snd_device_name_hint() and also _get_hint() and _free_hint(). It lazy-binds to libasound, so it will dlopen() it and then dlsym() all the symbols it uses; if any fail it unloads the lib and says it's not there. It uses the hint functions to build a device list, for example for presenting to the user.

I have two problems:

1. Firefox is build on machines configured with I believe Centos5, and

I'm told the machines run Alsa 1.0.12, while the hints() functions were added in 1.0.14 (released June 2007). Right now I can't build release or 'try' builds on the build servers because of this.

Are you sure? CentOS 5 is fairly new and on a box I have access to:

[csuk@shake ~]$ cat /etc/redhat-release CentOS release 5.5 (Final) [csuk@shake ~]$ rpm -q alsa-lib alsa-lib-1.0.17-1.el5

So I guess it's likely CentOS 4? Even still updating alsa-lib to 1.0.14 should be pretty trivial and safe. Or do you not have any control at all over the version used?

In general no, I do not have any control. These are the 'hive' of build and 'try' servers used at Mozilla; they run a "least-common-denominator" set of packages so that we don't accidentally introduce a dependency on a newer version. With 400+ million users, we need to be careful about this. (I don't know how many of those are Linux, but it's still a substantial number.)

Also, the point here is we need to package a binary that will operate on the minimum configuration we support. 10.1.14 was released initially just over 4 years ago; I don't know when it got into distro releases, but one would assume that would have occurred over the next 6 months to a year, so users who installed more than 3-4 years ago might have versions before .14, depending on if they installed updates.

...

2. We'd like to run on older machines if possible, and official release

builds are made on those servers. On older machines, _hint() aren't available, so even if I make them optional to dlsym-loading, I would need some other method to get the information I assume using older, now-deprecated-or-gone interfaces.

Not sure, but I suspect strongly that you should simply not worry about this too much. While it's nice to give a good experience to everyone, people with systems 4 years old have got to expect a degree of degradation over a more recent install.

I understand, and I can try to make an argument for bumping the minimum configuration required - and that might fly. But I need to know what the alternative is to even make the argument for bumping.

Thanks for the reply!

On 10/23/2011 6:36 AM, Clemens Ladisch wrote:

On 10/21/2011 05:28 AM, Randell Jesup wrote:

...

On older machines, _hint() aren't available, so even if I make them optional to dlsym-loading, I would need some other method to get the information I assume using older, now-deprecated-or-gone interfaces.

On older machines, that information wasn't available at all.

The recommendation was to use "default" or to let the user enter a device name.

Ah. Ok. Wow, was it really that painful? I didn't do a lot of Linux media stuff back then, and generally had only built-in-audio (no USB headsets, etc) with simple speakers.

The best way to get a list of devices would have been to enumerate sound cards with snd_card_next(), then use device names "default:CARD=x". However, this gets only the primary device of each card, there might be sound cards without a PCM device, devices not based on an ALSA kernel driver aren't listed, and the "default:CARD=x" mechanism doesn't work if the user has redefined the "default" device.

Ugh. So, there's no reasonable way to get a user-understandable list before .14? How useful was snd_ctl_card_info_get_name()/snd_ctl_card_info()? And I guess I'd need to enumerate the 'devices' and 'subdevices' on each card as well...

Thanks for the info, BTW

Randell Jesup wrote:

On 10/23/2011 6:36 AM, Clemens Ladisch wrote:

...

The best way to get a list of devices would have been to enumerate sound cards with snd_card_next(), then use device names "default:CARD=x". However, this gets only the primary device of each card, there might be sound cards without a PCM device, devices not based on an ALSA kernel driver aren't listed, and the "default:CARD=x" mechanism doesn't work if the user has redefined the "default" device.

Ugh. So, there's no reasonable way to get a user-understandable list before .14? How useful was snd_ctl_card_info_get_name()?

That gives you the card name, which is not the same as the name of the PCM device (although it shouldn't matter when the card has only one PCM device).

And I guess I'd need to enumerate the 'devices' and 'subdevices' on each card as well...

Yes, but subdevices are typically used for multiple streams that are mixed together, so you can ignore them.

Regards, Clemens