On Tue, 31 Jan 2017 09:37:46 +0100, John Frankish wrote:
> 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).
Sorry, ALSA layer isn't designed to be smart. It's rather dumb, gives simply what the kernel provides. You can implement many things on top of it in a form of plugins, but the basic policy is not to modify the given stuff, and pass it as is.
And, as mentioned, such a smartness can be implemented in another layer where you have a better view over the whole devices, too.
Takashi