On Mon, 8 Dec 2003, Arve Knudsen wrote:
Wether its done via the control or pcm interface, it'd be good to have a
loose coupling between configuration and streams, so one could could access
configuration space without locking a stream don't you think? I mean,
with ASIO, from what I can see there is no problem obtaining info about
devices in the system even if they might be in use. Shouldn't we at least
aim for the same flexibility with ALSA?
I was thinking about this issue whole day and it seems to me that you need
only a list of available devices (including used ones). Ok, it can be done
now using the control interface for hw devices, but we missing a way for
the abstract names. Yes, there is a gap in our API and we can fix it.
Only device names? Like I said, I would like to be able to describe any device in the system (I already obtain the names of all hw devices, available or not). I don't see any real reason why this shouldn't be doable. This is handled smoothly with other driver models from what I can see? What do you mean by abstract names by the way, software devices?
The second question is, if we want to give you more information about
devices than an unique name (and perhaps description). My feeling is that
you're aware what you have in your computer (and I hope, we will develop
configuration tools which makes the configuration of alsa-lib devices more
comfortable in future).
I don't think we should assume the user knows which devices are in the computer, and leave it at that. In my opinion the application should be simply able to obtain and present information in a generic manner, if the user wants to specify parameters explicitly, hey why not. Why should this information not be made available (so it can be presented graphically for instance)? By the way, I'm not asking for more than what is already available in ALSA-lib (except I want it readable without locking a stream)?? I think Paul's idea of separating configuration from opening of a stream sounds appealing by the way, although I lack the insight to really comment on this.
Also, alsa-lib's flexibility allows us to acceptI'm not sure if I totally understand what you mean, most streams are
almost any stream with the global - system wide - optimizations on our
side. We don't want to let probing from the application side. This way
is not very good. The application should choose (or maybe an user of
this application should choose) the best communication (stream parameters)
used for the HAL layer (in our case alsa-lib).
constrained when it comes to configuration (unless its a software device
which accepts anything). We're not trying to automagically configure ALSA
devices, but simply infer such info as reasonable default samplerate etc.
(and the number of min/max channels of course). Like ive written this
plugin for a mediaplayer which allows the user to choose between individual
output stereo pairs of available devices, and stores this among preferences.
This is made difficult by possibly not being able to query devices, unless
I wish to block during the initialization phase.
Regards
Arve Knudsen
------------------------------------------------------- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ _______________________________________________ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
