[alsa-devel] hardware-dependent features
Hi,
some of the devices the caiaq driver supports have special hardware features such as switchable ground lift, input impedance selection or other, hardware-specific features. On both Windows and MacOSX there are special tools to set those features but the ALSA driver still lacks support for them which I want to change soon. However, I couldn't find a generic way to do that. I was thinking about a sysfs entry which is attached to the sound card instance but didn't find a driver which did similar things.
Also, I'd like to support the LEDs and displays on the devices and was wondering which interface to choose for that. I've got a patch ready which uses the generic led subsystem, but that approach seems to be a bit ugly as I end up having one entry per led on each device in one single folder. Any idea of a better way?
Thanks, Daniel
On Nov 12, 2007 8:13 AM, Daniel Mack daniel@caiaq.org wrote:
Hi,
some of the devices the caiaq driver supports have special hardware features such as switchable ground lift, input impedance selection or other, hardware-specific features. On both Windows and MacOSX there are special tools to set those features but the ALSA driver still lacks support for them which I want to change soon. However, I couldn't find a generic way to do that. I was thinking about a sysfs entry which is attached to the sound card instance but didn't find a driver which did similar things.
Use the ALSA mixer API.
Lee
Daniel Mack wrote:
Also, I'd like to support the LEDs and displays on the devices and was wondering which interface to choose for that. I've got a patch ready which uses the generic led subsystem, but that approach seems to be a bit ugly as I end up having one entry per led on each device in one single folder. Any idea of a better way?
I've used three 'mixer' controls for the three LEDs of the SB Audigy 2 NX. Whether this is a good idea depends on how many LEDs there are, and how one might want to use them. Are there LED displays, i.e., multiple LEDs in a row?
I think the displays could by controlled by mixer controls of type "bytes". Usual mixer applications can't handle those, but this is quite hardware dependent anway ...
Regards, Clemens
Hi Clemens,
On Nov 12, 2007, at 6:26 PM, Clemens Ladisch wrote:
I've used three 'mixer' controls for the three LEDs of the SB Audigy 2 NX. Whether this is a good idea depends on how many LEDs there are, and how one might want to use them. Are there LED displays, i.e., multiple LEDs in a row?
Depends. There is one device which has 4 user-assignable LEDs, some others have up to >35 LEDs which can be dimmed in 64 steps, yet another one has 7-segment LED displays.
What I would like to achieve is a conventient way of accessing them, probably from the command line via some procfs or sysfs manner so users can even use scripts to switch them on and off if they like.
I think the displays could by controlled by mixer controls of type "bytes". Usual mixer applications can't handle those, but this is quite hardware dependent anway ...
But is that really where it belongs to? I would think that LEDs and input functions are not related to audio and thus should be handled by some other, more appropriate or maybe even proprietary subsystem.
There are some features which have influcence on the audio behaviour since they affect the way the signal is processed, but LEDs are certainly not, are they?
Is it ok to attach own, device-specific sysfs entries to device folders created by ALSA? I could imagine having a "leds" subdir with all the possible entries in it. The sysfs layer is easy to handle so there wouldn't be much overhead. This way, we would have those features releated to the audio device but wouldn't need to abuse the mixer API. Or is that a no-go?
Regards, Daniel
I would also advocate using controls...
Daniel Mack wrote:
Hi Clemens,
On Nov 12, 2007, at 6:26 PM, Clemens Ladisch wrote:
I've used three 'mixer' controls for the three LEDs of the SB Audigy 2 NX. Whether this is a good idea depends on how many LEDs there are, and how one might want to use them. Are there LED displays, i.e., multiple LEDs in a row?
Depends. There is one device which has 4 user-assignable LEDs,
4 boolean controls
$ amixer cset 'Led 3' on
some
others have up to >35 LEDs which can be dimmed in 64 steps, yet
Is that 64 steps each, or all together? (i.e one dim control + 35 booleans, or 35 dim controls)
another one has 7-segment LED displays.
integer or enumerated control.
What I would like to achieve is a conventient way of accessing them, probably from the command line via some procfs or sysfs manner so users can even use scripts to switch them on and off if they like.
I think the displays could by controlled by mixer controls of type "bytes". Usual mixer applications can't handle those, but this is quite hardware dependent anway ...
But is that really where it belongs to? I would think that LEDs and input functions are not related to audio and thus should be handled by some other, more appropriate or maybe even proprietary subsystem.
There are some features which have influcence on the audio behaviour since they affect the way the signal is processed, but LEDs are certainly not, are they?
I would think of them as "controls" on the device rather than "mixer". you have options of enumerated, integer, boolean, (or bytes)
In addition you can specify an index as well as a name.
"Led", index=23 or "Led 23"
I'm not sure if you can add controls to an "interface" other than "MIXER" (ie. "CARD") Other ALSA devs please answer...
-- Eliot
Daniel Mack wrote:
On Nov 12, 2007, at 6:26 PM, Clemens Ladisch wrote: What I would like to achieve is a conventient way of accessing them, probably from the command line via some procfs or sysfs manner so users can even use scripts to switch them on and off if they like.
The amixer tool can access any control.
I think the displays could by controlled by mixer controls of type "bytes". Usual mixer applications can't handle those, but this is quite hardware dependent anway ...
But is that really where it belongs to? I would think that LEDs and input functions are not related to audio and thus should be handled by some other, more appropriate or maybe even proprietary subsystem.
There are some features which have influcence on the audio behaviour since they affect the way the signal is processed, but LEDs are certainly not, are they?
The LEDs are part of the device, so it makes sense to use them in some manner related to audio.
Is it ok to attach own, device-specific sysfs entries to device folders created by ALSA?
It's possible, but so far, it hasn't been necessary.
This way, we would have those features releated to the audio device but wouldn't need to abuse the mixer API.
It's actually called the "control API" because it can be used to provide controls of all kinds, not only related to mixing.
I'd stronly recommend to use the control API. While it is possible to use sysfs for the same purpose, I don't see any advantage over the control API.
Regards, Clemens
participants (4)
-
Clemens Ladisch -
Daniel Mack -
Eliot Blennerhassett -
Lee Revell