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
> <[EMAIL PROTECTED]> 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
> [EMAIL PROTECTED]
> 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/
_______________________________________________
Alsa-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/alsa-devel
