[alsa-devel] Intel alsa sound request for Laptops

[John Frankish]

> > > > > > > > > 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".
>
Agreed, but using Xorg/vesa or Xvesa should work too.

> > (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?
> 
We're testing alsa so, no, I did not use pulseaudio.

> 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.
> 
I can understand the rationale behind using the first sound device the system discovers as the default sound device.

However, if the default sound device has been disabled by not loading i915, then alsa should be smart enough to use the next available sound device without the need to resort to obscure commands (snd_hda_intel.index=1,0) or additional software (pulseaudio).

Anyway, thanks for the time you took to explain all this - I guess I'll carry on without sound unless I really, really need it.