Query devices in a non-blocking fashion

Query devices in a non-blocking fashion

[Arve Knudsen]

I'd like to be able to query the capabilities (number of channels, buffer 
size etc.) of ALSA devices in the system, even if they should be in use 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 acquiring 
a device for querying, maybe this requirement could be loosened in a 
future version of ALSA?

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/

Re: Query devices in a non-blocking fashion

[Jaroslav Kysela]

On Sun, 7 Dec 2003, Arve Knudsen wrote:

> I'd like to be able to query the capabilities (number of channels, buffer 
> size etc.) of ALSA devices in the system, even if they should be in use 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 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.

I think that we should provide the list of devices with a description via 
some interface in alsa-lib.

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
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/

Re: Query devices in a non-blocking fashion

[Arve Knudsen]

On Sun, 7 Dec 2003 19:40:23 +0100 (CET), Jaroslav Kysela <perex@suse.cz> 
wrote:

> On Sun, 7 Dec 2003, Arve Knudsen wrote:
>
>> I'd like to be able to query the capabilities (number of channels, 
>> buffer
>> size etc.) of ALSA devices in the system, even if they should be in use 
>> 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 
>> 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 
able to display information about the different units. Like its normal in 
Windows audio applications to choose between available devices in the 
system and their respective channels. Are you saying this is a bad thing?

> I think that we should provide the list of devices with a description via
> some interface in alsa-lib.
Isn't this pretty much what I'm asking for? I don't care how its done, I 
would just like to obtain available information in some civilized manner 
(so I can gather info during initialization) :) Speaking of information, I 
wouldn't mind some info from each driver about supported period sizes, 
like ASIO has a way of obtaining buffer granularity I think. Could be 
useful for determining a common period size if a full-duplex stream 
consists of two different devices.

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/

Re: Query devices in a non-blocking fashion

[Paul Davis]

>>> 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.

--p





>> I think that we should provide the list of devices with a description v=
>ia
>> some interface in alsa-lib.
>Isn't this pretty much what I'm asking for? I don't care how its done, I=20
>would just like to obtain available information in some civilized manner=20
>(so I can gather info during initialization) :) Speaking of information, =
>I=20
>wouldn't mind some info from each driver about supported period sizes,=20
>like ASIO has a way of obtaining buffer granularity I think. Could be=20
>useful for determining a common period size if a full-duplex stream=20
>consists of two different devices.
>
>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
>Alsa-devel@lists.sourceforge.net
>https://lists.sourceforge.net/lists/listinfo/alsa-devel
>


-------------------------------------------------------
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/

Re: Query devices in a non-blocking fashion

[Arve Knudsen]

On Sun, 07 Dec 2003 14:19:28 -0500, Paul Davis 
<paul@linuxaudiosystems.com> 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?

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/

Re: Query devices in a non-blocking fashion

[Jaroslav Kysela]

On Sun, 7 Dec 2003, Arve Knudsen wrote:

> On Sun, 07 Dec 2003 14:19:28 -0500, Paul Davis 
> <paul@linuxaudiosystems.com> 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 <perex@suse.cz>
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/

Re: Query devices in a non-blocking fashion

[Arve Knudsen]

On Sun, 7 Dec 2003 20:38:48 +0100 (CET), Jaroslav Kysela <perex@suse.cz> 
wrote:

> On Sun, 7 Dec 2003, Arve Knudsen wrote:
>
>> On Sun, 07 Dec 2003 14:19:28 -0500, Paul Davis
>> <paul@linuxaudiosystems.com> 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/

Re: Query devices in a non-blocking fashion

[Jaroslav Kysela]

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.

> 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?).

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
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/

Re: Query devices in a non-blocking fashion

[Arve Knudsen]

On Sun, 7 Dec 2003 21:00:13 +0100 (CET), Jaroslav Kysela <perex@suse.cz> 
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.

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/

Re: Query devices in a non-blocking fashion

[Jaroslav Kysela]

On Sun, 7 Dec 2003, Arve Knudsen wrote:

> On Sun, 7 Dec 2003 21:00:13 +0100 (CET), Jaroslav Kysela <perex@suse.cz> 
> 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
2) which information is valid when some devices/configurations cannot be
   used simultaneously?

And I'm sure that I forgot something.

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
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/

Re: Query devices in a non-blocking fashion

[Arve Knudsen]

On Sun, 7 Dec 2003 21:44:16 +0100 (CET), Jaroslav Kysela <perex@suse.cz> 
wrote:

> On Sun, 7 Dec 2003, Arve Knudsen wrote:
>
>> On Sun, 7 Dec 2003 21:00:13 +0100 (CET), Jaroslav Kysela <perex@suse.cz>
>> 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/

Re: Query devices in a non-blocking fashion

[Frank Barknecht]

Hallo,
Arve Knudsen hat gesagt: // Arve Knudsen wrote:
> 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.

Which reminds me to ask: how does Portaudio currently cope with
user-defined, not enumerable interfaces in ALSA? 
ciao
-- 
 Frank Barknecht                               _ ______footils.org__


-------------------------------------------------------
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/

Re: Query devices in a non-blocking fashion

[Arve Knudsen]

On Mon, 8 Dec 2003 11:49:45 +0100, Frank Barknecht <fbar@footils.org> 
wrote:

> Hallo,
> Arve Knudsen hat gesagt: // Arve Knudsen wrote:
>> 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.
>
> Which reminds me to ask: how does Portaudio currently cope with
> user-defined, not enumerable interfaces in ALSA?
Only concrete hardware devices are considered at the moment as far as I
can tell, that is, we enumerate based on snd_card_next. I'll have to
admit I never really got into the ALSA configuration system. I might
look into it later, once I'm happy with the basic functionality of the
implementation (getting there).

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/

Re: Query devices in a non-blocking fashion

[Frank Barknecht]

Hallo,
Arve Knudsen hat gesagt: // Arve Knudsen wrote:

> On Mon, 8 Dec 2003 11:49:45 +0100, Frank Barknecht <fbar@footils.org> 
> wrote:
> >Which reminds me to ask: how does Portaudio currently cope with
> >user-defined, not enumerable interfaces in ALSA?
> Only concrete hardware devices are considered at the moment as far as I
> can tell, that is, we enumerate based on snd_card_next. I'll have to
> admit I never really got into the ALSA configuration system. I might
> look into it later, once I'm happy with the basic functionality of the
> implementation (getting there).

Ah, that would be cool. I'm not really intimate with PortAudio, but my
main application, Pure Data (not written by me ;), is using it in
parallel to direct ALSA/JACK/OSS backends. The goal is, to switch to
PA fully, but it would very annoying not to be able to select ALSA
devices by name.

Actually from a developer's perspective, ALSA's PCM configuration
system is rather simple: Just use the name (char*) the user provides
where you'd otherwise use something like "hw:0" or "default". The only
problem is, that this is not enumarable. But not providing the
possibility for a user, to specify a PCM name, is like trying to
outsmart the user.

ciao
-- 
 Frank Barknecht                               _ ______footils.org__


-------------------------------------------------------
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/

Re: [Alsa-devel][OT]Was: Query devices in a non-blocking fashion

[Arve Knudsen]

On Mon, 8 Dec 2003 12:39:25 +0100, Frank Barknecht <fbar@footils.org> 
wrote:

> Hallo,
> Arve Knudsen hat gesagt: // Arve Knudsen wrote:
>
>> On Mon, 8 Dec 2003 11:49:45 +0100, Frank Barknecht <fbar@footils.org>
>> wrote:
>> >Which reminds me to ask: how does Portaudio currently cope with
>> >user-defined, not enumerable interfaces in ALSA?
>> Only concrete hardware devices are considered at the moment as far as I
>> can tell, that is, we enumerate based on snd_card_next. I'll have to
>> admit I never really got into the ALSA configuration system. I might
>> look into it later, once I'm happy with the basic functionality of the
>> implementation (getting there).
>
> Ah, that would be cool. I'm not really intimate with PortAudio, but my
> main application, Pure Data (not written by me ;), is using it in
> parallel to direct ALSA/JACK/OSS backends. The goal is, to switch to
> PA fully, but it would very annoying not to be able to select ALSA
> devices by name.
>
> Actually from a developer's perspective, ALSA's PCM configuration
> system is rather simple: Just use the name (char*) the user provides
> where you'd otherwise use something like "hw:0" or "default". The only
> problem is, that this is not enumarable. But not providing the
> possibility for a user, to specify a PCM name, is like trying to
> outsmart the user.
There is infrastructure support for custom stream info when opening a
stream, so it would be possible to pass a device string through this,
but it is unimplemented as of yet.

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/

Re: Query devices in a non-blocking fashion

[Paul Davis]

>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'm not sure i agree with that. a user-space config DB could be used
to describe the possibilities. but it doesn't address the approach i
outlined where a program can present the *current* state of the
system as configured using the control API.

--p


-------------------------------------------------------
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/

Re: Query devices in a non-blocking fashion

[Jaroslav Kysela]

On Sun, 7 Dec 2003, Paul Davis 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'm not sure i agree with that. a user-space config DB could be used
> to describe the possibilities. but it doesn't address the approach i
> outlined where a program can present the *current* state of the
> system as configured using the control API.

Why not? We can have a dynamic database where are also described the 
rules.

					Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
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/

Re: Query devices in a non-blocking fashion

[Giuliano Pochini]

On Sun, 07 Dec 2003 14:19:28 -0500
Paul Davis <paul@linuxaudiosystems.com> wrote:

> 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.

I don't agree. The control API (usually) is for things that don't affect
the way data is transferred between the card the the computer. Sample rate,
format, etc. are used to configure the hardware at the driver level, but
from the point of view of the application they are attributes of the
substream. The application has to take them into account. It can't just
open the PCM device and play/record something without knowing the format. So
you'll end up always using two different APIs to do the same things you now
can do with only one.


--
Giuliano.



-------------------------------------------------------
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/

Re: Query devices in a non-blocking fashion

[Arve Knudsen]

On Mon, 8 Dec 2003 16:19:36 +0100, Giuliano Pochini <pochini@shiny.it> 
wrote:

> On Sun, 07 Dec 2003 14:19:28 -0500
> Paul Davis <paul@linuxaudiosystems.com> wrote:
>
>> 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.
>
> I don't agree. The control API (usually) is for things that don't affect
> the way data is transferred between the card the the computer. Sample 
> rate,
> format, etc. are used to configure the hardware at the driver level, but
> from the point of view of the application they are attributes of the
> substream. The application has to take them into account. It can't just
> open the PCM device and play/record something without knowing the 
> format. So
> you'll end up always using two different APIs to do the same things you 
> now
> can do with only one.

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?

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/

Re: Query devices in a non-blocking fashion

[Jaroslav Kysela]

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.

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). Also, alsa-lib's flexibility allows us to accept 
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).

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
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/

Re: Query devices in a non-blocking fashion

[Arve Knudsen]

On Mon, 8 Dec 2003 17:57:03 +0100 (CET), Jaroslav Kysela <perex@suse.cz> 
wrote:

> 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 accept
> 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).
I'm not sure if I totally understand what you mean, most streams are
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/

Re: Query devices in a non-blocking fashion

[Patrick Shirkey]

If we have a DB of info how would we define the abilities of each device?

I assume this info is available in the driver layer because there is a 
point where ALSA will return false eg. if a card is not able to run at 
48000Hz

My opinion is that a simple function could be included in alsactl which 
scans for available devices, makes a list of their abilities. Everyone 
uses "post-insert alsactl restore" in the modules.conf file so it would 
be essentially a non issue from a user perspective.

Couldn't this be saved in the config settings for alsactl?




-- 
Patrick Shirkey - Boost Hardware Ltd.
Http://www.boosthardware.com
Http://www.djcj.org - The Linux Audio Users guide
========================================


  Apparently upon the beginning of the barrage, the donkey broke 
discipline and panicked, toppling the cart. At that point, the rockets 
disconnected from the timer, leaving them strewn around the street. 
Tethered to the now toppled cart, the donkey was unable to escape before 
the arrival of U.S. troops.

United Press International
Rockets on donkeys hit major Baghdad sites

By P. MITCHELL PROTHERO
Published 11/21/2003 11:13 AM



-------------------------------------------------------
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/

Re: Query devices in a non-blocking fashion

[Paul Davis]

>My opinion is that a simple function could be included in alsactl which 
>scans for available devices, makes a list of their abilities. Everyone 
>uses "post-insert alsactl restore" in the modules.conf file so it would 
>be essentially a non issue from a user perspective.

i think it needs to be slightly more complex than that (because of the
way the configuration space is reduced as various parameters are set).

we need a structure that is somewhat equivalent to hw_params. the
program fills it out, in effect asking for "16 bit, stereo, 48kHz,
1024 frames/period" and then queries to see what devices can satisfy
that. it will be hard for the program to use this if it thinks it can
handle multiple configurations, but there are not many programs that
work this way: most know what configuration they want, and just want
to find devices that can work that way.

otoh, one may counter that the plughw layer in alsa-lib is there to
allow *any* h/w device to be used with *any* configuration, so this is
all a bit ridiculous. 

of course, the devices may be busy, so the program needs to be ready
for that as well (this applies to multiopen cards just the same, even
if its much less likely that they are "fully" busy).


-------------------------------------------------------
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/

Re: Query devices in a non-blocking fashion

[Arve Knudsen]

On Mon, 15 Dec 2003 01:17:26 +0900, Patrick Shirkey 
<pshirkey@boosthardware.com> wrote:

> If we have a DB of info how would we define the abilities of each device?
>
> I assume this info is available in the driver layer because there is a 
> point where ALSA will return false eg. if a card is not able to run at 
> 48000Hz
>
> My opinion is that a simple function could be included in alsactl which 
> scans for available devices, makes a list of their abilities. Everyone 
> uses "post-insert alsactl restore" in the modules.conf file so it would 
> be essentially a non issue from a user perspective.
>
> Couldn't this be saved in the config settings for alsactl?
This whole database thing seems like overkill to me, to be honest. This is
dynamic information would best be obtained from cards during operation,
the only problem is that you have to lock the device. A better design would
be to, if possible, allow the configuration space to be read even when a
device is streaming.

I dont know the dirty details of writing drivers, but would this be a
problem? Perhaps we could differ between read-locked and write-locked
configuration, so there would be inclusive read access to the device, and
totally exclusive access if it is to be modified.

Hope some of this makes sense

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/

Re: Query devices in a non-blocking fashion / 3D capabilties.

[Manuel Jander]

Hi,

While writing a advanced capabilities (positional audio) interface for
ALSA, i encountered this same problem.

So far i have "architected" the thing like this:

- The ALSA driver loads as usual.
- When OpenAL or whatever fires up, it queries the device for
capabilties, using a well defined control for that purpose.
- Depending on what capabilties are reported as supported, the library
uses a series of kcontrols to modify hardware settings for advanced
capabilties (HRTF, ITD, filters, etc).

If this can't be performed in a asyncronous (non-blocking) i wouldn't be
able to use controls.

I looked into "alsa-kernel/core/control.c" and after finding out that
every control interaction does a control lookup (iterated through all
controls), i don't feel very confortable about using kcontrols to update
hardware parameters in at tens of milisecond intervals.

Then i discovered the ALSA /proc interface, but the docs read "use for
debugging". They have a lot less overhead. Would it be OK to use them
for hardware parameter update ? And if so, why don't you use this
interface for queries ? They seem to give much more freedom about
locking and other issues.

I really need feedback :)

Best Regards

        
On Sun, 2003-12-14 at 12:46, Arve Knudsen wrote:
> On Mon, 15 Dec 2003 01:17:26 +0900, Patrick Shirkey 
> <pshirkey@boosthardware.com> wrote:
> 
> > If we have a DB of info how would we define the abilities of each device?
> >
> > I assume this info is available in the driver layer because there is a 
> > point where ALSA will return false eg. if a card is not able to run at 
> > 48000Hz
> >
> > My opinion is that a simple function could be included in alsactl which 
> > scans for available devices, makes a list of their abilities. Everyone 
> > uses "post-insert alsactl restore" in the modules.conf file so it would 
> > be essentially a non issue from a user perspective.
> >
> > Couldn't this be saved in the config settings for alsactl?
> This whole database thing seems like overkill to me, to be honest. This is
> dynamic information would best be obtained from cards during operation,
> the only problem is that you have to lock the device. A better design would
> be to, if possible, allow the configuration space to be read even when a
> device is streaming.
> 
> I dont know the dirty details of writing drivers, but would this be a
> problem? Perhaps we could differ between read-locked and write-locked
> configuration, so there would be inclusive read access to the device, and
> totally exclusive access if it is to be modified.
> 
> Hope some of this makes sense
> 
> 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
> Alsa-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/alsa-devel
> 



-------------------------------------------------------
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/

Re: Query devices in a non-blocking fashion / 3D capabilties.

[Jaroslav Kysela]

On Sun, 14 Dec 2003, Manuel Jander wrote:

> I looked into "alsa-kernel/core/control.c" and after finding out that
> every control interaction does a control lookup (iterated through all
> controls), i don't feel very confortable about using kcontrols to update
> hardware parameters in at tens of milisecond intervals.

Use it. We can improve the lookup algorithm (use hashes etc.).

> Then i discovered the ALSA /proc interface, but the docs read "use for
> debugging". They have a lot less overhead. Would it be OK to use them
> for hardware parameter update ? And if so, why don't you use this
> interface for queries ? They seem to give much more freedom about
> locking and other issues.

No, the proc interface is not definitely for these things.

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
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/

Re: Query devices in a non-blocking fashion

[Jaroslav Kysela]

On Sun, 14 Dec 2003, Arve Knudsen wrote:

> On Mon, 15 Dec 2003 01:17:26 +0900, Patrick Shirkey 
> <pshirkey@boosthardware.com> wrote:
> 
> > If we have a DB of info how would we define the abilities of each device?
> >
> > I assume this info is available in the driver layer because there is a 
> > point where ALSA will return false eg. if a card is not able to run at 
> > 48000Hz
> >
> > My opinion is that a simple function could be included in alsactl which 
> > scans for available devices, makes a list of their abilities. Everyone 
> > uses "post-insert alsactl restore" in the modules.conf file so it would 
> > be essentially a non issue from a user perspective.
> >
> > Couldn't this be saved in the config settings for alsactl?
> This whole database thing seems like overkill to me, to be honest. This is
> dynamic information would best be obtained from cards during operation,
> the only problem is that you have to lock the device. A better design would
> be to, if possible, allow the configuration space to be read even when a
> device is streaming.
> 
> I dont know the dirty details of writing drivers, but would this be a
> problem? Perhaps we could differ between read-locked and write-locked
> configuration, so there would be inclusive read access to the device, and
> totally exclusive access if it is to be modified.

Again, the configuration space is runtime information and it might depend
if a stream is active for given card. So, information might be useless 
(different).

Again, much better is to give this information from the user space rather
than adding code to the drivers. We may also describe the constraints 
here.

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
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/

Re: Query devices in a non-blocking fashion

[Arve Knudsen]

On Mon, 15 Dec 2003 09:59:16 +0100 (CET), Jaroslav Kysela <perex@suse.cz> 
wrote:

> On Sun, 14 Dec 2003, Arve Knudsen wrote:
>
>> On Mon, 15 Dec 2003 01:17:26 +0900, Patrick Shirkey
>> <pshirkey@boosthardware.com> wrote:
>>
>> > If we have a DB of info how would we define the abilities of each 
>> device?
>> >
>> > I assume this info is available in the driver layer because there is a
>> > point where ALSA will return false eg. if a card is not able to run at
>> > 48000Hz
>> >
>> > My opinion is that a simple function could be included in alsactl 
>> which
>> > scans for available devices, makes a list of their abilities. Everyone
>> > uses "post-insert alsactl restore" in the modules.conf file so it 
>> would
>> > be essentially a non issue from a user perspective.
>> >
>> > Couldn't this be saved in the config settings for alsactl?
>> This whole database thing seems like overkill to me, to be honest. This 
>> is
>> dynamic information would best be obtained from cards during operation,
>> the only problem is that you have to lock the device. A better design 
>> would
>> be to, if possible, allow the configuration space to be read even when a
>> device is streaming.
>>
>> I dont know the dirty details of writing drivers, but would this be a
>> problem? Perhaps we could differ between read-locked and write-locked
>> configuration, so there would be inclusive read access to the device, 
>> and
>> totally exclusive access if it is to be modified.
>
> Again, the configuration space is runtime information and it might depend
> if a stream is active for given card. So, information might be useless
> (different).
>
> Again, much better is to give this information from the user space rather
> than adding code to the drivers. We may also describe the constraints
> here.
Will these constraints be updated during runtime, so they take the device's
current state into account, such as samplerate vs number of channels? I
hope this won't add to the complexity of ALSA-lib, though.

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/

Re: Query devices in a non-blocking fashion

[Giuliano Pochini]

On 08-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?

Yes, of course. Perhaps it can be done already with the current API. I
never investigated how the configuration process works, but I know the
driver can define rule functions to manage complex hw constraints.
Maybe you can change the snd_pcm_hardware_t structure according to the
new setting from those functions. I mean, the application calls
snd_pcm_hw_params_set_rate_near(96000);
The hw_rule function is called, which does pcmhw.channels_max=12;
Paul, Jaroslav, is it possible/legal ?


--
Giuliano.


-------------------------------------------------------
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/

Re: Query devices in a non-blocking fashion

[Paul Davis]

>I don't agree. The control API (usually) is for things that don't affect
>the way data is transferred between the card the the computer. 

it is *now*. i was just imagining a different conception of what it
could be used for.

>								Sample rate,
>format, etc. are used to configure the hardware at the driver level, but
>from the point of view of the application they are attributes of the
>substream. The application has to take them into account. It can't just
>open the PCM device and play/record something without knowing the
>format. 

if the app can't do that, it should first configure the device. no
question about that. the question is: what API do you use to do it? i
was just imagining that the PCM interface doesn't do any of it. this
would then decouple one from the other - you could interrogate
configuration possibilities independently of accessing the PCM device
itself, as arve suggests also.

>									   So
>you'll end up always using two different APIs to do the same things you now
>can do with only one.

i was imagining removing the capability from the PCM API.


-------------------------------------------------------
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/