Created attachment 133771 [details]
output from alsa-info.sh
Sound quality is poor with my new HP Spectre 13 Ultrabook. Although it has a builtin subwoofer it is not used in Linux.
I tried overwriting unconnected pins with hda-jack-retask as described for chips like 92HD91BXX, without success.
Adding "options snd-hda-intel model=ref" to alsa-base.conf did not improve sound either.
Created attachment 133781 [details]
output from alsa-info.sh (plaintext)
if you look at the digaram at the first page of datasheet
BTL is connected to two portd r pins and two portd l pins
try hda analyzer to change port d 's BTL
Node 0x0d [Pin Complex] wcaps 0x400501: Stereo
Control: name="Speaker Phantom Jack", index=0, device=0
Pincap 0x00010050: OUT EAPD Balanced
EAPD 0x2: EAPD
Pin Default 0x93170110: [Fixed] Speaker at Int Left
Conn = Analog, Color = Unknown
DefAssociation = 0x1, Sequence = 0x0
Misc = NO_PRESENCE
Pin-ctls: 0x40: OUT
pincap supported balanced
functional block diagram
you need to study datasheet 7.1 widget list
1Ah VSW BTL register access
hda_analyzer crashes with:
ValueError: wrong proc file format (unknown dig1 bit 'KAE')
These are all the pins I can retask (screenshot)
Created attachment 133821 [details]
if you look at the functional block diagram or widget diagram, there are only two output pin complexes port A and port D which support balanced output
all the unconnected pin complex support input only
What does that mean for my subwoofer?
Refer to the functional block diagram, there is no low pass filter ,
just 5 band EQ, high pass filter, digital PWM controller and BTL for port D
8. The pin function “BTL” indicates balanced output drivers presumably driving hard wired speakers. This implies two output pins for each channel or four output pins for a typical stereo Pin Widget. While the additional outputs and associated amplifiers may be reconfigured from another port or Pin Widget, they must logically appear as a single Pin Widget; i.e., if a stereo Pin Widget was switched to BTL output, it must remain stereo and switch to four output pins rather than two. Similar to the example in rule #7, a headphone jack may be shared with external speakers; in this case, instead of switching an external (EAPD) signal, the Pin Widget would be switched from standard jack (two pin) output to BTL (four pin) output. If a Pin Widget supported BTL exclusively (no sharing), then the “BTL Capable” bit in the Pin Capabilities parameter would be set, and the “Output Capable” bit would be cleared. If the Pin Widget supported headphone jack sharing, then both “BTL Capable” and “Output Capable” bits would be set, and the output mode of the Pin Widget would be controlled by the function driver, after consulting the “Presence Detect” bit.
Sadly I don't understand this pin architecture. I just keep asking myself how Windows handles this subwoofer to be adressed if its "technically not possible"...
it is unlikely to use port a if the codec support combo Jack detection
2.20.Combo Jack Detection 4 conductor (combo) jacks are becoming popular. In the most common implementation the 4 conductor plug has the same mechanical dimensions as a 3 conductor 3.5mm plug but the sleeve portion has been split into two segments:S1 and S2. When a 4-conductor plug (headset) is inserted into the jack T (Tip) = Left headphone audio, R (Ring) = Right headphone audio, S1 (First half of sleeve) = microphone input, and S2 (Second half of sleeve) = return (GND). When a 3-conductor plug (headphones) is inserted into the jack; T=Left audio, R=Right audio, S1=GND, S2=GND. By monitoring the S1 connection to see if it is shorted to ground, we can distinguish between headsets and headphones. Please note that analog microphone plugs (3-conductor-Lmic/Rmic/GND) and optical SPDIF plugs can not be supported using this implementation.
2.17.Class-D BTL Amplifier An integrated class-D stereo BTL amplifier is provided to directly drive 4 ohm speakers (2W @ 4.75V) or 8 ohm speakers (1W @ 4.75V). No external filter is needed for cable runs of 18” or less. An internal DC blocking filter prevents distortion when the audio source has DC content, and prevents unintentional power consumption when pausing audio playback. The amplifier may be controlled using the EAPD pin (see EAPD section.) Using a vendor specific verb, the BTL amplifier may be configured to support a mono speaker connected to the L +/- pins. In this mode, the Left and Right audio is mixed and sent to the left output only. The right channel is turned off to conserve power. Maximum gain for the BTL amplifier is programmable. The following 4 gain settings relative to a nominal line output are desired: +6.5dB, +9.5dB, +14.5dB, +16.5dB. Absolute gain may vary and the suggested accuracy is +/-1.5dB. This gain is exposed in a vendor specific widget and is intended to mimic the pin programmable gain implemented in discrete BTL amplifiers commonly used in notebook computers. The BTL amplifier includes thermal management circuitry. When the CODEC reaches a temperature of about 140 degrees, the output amplitude of the BTL amp is gradually lowered until the temperature falls below 140. All other functions will remain active if the BTL amplifier is shut down due to die temperature.
From an end-users point of view: Will ALSA support it?
any url of your notebook specification ?
are you sure that your note book have subwoofer ?
Beats Audio™ with 2 speakers
Well, it has a deep bass and full sound with Windows - which it does not have with Linux.
Usually such a bass speaker is controlled either via an individual audio pin (which corresponds to a pin widget of HD-audio codec), EAPD bit of the speaker pin, some GPIO pin, or some VREF bits of some pin(s). It can be even vendor-specific verbs, but I don't think this is the case for HP.
As a start, try to pass model=hp-envy-bass,hp-envy-bass option. (Here you need to pass twice just to be sure to reach to the proper codec.) If this doesn't work, again upload alsa-info.sh output during testing it.
Created attachment 134261 [details]
alsa-info with model=hp-envy-bass,hp-envy-bass
No change with
options snd-hda-intel model=hp-envy-bass,hp-envy-bass
Test with newer kernels, at least 3.14.
Also, build the kernel with CONFIG_SND_DEBUG=y, if not set.
No change with Kernel 3.14.2-031402-generic (CONFIG_SND_DEBUG=y)
see new alsa-info.txt
Created attachment 134551 [details]
alsa-info with 3.14.2
OK, this is with 92HD95, so the existing model option doesn't take effect.
And, there are indeed only two output pins on this codec, so the quirk won't work in anyway.
Another possibility would be GPIO, as already mentioned. There are 4 GPIO pins, so try to turn on/off and set in/out direction for each. For example, the commands below sets the GPIO 0 bit to the out direction:
hda-verb /dev/snd/hwC1D0 SET_GPIO_MASK 0x01
hda-verb /dev/snd/hwC1D0 SET_GPIO_DIR 0x01
hda-verb /dev/snd/hwC1D0 SET_GPIO_DATA 0x01
Change the value to 0x02, 0x04 and 0x08 in order to check each GPIO pin.
You can set SET_GPIO_DIR value either 0 and non-zero for each time, too. This checks both in and out directions.
And, another primary question: does your machine has really a separate bass speaker? In many cases, the bass effect is just a fake -- it's amplified in the software.
I tried the commands but it keeps printing
usage: hda-verb [option] hwdep-device nid verb param
-l List known verbs and parameters
-L List known verbs and parameters (one per line)
Another question: Do the changes take effect immediately or do I have to restart
Which application do I have to use? VLC? Totem?
Should I remove the options line from alsa-base.conf?
Actually I could not find any information about the speaker configuration in my notebook. If it is software-based amplified it is damn good amplified. In Windows there is an option for disabling BeatsAudio(R) which results in a sound like in Linux now.
My bad, pass like
hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_MASK 0x01
The values 0x02, 0x04, 0x08 should be changed only the last argument. The second argument 0x01 must be same for all GPIO pins.
Usually the effect takes place immediately, so you should be able to notice by testing it while playing something. BTW, some GPIO pins may influence on other things, such as the mute LED, etc. If you find such, let me know, too.
The Music did not even take a skip. Also I pressed the mute/unmute button each time after command set; the LED did not light.
The command itself (might) turn on/off LED or take some effect, if any.
The mute button (or any other buttons) doesn't play any role unless bound in the driver.
After trying an equalizer I could not achieve any bass quality similar to the Windows sound.
you are unlikely to get low frequency since the high pass filter is enabled by default with cutoff at 300Hz to protect the speakers attached to BTL ampilifer
2.18.BTL Amplifier High-Pass Filter
For mobile applications, speakers are often incapable of reproducing low frequency audio and unable to handle the maximum output power of the BTL amplifier. A high-pass filter is implemented in the BTL output path to reduce the amount of low frequency energy reaching speakers attached to the BTL amplifier. This can prevent speaker failure.
2.18.1.Filter Description The high-pass filter is derived from the common biquadratic filter and provides a 12dB/octave roll-off. The filter may be programmed for a -3dB response at: 100Hz, 200Hz, 300Hz, 400Hz, 500Hz, 750Hz, 1KHz, or 2KHz. The high pass filter is enabled by default with a cut-off frequency of 300Hz. The filter may be bypassed using the associated verb (processing state verb). The analog PC_Beep input is not affected by the digital high-pass filter. To ensure that the speakers attached to the BTL amplifier are not harmed by low frequency audio entering the PC_Beep input, an external filter must be implemented.
The high-pass filter is possible, and if any, it's done in BIOS. Unfortunately, IDT (and other codec vendors) never exposes the information about such vendor-specific EQ setups. So, we can't cover it by now.
Meanwhile, HP BIOS tends not to set up the equalizer as default. That's why we had to apply the EQ setup manually in the driver for some 2013 HP models.
In anyway, unless confirmed that it's an individual bass speaker, it's not strictly a kernel driver issue. Even if the hardware EQ is involved, we can't fix it for now due to lack of information. So, this bug is WONTFIX for now.
Feel free to reopen if you gain more information that helps the kernel driver implementation (e.g. you found the pin corresponding to the separate bass speaker, or GPIO, EAPD or VREF triggers the bass). Thanks.
Thanks to a German blogger I could improve the sound at least a bit via the following verbs:
hda-verb /dev/snd/hwC1D0 0x1a 0x795 0x00
As he writes on  it is possible to disable the high pass filter.
0×1A addresses the NID of the amplifier as he found on page 194 of the document ("7.21.4. AdvancedFunctions (NID = 1Ah): Cntrl3").
Furthermore, page 196 describes the verb 0×795 which configures the high pass filter. It seems to be set to a "somewhat" high level of 750 Hz by HPs BIOS. 0×00 sets this value to 100 Hz.
Now the sounds on Linux resembles the Windows sound when BeatsAudio is deactivated. Which is really better than before.
In order to achieve a BeatsAudio-like full-bass sound, the author of the blog post assumes the Windows driver to be making use of an "exciter with a big bottom". Page 204 describes an equalizer which would be handy for such a task.
Good to know that it's really a HPF issue. Then you can try "0x1a 0x782 0x00" instead. This will bypass the whole BTQ EQ and HPF.
I tried it and cannot hear a difference between 0x795 and 0x782.
I have to correct myself. I tested the verbs again after a restart.
0x795 improves the sound; 0x782 does nothing alone, nothing hearable at least.
OK, so the BTL HPF must be enabled even if you want no filtering. Or, the parameter doesn't work as written in the documentation.
In anyway, if you're happy with the setup, try the patch below. It should apply the same workaround as default in the driver itself.
Created attachment 139881 [details]
A fixup patch
Your patch works like a charme with Kernel 3.15.1.
Thank you very much.
Another update, concerning the mute LED.
hda-verb /dev/snd/hwC1D0 0x01 SET_GPIO_MASK 0x08
hda-verb /dev/snd/hwC1D0 0x01 SET_GPIO_DIR 0x08
hda-verb /dev/snd/hwC1D0 0x01 SET_GPIO_DATA 0x08
enables the mute LED.
Any other (!= 0x08) disables it. In fact, setting the MASK is sufficient to disable it, no need to run the other commands _DIR and _DATA.
OK, what about the revised patch below? Usually HP BIOS should set up a DMI string indicating the LED support. Hopefully your BIOS does it right.
Created attachment 140701 [details]
I compiled it again with 3.15.1, the sound is still fine but the mute LED does not work accordingly, neither when pressing mute nor when decreasing volume.
OK, then maybe the necessary DMI entry is missing. Please attach the output of dmidecode program.
Created attachment 140821 [details]
Output from dmidecode
It contains the following:
Handle 0x0011, DMI type 11, 5 bytes
String 1: $HP$
String 2: LOC#ABD
String 3: ABS 70/71 78 79 7A 7B
String 4: CNB1 0973100400405F10000120183
String 5: HP_Mute_LED_P_G
This means that your BIOS is incomplete, doesn't fill the right values there. The "P" and "G" should have been some real numbers.
So, in this case, we must assume the GPIO pin number and the polarity statically.
The revised patch is below. Give it a try.
Created attachment 140831 [details]
Revised patch (v3)
Works perfectly with your patch and Kernel 3.15.1. Sound and mute LED.
OK, the patch is merged to sound git tree.
It'll be likely included in 3.16-rc3, and eventually backported to stable kernels.
Thanks for testing.
The right set for 0x782 is 0x61 - bit 0, bit 5 and bit 6
This bypass all filters.
hda-verb /dev/snd/hwC1D0 0x1a 0x782 0x61
This work on laptop HP G1 350 with last Ubuntu 14.04, Linux Mint 17.2, Debian...