[alsa-devel] Kernel 3.2, and "speaker" controlling headphone path
It seems like on one machine the "Speaker Playback Volume" was part of the headphone path, in combination with PulseAudio this is leading to muted headphones.
One of my colleagues wrote a workaround for that specific machine - I'm providing links in case you're interested:
The patch: https://launchpadlibrarian.net/109499922/restrict_bass.patch
Alsa-info: https://launchpadlibrarian.net/109251353/bad-kernel-yes-headphones.txt
Bug link: https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/994685
At Wed, 11 Jul 2012 12:50:20 +0200, David Henningsson wrote:
It seems like on one machine the "Speaker Playback Volume" was part of the headphone path, in combination with PulseAudio this is leading to muted headphones.
One of my colleagues wrote a workaround for that specific machine - I'm providing links in case you're interested:
The patch: https://launchpadlibrarian.net/109499922/restrict_bass.patch
Alsa-info: https://launchpadlibrarian.net/109251353/bad-kernel-yes-headphones.txt
Bug link: https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/994685
This doesn't happen with the recent kernel, right?
As far as I've tested with hda-emu, 3.6 kernel picks up the headphone path as the primary, as this has the least badness value.
thanks,
Takashi
On 07/16/2012 11:33 AM, Takashi Iwai wrote:
At Wed, 11 Jul 2012 12:50:20 +0200, David Henningsson wrote:
It seems like on one machine the "Speaker Playback Volume" was part of the headphone path, in combination with PulseAudio this is leading to muted headphones.
One of my colleagues wrote a workaround for that specific machine - I'm providing links in case you're interested:
The patch: https://launchpadlibrarian.net/109499922/restrict_bass.patch
Alsa-info: https://launchpadlibrarian.net/109251353/bad-kernel-yes-headphones.txt
Bug link: https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/994685
This doesn't happen with the recent kernel, right?
As far as I've tested with hda-emu, 3.6 kernel picks up the headphone path as the primary, as this has the least badness value.
Correct. The issue was not present on 3.0 and 3.4. It was present in 3.2 and 3.3, and fixed with commit 1c4a54b4513c175ba (ALSA: hda/realtek - Finer tuning of auto-parser with badness evaluation), but that commit felt to risky to just backport/apply to 3.2.
participants (2)
-
David Henningsson -
Takashi Iwai