hardware-dependent features

hardware-dependent features

[Daniel Mack]

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

Re: hardware-dependent features

[Lee Revell]

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

Re: hardware-dependent features

[Clemens Ladisch]

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

Re: hardware-dependent features

[Daniel Mack]

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

Re: hardware-dependent features

[Eliot Blennerhassett]

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

Re: hardware-dependent features

[Clemens Ladisch]

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