Alsa-Devel Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Randell Jesup <randell1@jesup.org>
To: Colin Guthrie <gmane@colin.guthr.ie>
Cc: ALSA Development Mailing List <alsa-devel@alsa-project.org>,
	Randell Jesup <randell1@jesup.org>
Subject: Re: Use of _hint() functions and older machines
Date: Sun, 23 Oct 2011 03:46:07 -0400	[thread overview]
Message-ID: <4EA3C63F.4090501@jesup.org> (raw)
In-Reply-To: <4EA305B7.6050001@colin.guthr.ie>

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!


-- 
Randell Jesup
randell-ietf@jesup.org

  reply	other threads:[~2011-10-23  7:51 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-10-21  3:28 Use of _hint() functions and older machines Randell Jesup
2011-10-22 18:04 ` Colin Guthrie
2011-10-23  7:46   ` Randell Jesup [this message]
2011-10-23 10:36 ` Clemens Ladisch
2011-10-24  5:19   ` Randell Jesup
2011-10-24  7:00     ` Raymond Yau
2011-10-24 10:26     ` Clemens Ladisch

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4EA3C63F.4090501@jesup.org \
    --to=randell1@jesup.org \
    --cc=alsa-devel@alsa-project.org \
    --cc=gmane@colin.guthr.ie \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox