[alsa-devel] [Alsa-user] Impossible to make subwoofer work on a Dell XPS M1710w
Takashi Iwai
tiwai at suse.de
Fri Aug 17 19:41:07 CEST 2007
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
More information about the Alsa-devel
mailing list