On Sun, 7 Dec 2003, Arve Knudsen wrote:
On Sun, 7 Dec 2003 21:00:13 +0100 (CET), Jaroslav Kysela <[EMAIL PROTECTED]> wrote:
> On Sun, 7 Dec 2003, Arve Knudsen wrote:
>
>> > 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.
>
> With very little success when a complicated hardware is in the machine.
I can't remember having any real problems with this on Windows, or hearing
about any such problems from others? There was the problem with Logic Audio
not coping with Hammerfall's variable numberof channels, but I think other
applications worked fine.
>> Will this database cope with runtime variables, such as the number of
>> channels with RME Hammerfall though (dependent on samplerate)?
>
> It depends on our goals and what we expect from this information. Can you
> describe your requirement (for what reason, you need this information?).
I'm one of the developers responsible for the ALSA implementation of a
cross
platform audio wrapper called PortAudio (www.portaudio.com), which gathers
info about available devices during startup. Also, when using this library
myself, I would like to be able to display a list of devices/channels to
choose from (I normally use channels 17/18). Anyway, such information is
seemingly easily obtained with other driver architectures, any reason why
this shouldnt be available to Linux users (disregarding the implementation
issue)? Personally I see no reason to inhibit flexibility beyond what we
see as immediately useful.
It depends on your look.
1) we have "abstract" devices not connected to hw (for example null PCM
device in alsa-lib); they can support any configuration you can imagine
I don't immediately see the problem, if its a software device which accepts anything, we'll treat it as that (given we are able to discern).
2) which information is valid when some devices/configurations cannot be used simultaneously?
Its difficult for me to relate to this on a theoretical level, but its problematic to guard yourself against any possible issue. Anyway, wouldn't the configuration reflect this if the information is generated during runtime? That is, one opened device affects the possible configuration of another (not opened). I could be completely lost here, but I don't think we should constrain ourselves completely because of possible problems (I'd much rather look for solutions).
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
