[PATCH] add soundcard device and fix device_file handling
Danny Kukawka
danny.kukawka at web.de
Wed Mar 21 01:25:57 PDT 2007
On Dienstag, 20. März 2007, David Zeuthen wrote:
> On Tue, 2007-03-20 at 11:01 +0100, Danny Kukawka wrote:
[..]
> > But I can add this really paranoid check.
>
> Yeah, it's always good to check things since otherwise things might stop
> working when/if we change the event dispatcher..
As I already wrote: a check for != NULL is useless at the moment since this
is a char array and can't be NULL. If this change you have to rewrite and check
all code which is effected by the change. It make no sense to add code to
prevent problems is may sometime get changed.
> > The (finally, if we depend on 2.6.20) goal is to add all card related information
> > to the soundcard itself and not again and again to each single sound device
> > (as e.g. alsa/oss.card and alsa/oss.card_id). Btw this would also reflect the
> > real sysfs structure in the future.
>
> Why is this an advantage? It might be, I'm not opposed to change things
> unless it starts breaking PulseAudio (did you test?) or other apps etc.
> I just like to see some justification. Perhaps it should be called
> alsa_soundcard as well since this is for ALSA only, yes?
As first we don't need to duplicate all the data for each ALSA or OSS device which is
connected to this soundcard. If you want to know what the name or the card number of
the ALSA/OSS device is you need only to check the parent device which is now the real
soundcard. And you can add more info to a soundcard in the future and you don't want
to add these (maybe usefull) info to each ALSA/OSS device again and again. At least
it would massive reduce the sound device related code in HAL.
Maybe it would break PulseAudio or any other Audio application that use HAL, but
this is only something we should handle as we do with each other change: provide the
old keys 12 months and document the change.
IMO we should not call the the soundcard alsa_soundcard since this is not really
alsa specific. You can IMO add also other sound card devices here if you want
(is there any other sound system under Linux? Would the Solaris or FreeBSD system
be that different that this would not fit?).
Btw. This is nothing for 0.5.9.
> > IMO we should think about moving the alsa and oss namespace to the (new) sound
> > namespace as a subspace/class by changing all alsa.*/oss.* properties to
> > sound.alsa.*/sound.oss.* , but for the we need to depend on >= 2.6.20
>
> Probably it's better to wait for HAL 0.5.10 and we'll bump the
> requirements to Linux 2.6.20. It's still fishy that it will only with
> with !CONFIG_SYSFS_DEPRECATED especially if apps start depending on this
> and then it only works on kernels configured in such a way....
This was not my plan for 0.5.9, I would only start to discuss this. Btw. the change
from alsa.* to sound.alsa.* would make also sense without !CONFIG_SYSFS_DEPRECATED
because this don't need to depend on the sound card device. This devices are really
similar devices and should be in the same namespace.
More information about the hal
mailing list