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.
- 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?
- 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).
- 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 :-)
- this chip has 3 ADC, each capable recording from different source, but alsa
uses only first.
OK, that's a bug.
- 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