Thursday, September 17, 2009

Limited liability, or how not to develop Karmic using Karmic

Karmic has been wonderfully jumpy these past few days. I must have some sick fascination with broken systems, as my presentation at this year's Ohio LinuxFest will focus on developing Karmic while running Karmic. Not just that, but this Saturday I'll briefly discuss Linux audio at Atlanta Linux Fest.

Now for the real meat in this post. For Karmic+1, I want Ubuntu to lead the charge in populating alsa-utils's init db.

Currently we do some pretty braindead things in alsa-utils's initscript, namely forcibly iterate over an entire set of static mixer element strings and values and attempt to set all detected audio devices to a specific state. Well, it's rather unlikely that my Logitech USB headset will have a Creative Audigy-specific "Audigy Analog/Digital Output Jack", yes?

Of course, that's just one badness, but the driving factor is to be able to conditionally set volumes on system start (for non-PulseAudio configurations) based on the machine's SSID. This approach largely resolves the "Gee, I have an Audigy X that requires the jack toggle to be muted to get audible analog output but person Y with an Audigy Z requires it to be unmuted" debacle.

So where do you come in? With current HDA codecs, using a static setting of 80% for PCM is pretty fragile. Some hardware sounds really overdriven at that setting, and others are barely audible. We need your SSID (lspci -nv|grep -A1 040[13]) and your preferred volumes! More in the following weeks.

3 comments:

  1. bear in mind that a lot of the tinny little media speakers being overdriven by their amps can also contribute to similar distortions. can you rely on the userbase to contribute data from a system which has been accurately diagnosed first?

    ReplyDelete
  2. Where is this data being collected/archived? Is there a wiki page?

    ReplyDelete
  3. @mervaka 77% or 80% likely will be the ceiling. I'm more concerned with cases where 77% results in "overdriven" audio - yes, shoddy hardware or BIOS - that can be worked around by SSID class using alsactl init.

    @Brian The data are collected and inserted directly into upstream's alsa-utils source: http://git.alsa-project.org/?p=alsa-utils.git;a=tree;f=alsactl/init;hb=HEAD

    ReplyDelete