I looked it up, and according to the information here (Subsystem: Dell Unknown device 01ce, Dell XPS M1710), your system should have a Stac9200 in it and it has been supported (in hg) since Feb 13. Make sure you are not specifying any model in the /etc/modprobe.conf or /etc/modprobe.d/* files.
Also, if you are still having issues, run http://bulletproof.servebeer.com/alsa/scripts/alsa-info.sh and post the resulting file. It will have most of the debugging info that we need.
Tobin
On Fri, 2007-08-17 at 19:41 +0200, Takashi Iwai wrote:
At Fri, 17 Aug 2007 19:09:36 +0200, Michael Gerdau wrote:
[crossposting to alsa-devel as adviced in ALSA-Configuration.txt]
The model option is _the_ important option for HD-audio driver. It overrides the configuration preset. As default, the driver reads the PCI (subsystem) IDs to identify which configuration preset to use. If not found, the driver does a guess work from the BIOS setup in most cases.
Now, since many laptops are shipped with broken BIOS and the guess work is imperfect, you often face the famous problem -- "sound doesn't work" (great words that explain everything). Then you can pass model option for the preset designed for anohter hardware (e.g. model=thinkpad) to make the driver probe as if it's such a hardware. If you are lucky, your device is similar with others, and the driver works with such a preset. If not, we'd need to hack another preset for matching with your device.
The list of available model option is found in ALSA-Configuration.txt.
So it seems the Dell XPS M1710 isn't yet listed among the known models and also does not seem to be detected properly (as of hg20070816).
The sigmatel codec support is somewhat different from other codes. It tries to be as generic as possible, based only on the pin configuration without pre-defined mixer definitions and init verbs.
Do you mean a problem with the missing LFE? The missing LFE sounds like a different problem. AFAIK, the device itself _is_ set up properly as expected. It's likely a feature regression due to the improvements on the support of other devices with STAC codec chips. Or any other issue? Maybe it's better to describe the problem again here for guys who only read alsa-devel ML (I mostly do so, too). And, if it's about debugging, let's discuss on alsa-devel ML and drop Cc from alsa-users.
'lspci -v' gives: ... 00:1b.0 Audio device: Intel Corporation 82801G (ICH7 Family) High Definition Audio Controller (rev 01) Subsystem: Dell Unknown device 01ce Flags: bus master, fast devsel, latency 0, IRQ 21 Memory at efffc000 (64-bit, non-prefetchable) [size=16K] Capabilities: [50] Power Management version 2 Capabilities: [60] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0 Enable- Capabilities: [70] Express Unknown type IRQ 0 Capabilities: [100] Virtual Channel Capabilities: [130] Unknown (5) ...
'lspci -nv' gives: ... 00:1b.0 Class 0403: 8086:27d8 (rev 01) Subsystem: 1028:01ce Flags: bus master, fast devsel, latency 0, IRQ 21 Memory at efffc000 (64-bit, non-prefetchable) [size=16K] Capabilities: [50] Power Management version 2 Capabilities: [60] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0 Enable- Capabilities: [70] Express Unknown type IRQ 0 Capabilities: [100] Virtual Channel Capabilities: [130] Unknown (5) ...
Anything else I could do to help getting it (fully) supported ?
Why not patch the code :)
... or, we'd need more detailed information. Which codec chip is on it, and which pin widget corresponds to the actual I/O, especially the pin NID of the missing feature must be identified. It can be done only by the owner (tester) of the hardware. Developers don't have your device.
As a hint, if it's really a regression, try to revert to the version it did work. Check /proc/asound/card0/codec#* file to see which widget is changed by the LFE volume. That's the vital information.
Takashi _______________________________________________ Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel