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.
I dunno, I think Paul's thoughts sound sensible. Its not solved in a simple
manner, but it was obviously solved somehow with other driver architectures.
Will this database cope with runtime variables, such as the number of
channels with RME Hammerfall though (dependent on samplerate)?
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
