[Pkg-alsa-devel] Bits from Thomas

[Thomas Hood]

Hi folks,

I am entering a period in which I will have less time to devote to
Debian projects, including ALSA packaging.  I thought I would dump some
thoughts before entering that period.

Experimental releases of 1.0.9rc
================================
In some earlier release cycles the upstream sources failed to build out
of the box.  We were able to work out the problems with upstream, but I
thought then that it was a shame that these bugs hadn't been caught
earlier, before upstream released.  A little testing before the release
would have saved both us and others some trouble.  In this cycle I
managed to get the packages updated to 1.0.9rc1 and 1.0.9rc2 soon after
these were made available.  This revealed build problems again, but when
informed of them, upstream was very responsive.  The problems were
resolved in rc2 or should be resolved in 1.0.9 final.  This is
definitely the way we should work in the future.

For similar reasons I have been trying to help upstream deal with its
bug report backlog.  The more bugs we can close upstream, the fewer we
will see in our BTS.  See below.

Thus, it should be possible to release Debian packages very soon after
upstream releases 1.0.9 final.

TODO for 1.0.9
==============
I have only one mental note that I can find.  An ubuntu user reported
(to the ubuntu BTS) that he was using snd-via82xx and wanted to use the
sequencer, but snd-seq was not being loaded.  It is true that
our /etc/mod{utils,probe.d}/alsa-base file does not cause snd-seq to be
loaded anywhere.  The user was able to fix his problem by adding
"modprobe --quiet snd-seq" to the set of commands on the "install
snd-via82xx" line.  This requires investigation.  If the user needed
this line then why have we not received many reports about snd-seq not
being loaded?  Are few people using snd-seq?  Do some sound card drivers
load snd-seq on top of themselves?  Have many people run into this
problem and solved with local hackery?  This requires investigation.  It
may turn out that all the "install <sound-card-driver>" lines for sound
cards that work with snd-seq will need to be augmented with "modprobe
--quiet snd-seq".  I really hope not.  That would require present and
future maintainers of alsa-driver to know about the capabilities of
particular sound cards.  We should try to avoid being required to have
such knowledge.  :)

Another aspect of the package that is requiring the accumulation of
hardware-specific knowledge is the sanify_levels_on_card() function in
the alsa initscript.  As time goes on we learn about more and more
controls that need to be set to certain states if users are to have
useful sound.  The latest additions to the function are:

        # Required on some notebooks with ICH4:
        switch_control "Headphone Jack Sense" off
        switch_control "Line Jack Sense" off

I fear that these won't be the last additions.  I fear even more that
eventually there will be different cards that need to have their
controls set different ways in order for basic sound to work; then we
will be faced with doing some sort of card sensing in this function.
Bleah.

1.0.8 or 1.0.9 in sarge?
========================
Although there are some improvements to the Debian packaging for 1.0.9,
I can't think of any that are release critical.  The most desirable new
feature is the addition of linux-sound-base.  However, if sarge is going
to freeze very soon then we are probably better off not introducing that
change.  The 1.0.8 packages have a few flaws in comparison with what's
now in svn, but the flaws seem minor.  So I am not uncomfortable if the
current 1.0.8 packages are released with sarge.  I would be
uncomfortable with rushing 1.0.9 into sarge without adequate time for it
to get tested.

Work on upstream BTS
====================
Recently I have been doing what I can to help upstream improve the
quality of ALSA.  I figure: the more we do this, the fewer bugs we have
to deal with in the Debian BTS.  Mostly this has consisted of triaging
their bug list.  The bug list for alsa-driver, in particular, has gotten
out of hand.

If you have some spare time then please call up upstream's bug view page

   https://bugtrack.alsa-project.org/alsa-bug/view_all_bug_page.php

and either look for bugs that you might be able to help with, or set the
view to update-date-ascending-order, click on some old status-new bugs
(highlighted in red) and ping the submitter to ask if he or she has any
new information.  Or do something else that could be of help, such as
fixing bugs and submitting patches.  ;)

-- 
Thomas Hood <jdthood@yahoo.co.uk>