Re: Default soundcard (UDEV?)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



At Thu, 28 Sep 2006 17:06:08 +0200 (CEST),
Jaroslav Kysela wrote:
> 
> On Thu, 28 Sep 2006, Takashi Iwai wrote:
> 
> > BTW, for the secondary card, you can use like the style like
> > "default:1".  This will choose the default PCM of the secondary card.
> 
> Note that perhaps we should change what the default card means. In the 
> sense of udev mechanism, devices should be detected and enumerated in 
> system. We have actually no way (and it will be very problematic) to 
> change the soundcard number in the ALSA driver. Fortunately, we have extra 
> card id (which is not very much used) which can be perfectly used for this 
> purpose and it can be also changed at runtime (so udev rules can reassing 
> for example the default card).
> 
> I would propose that "default" will refer always to a card with id 
> "default" (and if no card will have this id, first soundcard will be used 
> as now). At driver initialization, first card becomes as "default", then 
> user or udev can rename it to something else.
> 
> Also, extra udev support should be added to match devices from longname or 
> shortname (see control API and SYSFS{}).
> 
> Opinions (except that we should learn users to use "logical 
> identification" not card numbers)?

The logical id (aka persistent name) is a good invention, but actually
it forces apps to change its code.  This is not easy.  Thus, we can
never drop the style like "hw:1" while we may provide the new support
of logical id.

That is, we'd need eventually an internal map between the logical id
and the numerical id.  Currently it's in the driver side, but this
could be in alsa-lib once if the device connection is moved to the
persistent device-file names.

(BTW, I very much agree with changing the semantics of "default:1".
 Originally I proposed to use a different name, but we didn't get
 consensus to a solid name, so "default" was chosen as compromise.)


IMO, the first thing we have to do above the things above is to
provide an easy-to-use device enumeration API.  This must be as simple
as possible, just let apps to choose a device.  No more, no less.

We have already some framework for enumeration, but it's unfortunately
useless right now.  Partly because it requires extra work (to call
alsactl names), and partly because it's incomplete.

Once after we get this, the naming doesn't matter so much because apps
simply choose from the names the system provides.  (Of course, apps
may ask you arbitrary string for device, but the basic operatoin
should be a selection from the list.)  That's why I find it's more
important here...


Takashi

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Alsa-devel mailing list
Alsa-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/alsa-devel

[Index of Archives]     [ALSA User]     [Linux Audio Users]     [Kernel Archive]     [Asterisk PBX]     [Photo Sharing]     [Linux Sound]     [Video 4 Linux]     [Gimp]     [Yosemite News]

  Powered by Linux