[lsb-discuss] ALSA (libasound) inclusion in LSB

Daniel Yek dyek at real.com
Mon Nov 12 16:54:45 PST 2007


[Change the email encoding to UTF-8 for better mailing list archiving.]

Hi,

All ALSA API functions used by Helix:
https://helixcommunity.org/viewcvs/audio/device/platform/unix/audlinux_alsa.cpp?view=markup&pathrev=hxclient_1_5_0_cayenne

are included the spreadsheet sent in the original email (attached here 
too), except for the following 4 macros:

snd_mixer_selem_id_alloca()
http://www.alsa-project.org/alsa-doc/alsa-lib/group___simple_mixer.html

snd_pcm_hw_params_alloca
http://alsa-project.org/alsa-doc/alsa-lib/group___p_c_m___h_w___params.html

snd_pcm_sw_params_alloca
http://alsa-project.org/alsa-doc/alsa-lib/group___p_c_m___s_w___params.html

snd_pcm_status_alloca
http://alsa-project.org/alsa-doc/alsa-lib/group___p_c_m___status.html

Is LSB going to include these macros?

Thanks.

-- 

Daniel Yek.



Denis Silakov wrote:
> The new release of the LSB specification database contains data about
> libasound interfaces. The data is based on alsa 1.0.13 from openSUSE
> 10.2 x86-64.
>
> Database contains all interfaces found in libasound on openSUSE 10.2.
>
> 1) The final step is to decide which interfaces should be actually
> included in the LSB.
>
> The document attached should help to make this decision - it shows which
> interfaces are used by applications, which are provided by distributions (note that there are 26 distributions in the database at the moment)
> and which are documented ('documented' here means that there is an
> appropriate interface description on
> http://www.alsa-project.org/alsa-doc/alsa-lib/).
>
> We suggest adding to LSB all interfaces actually used by at least one application and only them. All of them except one are present in all distributions, and that one is missing in old distributions only (RHEL 4, Asianux 2.0 and Debian 3.1). All such interfaces have documentation (except starting with '__' - see below).
>
> 2) The document contains three columns about interface versions. The thing
> is that alsa sources contain instructions for linker which version
> should be assigned to every interface. However, it seems that this
> assigning is broken - version list contains values from ALSA_0.9 up to
> ALSA_1.0.14 in the latest release, but in the compiled library there are
> no binary symbols with versions ALSA_1.0.4 and higher. All interfaces
> that should have such versions according to alsa sources, actually have
> 'ALSA_0.9' version. (And if you take a look on distributions and their
> alsa interfaces, you will find no interfaces with versions starting with
> 'ALSA_1').
>
> Three columns mentioned contain actual interface version (as 'readelf'
> reports), version which the interface should have according to alsa
> sources and the third column simply shows if these two versions are equal.
>
> So the question is which versions should be assigned to interfaces which should have 'ALSA_1.*' version according to alsa sources and should such interfaces be included in LSB at all? From application usage point of view, there are only 2 interfaces used by apps with such versions problem. We suggest to add both with 'ALSA_0.9' version, as they are provided by distributions.
>
> 3) Note also that there are some binary interfaces starting with '__' which
> are not documented directly. These interfaces appear on binary level
> only and it seems that they appear after some manipulations with
> interfaces  with the same names but without '__'. (This is a rough
> explanation; it would be nice if someone explain in details where such
> interfaces come from). Such interfaces are not marked as documented, but
> appropriate interfaces without leading '__' have documentation.
>
> Some of these interfaces are widely used, so we suggest to include them in the specification. If suggestions above are right, then for every such interface included in the specification a separate page should be created noticing that this is a BinOnly interface and that it behaves as the interface without '__'.
>
> 4) A short summary of the document attached:
>    - total interfaces uploaded - 1694
>    - 471 interfaces are used by applications; among these interfaces:
>        - 56 start with '__' (see comment above)
>        - 2 (snd_pcm_hw_params_set_rate_resample and
> snd_asoundlib_version) have 'ALSA_0.9' version while they should have
> other versions according to alsa sources;
>        - all interfaces were found in all modern distributions uploaded to the database
>        - 2 (snd_config_substitute and snd_config_search_alias_hooks)
> were not found in alsa headers and their names do not start with '__'.
>
>
> Thus, the following questions remain (and we would appreciate community opinion on these):
> 1) Is it reasonable to use the inclusion criterion based on actual usage by apps?
> 2) Which interfaces should be actually included in the LSB? 3) What's
> wrong with versions assigning during alsa build process? 4) Where
> interfaces starting with '__' come from and how they should be handled?
>
>   
> ------------------------------------------------------------------------
>
> _______________________________________________
> lsb-discuss mailing list
> lsb-discuss at lists.linux-foundation.org
> https://lists.linux-foundation.org/mailman/listinfo/lsb-discuss
>   
-------------- next part --------------
A non-text attachment was scrubbed...
Name: alsa_ints_summary.ods
Type: application/vnd.oasis.opendocument.spreadsheet
Size: 76247 bytes
Desc: not available
Url : http://lists.linux-foundation.org/pipermail/lsb-discuss/attachments/20071112/8eed8c6b/attachment.ods 


More information about the lsb-discuss mailing list