Ubuntu Wiki

• Launchpad Entry: alsa-modules-outside-kernel-tree

• Created: 2008-12-10 by LukeYelavich

• Contributors: DanielTChen

• Packages affected: linux alsa-driver

Summary

Evaluate feasibility of maintaining updated alsa driver modules outside the linux and linux-backports-modules source trees.

Release Notes

Rationale

• From gutsy onward, the vast majority of supported alsa driver modules ships in the linux-ubuntu-modules or linux source packages (with newer versions in the linux-backports-modules source). An overlapping, not as well maintained, set of alsa driver modules is available in the alsa-driver source package. New sound card models and quirks, particularly for HDA, are added to one or the other (but not to alsa-driver). This procedure requires a complete rebuild of one or more of l-u-m, linux, and l-b-m.
• Maintaining non-core alsa driver modules outside the kernel source would allow for much easier and quicker updates of existing drivers, such as adding model quirks or new SSIDs to existing model quirks. It also would allow for one consistent alsa version across the three kernel source trees currently in the Ubuntu archive.

Use Cases

• Fred has a popular new laptop containing an HDA codec. Currently he has inaudible audio due to a missing quirk for his SSID/codec combination. He verifies that an existing model quirk makes his audio audible and would like to add his SSID to the alsa driver so others with his SSID/codec combination can have audible audio.

Assumptions

• It is feasible to maintain header/version (and possibly kconfig) parity between linux and alsa-driver.

Design

Implementation

• alsa core should continue to be built by linux due to kconfig being used by other drivers.

UI Changes

• none required (no graphical UI)

Code Changes

Migration

Test/Demo Plan

Unresolved issues

• header/version and kconfig parity
• OEM certification processes that require a non-changing alsa driver
• increased base install footprint (see rtg's comment)

BoF agenda and discussion

• How would we package the drivers separately?
  • DKMS
    • Which alsa driver modules would be built?
    • Would it take too long to build all driver modules?
    • Would we have separate packages for each kernel, pulled in with the metapackages?
      • Likely not, as the kernel team wants to eliminate all such packages

(rtg) I think there are several issues with external packaging of ALSA:

• Building ALSA as a DKMS package requires a number of tools, e.g., at least build-essential plus some other tools. This is likely quite a burden on low powered or SSD based devices. The build times could be substantial. Even a fast machine requires a minute or so.
• There are several modules _not_ in the sound directory that depend on ALSA headers. You must copy those modules into the ALSA DKMS package so that they get built against the correct headers, otherwise you run the risk of ABI skew. You must also remember you've done this so that any patches made to the kernel sources also get reflected in these ALSA copies.
• Quirk and PCI additions are not sufficient reasons unto themselves to warrant a separate package.

CategorySpec