[alsa-devel] Intel alsa sound request for Laptops
Takashi Iwai
tiwai at suse.de
Tue Jan 31 09:16:21 CET 2017
On Tue, 31 Jan 2017 08:47:54 +0100,
John Frankish wrote:
>
> > > > > > > > That said, if you boot without i915, drop the index option.
> > > > > > > >
> > > > > > > I booted without i915 and did not set any index options (the
> > > > > > > default behaviour of tinycorelinux is to boot clean like a
> > > > > > > live-CD
> > > > > > > distro)
> > > > > > >
> > > > > > Ah OK, that's the way the current HD-audio driver behaves.
> > > > > > It takes the card at first, then it leaves when the i915 component binding fails (like nomodeset).
> > > > > > It's good to keep the device assignment consistent. OTOH, it may leave the card#0 empty as a result.
> > > > > > So this is the expected behavior.
> > > > > >
> > > > > Great - so the expected behaviour is for it to fail :P
> > > >
> > > > Yeah, "fail" to your expectation, unfortunately.
> > > >
> > > >The nomodeset or whatever disabling KMS itself is already the hackish workaround, and it's in a sort of abnormal state.
> > > >
> > > I disagree - in fact I was wrong to state that Xorg was using the modesetting driver, further down Xorg.0.log
> > > I see that the modesetting driver is unloaded and the vesa driver is used instead.
> > >
> > > The use of the vesa driver is not hackish and especially not when i915 has a serious bug and the Intel driver is not stable.
> >
> > Such a buggy state *is* already abnormal, no?
> > It should be fixed instead of the forever workaround.
> >
> I found four or five bug reports for i915, but nothing indicating that it was fixed in the latest kernel versions.
Of course some bugs do remain and some bugs are introduced in new
kernels. But it still means that it's buggy and you shouldn't take it
as "normal".
> (I'm using 4.2.9)
Oh, it's very very old. And, HSW/BDW platforms work fine on the
latest kernels. (I'm writing from such a laptop now.)
> > > > > Is there any chance of that being fixed in the future?
> > > > >
> > > > As already mentioned, the "fix" is to use PA.
> > > >
> > > Using pulseaudio is not going to fix the broken analogue sound when
> > > the i915 driver is not loaded
> >
> > Did you really test it? If yes, please give the log.
> >
> As per earlier in the thread:
>
> $ aplay -l
> **** List of PLAYBACK Hardware Devices **** card 1: PCH [HDA Intel
> PCH], device 0: ALC3226 Analog [ALC3226 Analog]
> Subdevices: 1/1
>
> $ alsamixer
> cannot open mixer: No such file or directory
You didn't use PA, right?
If you use PA, the hole of the card 0 doesn't matter. PA probes the
all devices and manages the right one. Also, there is pulse
alsa-plugins, and this allows the native ALSA-API apps to talk with
PA.
I feel like a broken record, but let me repeat:
if you don't use PA, you need the manual adjustment.
In short, pass snd_hda_intel.index=1,0 option no matter whether to
pass nomodeset or not when you're using a HSW or BDW machine and
seeing such a problem. Then the analog audio will be assigned to
card#0.
There is no "fix" in the ALSA side, because it's no real issue in ALSA
layer. ALSA driver and lib are for low-level accesses, and they don't
assure the full automation in a high-level device management. The
policy decision -- which device to be preferred -- is such a
high-level management. If you don't agree with the system default
values, it needs the manual adjustment.
This is normal in allover the kernel drivers: think of other devices,
e.g. eth0 vs eth1, or /dev/sda vs /dev/sdb.
Takashi
More information about the Alsa-devel
mailing list