At Thu, 28 Sep 2006 18:00:41 +0200 (CEST),
Jaroslav Kysela wrote:
>
> On Thu, 28 Sep 2006, Takashi Iwai wrote:
>
> > 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.
>
> I do not propose to change the current behaviour. We do not require any
> changes in alsa-lib except changing "defaults.pcm.card 0" to
> "defaults.pcm.card "default"" (and handle fallback to first soundcard).
Hm, then I misunderstood. I thought you meintioned the persistent
device files via udev (like ethernet and disk)...
> > 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.
>
> I am against any kind of remapping based on the card index. It would be
> more confusing.
Yeah, it's a workaround if we were to move to the persistent device
files. Then there would be no number in the device file any more.
> > (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.)
>
> Note that "default:Intel" (or replace Intel with your card id) works now.
> I don't see any collision. You may refer device using logical or
> physical name.
I know. That's why I mentioned numbers.
Since no real applications use this id string at all (AFAIK), it
doesn't help to cry "Hey but we already support it!"...
My point is to keep the number scheme compatible like before _even if_
we are obliged to move to persistent device files.
> > 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.
>
> We all know that the problem with right enumeration is that we have
> virtual names and arguments, so we have basically unlimited number of
> choices.
>
> I would propose to return a list of devices consisting from:
>
> a) basic devices on top of hardware (default:X, hw:X, surround...)
Returning both default and hw makes little sense, rather confusing.
The apps don't (shouldn't) care what black magic is done in the
background. (Note that the apps I suppose here are not the sound
system like JACK but media players, voip, recorders, etc.)
Maybe we'd better to think in another way from user's point of view.
Imagine to let app choose one entry per card or function (currently
identifed as "default"). And, you can set up the card default
differently per purpose, such as 5.1, or SPDIF output. In this way,
the list becomes small, and you can still configure the devices.
This sounds more logical to me. However...
The problem in this scheme is that the ALSA setup isn't dynamically
configurable. Once you open a device, it's bound to a specific
purpose. If you change the setup (e.g. from 2 to 5.1 channels) while
opening a device, it's not reflected to the running system.
Also the crash (race) of different configurations is another issue,
especially for dmix. So, this is not an easy option.
> b) user selectable list (from asoundrc or global configuration)
A new attirbute in the definition would be needed since we shouldn't
list all available defitions (like aplay -L currently does). Only the
definitions with such an attribute are listed as selectable devices.
Then you can have a description for each definition, too.
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
