[alsa-devel] I want to improve Sigma-Tel STAC9227 driver / How to implement support for multiple ADC

[Takashi Iwai]

At Mon, 20 Aug 2007 04:48:52 +0300,
Maxim Levitsky wrote:
> 
> Hello,
> 
> I am a user of Sigma-Tel STAC9227 intel hda based chip.
> I have studied its documentation, and found that alsa driver doesn't support 
> number of its features.
> 
> 
> 1) it has "analog loop-back" which means it can mix sound just before it 
> enters ADC0 to output of DAC0 (headphones/front).
> For me it is the most important feature, since I have a tv card with analog 
> output.

I couldn't find it in the datasheet...  Is it just a matter of amp or
widget connection?

> 2) it has the ability to "swap" left/right channels, and this can be very 
> useful for LFE/center channel

This would be relatively easy (if we really need).

> 3) It has a VolumeKnob "widget" , that allows to decrease volume of all DACs 
> _after_ their own volumes were applied, and I think I turn it to "master 
> volume"

The problem is how to know whether this widget is really used or not.
(That is, whether the volume knob is implemented in this hardware)

> Those things below aren't supported by windows driver ether, but that doesn't 
> mean we can't support that :-)
> 
> 4) this chip has 3 ADC, each capable recording from different source, but alsa 
> uses only first.

OK, that's a bug.

> 5) I have 5.1 configuration, so DAC1 is unused.
> It is possible to connect it to "front" mic, and get 7.1 sound card
> I think about a option "Use front mic as output", for 3Stack configuration

Hm, but still too tricky to set up in that way.
You cannot imagine easily such a switch means 7.1 output.

For other codecs, we have "Channel Mode" enum.  The pins are set up
according to this value.  But, sigmatel code doesn't have this enum
list but rather individual switches.  It's slightly confusing, I
think.  From the easiness POV, I prefer the channel mode enum
solution.

> 1,2,3 are easy to implement, since those are just mixer switches.

Not really.  patch_sigmatel.c is written to be as generic as
possible.  Thus, if you add something special for a specific device,
you should be careful not to break others.

> But I have a question about 4:
> 
> Now the driver has buggy support for second ADC, it record from it, but fails 
> to connect it to any input source, and unmute it.
> 
> I can fix that and trivially add support for third ADC, but current driver 
> makes all ADCs a sub-streams of a single  PCM device.
> 
> I think that sub-streams are meant to be used only by playback PCMs that have 
> hardware support of mixing,

No, it's misunderstanding :)

> so I feel that is is better  to make  each ADC to 
> be a separate PCM device, with separate  mixer controls (enabled/input 
> source/gain), and I want to ask you whenever you agree with me.

... thus I disagree.  And, the mixer controls can be provided
separately anyway (as other codecs already do).

> Also I noticed that dsnoop chokes on record streams with more that one 
> substream, it fails with error, when I try to open second arecord.

Yes, and note that it's the intentional behavior.

The problem is _not_ that the secondary capture is assigned to the
secondary substream.  As long as you use the default PCM, it'll be not
accessed anyway.  The problem is rather that currently the overall
design doesn't suit for the multi-stream environment.

We provide "default" PCM for the generic purpose.  That's fine.  It's
a mighty ace that can be used for everything.  Now we have a second
guy.  But we have no standard symbolic name for him.  It's possible to
access via hw:0,0,1.  It's however ugly, cryptic and even bare.  We
need to provide a more understandable symbolic PCM definition with the
decoration of plugins.  This is what is missing so far.  Thus it's
basically not a driver issue but an alsa-lib issue.


thanks,

Takashi