AudioInfrastructure, general desktop hotplug daemon

[Martin Pitt]

Hi all!

One feature that is still missing in the Audio infrastructure
implementation is to make it hotplug-aware. Now you can choose the
default device in System -> Preferences -> Audio, but if you plug in a
new device (USB headset or whatever) there should be a dialog box that
asks you whether to make this device the default (and also allow you
to call the mixer and some tests on it). If the device is unplugged,
the previous default device should be restored.

We need a daemon runing in the user's desktop environment that listens
to hal's soundcard events, creates the dialog and does the appropriate
action (call set-default-soundcard). 

The question is where to implement this notification. I see three
options:

(1) Create a new daemon.
  + Easy to implement.
  - Redundant; if we create a new daemon for every new hotplug
    category we need, we will end up with bazillions of daemons.
  - New daemons need to duplicate much of already existing code for
    dbus reconnection, dbus handling, etc.
  - New daemons need to be registered in the user's session which
    makes upgrading from previous releases hard.

(2) Add support for sound card events to update-notifier.
  + dbus code is already present and the daemon is in the user's
    session (at least for those upgraders that followed the
    instructions). We only need to add little code.
  - We cannot use the upgrading hook infrastructure for this purpose.
  - It is a h4ck and does not fit into the original idea of u-n.
 
(3) Add support for sound card events to gnome-volume-manager.
  + Almost all of the required dbus/hotplug/notification code is
    already there.
  + Runs in all user sessions since Warty.
  - It is a bad h4ck. OTOH g-v-m is already hacked up to death in
    Debian and Ubuntu anyway, so it does not really make much of a
    difference. In addition, g-v-m already handles USB drives, digital
    cameras, audio and video CDs/DVDs, etc. so it already handles
    several types of devices (and should be called g-hotplug-manager).
  + "volume" can be interpreted as sound related *duck* (SCNR)

(4) Create an universal, modular, and extensible common desktop
    hotplug client "event-notifier". Throw away update-notifier and
    gnome-volume-manager and implement their functionality into
    modules of event-notifier.
  + Clean design, should be extensible with
    "/etc/desktop-hotplug-foo/{device,package,log,gamin}.d/<module>"
    files so that packages can just register new actions without much
    fiddling.
  + Solves the problem once and for all.

Obviously (4) is the solution we actually want. I discussed this with
Michael a bit and it seems that we can even make this efficient by
adding a kind of "filter" expression to every module that can be
evaluated quickly, which avoids calling all modules for every received
event. However, the design of the module, file structure, and filter
descriptions requires a good deal of thought. It is nothing that one
person can/should design in two hours on a lazy afternoon, it should
rather become an extended BoF at the next conference.

Since I don't think that we can implement (4) in a really good way for
Breezy, my gut feeling is that we should do the Ugly Hack (tm)
described in (3) for Breezy, and come up with a really good solution
for Breezy+1.

However, before we start doing this I would like to get some more
opinions.

Any thoughs?

Thanks,

Martin

-- 
Martin Pitt              http://www.piware.de
Ubuntu Developer   http://www.ubuntulinux.org
Debian Developer        http://www.debian.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.ubuntu.com/archives/ubuntu-devel/attachments/20050531/a3b0046f/attachment.pgp