On Sun, 7 Dec 2003, Arve Knudsen wrote:
> On Sun, 07 Dec 2003 14:19:28 -0500, Paul Davis
> <[EMAIL PROTECTED]> wrote:
>
> >>>> I'd like to be able to query the capabilities (number of channels,=20
> >>>> buffer
> >>>> size etc.) of ALSA devices in the system, even if they should be in
> >>>> us=
> >> e=20
> >>>> by
> >>>> some other process. The only current way to probe device capabilities
> >>>> =
> >> is
> >>>> to open a pcm, and use snd_pcm_hw_params, correct? At least this is my
> >>>> current approach, but I'd like to query the devices without first
> >>>> acquiring exclusive access. If there is currently no way around=20
> >>>> acquiring
> >>>> a device for querying, maybe this requirement could be loosened in a
> >>>> future version of ALSA?
> >>>
> >>> Nope. You ask for runtime information. This information can change due
> >>> various hardware contraints so we cannot give you an useful information
> >>> without blocking the device.
> >>>
> >>> Anyway, auto-probing for devices is a bad idea. Let user to choose the
> >>> device (hw:X,Y or plughw:X,Y or some "abstract" name in a dialog box)
> >>> yourself. The hw:X,Y numbers can be determined using the control API
> >>> in=
> >> a
> >>> non-blocking way.
> >> The user is allowed to choose between devices, but its also good to
> >> be=20
> >> able to display information about the different units. Like its normal
> >> in=
> >> =20
> >> Windows audio applications to choose between available devices in the=20
> >> system and their respective channels. Are you saying this is a bad
> >> thing?
> >
> > its not a *bad* thing, but it is tricky to get it 100% correct. let me
> > explain the kind of thing that is going on *at the moment*. the
> > drivers i know best are the RME hdsp and digi9652. the number of
> > channels one of these devices has depends on the sample rate you want
> > to use it with. hence, its not possible to say unambigously "RME HDSP
> > (26 channels)" because it might be "RME HDSP (12 channels)". in this
> > particular case, you could consider this to be a detail: you should
> > report the number of channels available at the current sample rate. ok.
> >
> > however, there are other similar aspects of several cards that can't
> > be finessed as easily as this; sample format, duplex behaviour, sample
> > rates etc. all end up being dependent on other aspects of the
> > configuration you are asking about.
> >
> > i personally am heading towards believing that we made a design
> > decision that was wrong here. i now tend to think that the PCM
> > interface should not be involved with configuring the hardware at all,
> > and that this should be left to the control API. when you open the PCM
> > device, you get whatever is currently configured. if that's not what
> > you want, you open the control API first, configure the device, then
> > open the PCM device. i think this would be much much simpler for
> > most application programmers (not as simple as JACK, but ...) and it
> > would also mirror what happens in the windows world to some extent,
> > where control applets are used to change aspects of the card config.
> >
> > still, its pretty much too late for that.
> Wow, this is somewhat along the lines of what I was thinking myself.
> Although it didn't manifest itself as clearly. I am aware of the
> Hammerfall problem, as its also somewhat painful in Windows. Logic
> Audio never quite coped with it, from what I remember. But there
> seems to be a separation between obtaining information about a card,
> and actually acquiring it.
>
> Perhaps this could be refined in a future design of ALSA?
We all think in the same way, but there's no simple solution for this
problem. I prefer to have such configuration information in an user-space
database accessed via an alsa-lib API. It's nothing for the kernel space.
Jaroslav
-----
Jaroslav Kysela <[EMAIL PROTECTED]>
Linux Kernel Sound Maintainer
ALSA Project, SuSE Labs
-------------------------------------------------------
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
