Intel alsa sound request for Laptops

Intel alsa sound request for Laptops

[John Frankish]

For two or three kernel versions of alsa divers now, HDMI has been the default alsa device on my laptop (Dell Latitude E7240) - this does not make logical sense.

In the latest kernel version I use, 4.2.9, alsa sound will not work at all unless I load the i915 kernel driver - this does not make logical sense and means that I cannot use Xvesa.

Is it possible to make an alsa feature request for analogue sound to be the default alsa device on laptops and for alsa sound to work without the need to load the i915 kernel driver?

Regards
John

**** List of PLAYBACK Hardware Devices ****
card 0: HDMI [HDA Intel HDMI], device 3: HDMI 0 [HDMI 0]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 0: HDMI [HDA Intel HDMI], device 7: HDMI 1 [HDMI 1]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 0: HDMI [HDA Intel HDMI], device 8: HDMI 2 [HDMI 2]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 1: PCH [HDA Intel PCH], device 0: ALC3226 Analog [ALC3226 Analog]
  Subdevices: 1/1
  Subdevice #0: subdevice #0

Re: Intel alsa sound request for Laptops

[Takashi Iwai]

On Sat, 28 Jan 2017 13:46:57 +0100,
John Frankish wrote:
> 
> For two or three kernel versions of alsa divers now, HDMI has been the default alsa device on my laptop (Dell Latitude E7240) - this does not make logical sense.
> 
> In the latest kernel version I use, 4.2.9, alsa sound will not work at all unless I load the i915 kernel driver - this does not make logical sense and means that I cannot use Xvesa.
> 
> Is it possible to make an alsa feature request for analogue sound to be the default alsa device on laptops and for alsa sound to work without the need to load the i915 kernel driver?

It's a configuration issue.  Pass the module option if you prefer the
secondary device:

  options snd-hda-intel index=1,0


Takashi

Re: Intel alsa sound request for Laptops

[John Frankish]

> > For two or three kernel versions of alsa divers now, HDMI has been the default alsa device on my
> > laptop (Dell Latitude E7240) - this does not make logical sense.
> >
> > In the latest kernel version I use, 4.2.9, alsa sound will not work at all unless I load the i915 kernel driver
> > - this does not make logical sense and means that I cannot use Xvesa.
> >
> > Is it possible to make an alsa feature request for analogue sound to be the default alsa device on
> > laptops and for alsa sound to work without the need to load the i915 kernel driver?
> >
> It's a configuration issue.  Pass the module option if you prefer the secondary device:
> 
> options snd-hda-intel index=1,0
> 
Sure, I realise I can do that, but it's not the point and it's awkward to do so with the "live CD-type" distro I use (tinycorelinux).

Laptop sound should work in standalone mode by default - i.e. if laptop uses analogue sound for its built-in speakers then the alsa default should be analogue sound.

The above notwithstanding, analogue sound should work without needing to load the i915 kernel driver.

Re: Intel alsa sound request for Laptops

[Takashi Iwai]

On Sat, 28 Jan 2017 17:54:29 +0100,
John Frankish wrote:
> 
> > > For two or three kernel versions of alsa divers now, HDMI has been the default alsa device on my
> > > laptop (Dell Latitude E7240) - this does not make logical sense.
> > >
> > > In the latest kernel version I use, 4.2.9, alsa sound will not work at all unless I load the i915 kernel driver
> > > - this does not make logical sense and means that I cannot use Xvesa.
> > >
> > > Is it possible to make an alsa feature request for analogue sound to be the default alsa device on
> > > laptops and for alsa sound to work without the need to load the i915 kernel driver?
> > >
> > It's a configuration issue.  Pass the module option if you prefer the secondary device:
> > 
> > options snd-hda-intel index=1,0
> > 
> Sure, I realise I can do that, but it's not the point and it's awkward to do so with the "live CD-type" distro I use (tinycorelinux).
> 
> Laptop sound should work in standalone mode by default - i.e. if laptop uses analogue sound for its built-in speakers then the alsa default should be analogue sound.
> 
> The above notwithstanding, analogue sound should work without needing to load the i915 kernel driver.

For a smart automation, use PulseAudio.  It's exactly for such a
purpose.

The kernel driver assigns each device just in the order how they are
enumerated.  In the case of HD-audio, it's the order of PCI devices.
It's nothing different from any other PCI drivers.


Takashi

Re: Intel alsa sound request for Laptops

[John Frankish]

> > > > For two or three kernel versions of alsa divers now, HDMI has been 
> > > > the default alsa device on my laptop (Dell Latitude E7240) - this does not make logical sense.
> > > >
> > > > In the latest kernel version I use, 4.2.9, alsa sound will not 
> > > > work at all unless I load the i915 kernel driver
> > > > - this does not make logical sense and means that I cannot use Xvesa.
> > >> 
> > > > Is it possible to make an alsa feature request for analogue sound 
> > > > to be the default alsa device on laptops and for alsa sound to work without the need to load the i915 kernel driver?
> > > >
> > > It's a configuration issue.  Pass the module option if you prefer the secondary device:
> > > 
> > > options snd-hda-intel index=1,0
> > > 
> > Sure, I realise I can do that, but it's not the point and it's awkward to do so with the "live CD-type" distro I use (tinycorelinux).
> >
> > Laptop sound should work in standalone mode by default - i.e. if laptop uses analogue sound
> > for its built-in speakers then the alsa default should be analogue sound.
> > 
> > The above notwithstanding, analogue sound should work without needing to load the i915 kernel driver.
> > 
> For a smart automation, use PulseAudio.  It's exactly for such a purpose.
> 
> The kernel driver assigns each device just in the order how they are enumerated.
> In the case of HD-audio, it's the order of PCI devices.
> It's nothing different from any other PCI drivers.
>
OK, but I should not have to add bloat like pulseaudio in order to have basic sound functionality.

You also don't mention why I should have to load a graphics driver (i915) in order to get analogue sound? That makes no sense at all...

Re: Intel alsa sound request for Laptops

[Takashi Iwai]

On Sun, 29 Jan 2017 06:27:29 +0100,
John Frankish wrote:
> 
> > > > > For two or three kernel versions of alsa divers now, HDMI has been 
> > > > > the default alsa device on my laptop (Dell Latitude E7240) - this does not make logical sense.
> > > > >
> > > > > In the latest kernel version I use, 4.2.9, alsa sound will not 
> > > > > work at all unless I load the i915 kernel driver
> > > > > - this does not make logical sense and means that I cannot use Xvesa.
> > > >> 
> > > > > Is it possible to make an alsa feature request for analogue sound 
> > > > > to be the default alsa device on laptops and for alsa sound to work without the need to load the i915 kernel driver?
> > > > >
> > > > It's a configuration issue.  Pass the module option if you prefer the secondary device:
> > > > 
> > > > options snd-hda-intel index=1,0
> > > > 
> > > Sure, I realise I can do that, but it's not the point and it's awkward to do so with the "live CD-type" distro I use (tinycorelinux).
> > >
> > > Laptop sound should work in standalone mode by default - i.e. if laptop uses analogue sound
> > > for its built-in speakers then the alsa default should be analogue sound.
> > > 
> > > The above notwithstanding, analogue sound should work without needing to load the i915 kernel driver.
> > > 
> > For a smart automation, use PulseAudio.  It's exactly for such a purpose.
> > 
> > The kernel driver assigns each device just in the order how they are enumerated.
> > In the case of HD-audio, it's the order of PCI devices.
> > It's nothing different from any other PCI drivers.
> >
> OK, but I should not have to add bloat like pulseaudio in order to have basic sound functionality.

For getting the basic sound functionality, you have to set up
something.  You're asking the high-level automation, hence you need
something like PA.

Of course, you're free to reimplement a wheel if you don't like PA.
A similar thing can be achieved just by delaying the sound driver
module loading at udev level, or dynamically evaluating the priority
per PCI ID, at udev and assigning the index appropriately there.
(Just an idea, though.)

> You also don't mention why I should have to load a graphics driver (i915) in order to get analogue sound? That makes no sense at all...

The lack of i915 influences on the index assignment since the HDMI
codec driver probe fails without i915.  It's the reason why the
secondary HD-audio codec appears as the first, eventually it's the
analog audio output in your case.


Takashi

Re: Intel alsa sound request for Laptops

[John Frankish]

> > > > > > For two or three kernel versions of alsa divers now, HDMI has 
> > > > > > been the default alsa device on my laptop (Dell Latitude E7240) - this does not make logical sense.
> > > > > >
> > > > > > In the latest kernel version I use, 4.2.9, alsa sound will not 
> > > > > > work at all unless I load the i915 kernel driver
> > > > > > - this does not make logical sense and means that I cannot use Xvesa.
> > > > > > 
> > > > > > Is it possible to make an alsa feature request for analogue 
> > > > > > sound to be the default alsa device on laptops and for alsa sound to work without the need to load the i915 kernel driver?
> > > > > >
> > > > > It's a configuration issue.  Pass the module option if you prefer the secondary device:
> > > > > 
> > > > > options snd-hda-intel index=1,0
> > > > > 
> > > > Sure, I realise I can do that, but it's not the point and it's awkward to do so with the "live CD-type" distro I use (tinycorelinux).
> > > >
> > > > Laptop sound should work in standalone mode by default - i.e. if 
> > > > laptop uses analogue sound for its built-in speakers then the alsa default should be analogue sound.
> > > > 
> > > > The above notwithstanding, analogue sound should work without needing to load the i915 kernel driver.
> > > > 
> > > For a smart automation, use PulseAudio.  It's exactly for such a purpose.
> > > 
> > > The kernel driver assigns each device just in the order how they are enumerated.
> > > In the case of HD-audio, it's the order of PCI devices.
> > > It's nothing different from any other PCI drivers.
> > >
> > OK, but I should not have to add bloat like pulseaudio in order to have basic sound functionality.
> > 
> For getting the basic sound functionality, you have to set up something.
> You're asking the high-level automation, hence you need something like PA.
>
I'm not asking for high level automation, I'm asking that when I boot my laptop with alsa the built-in speakers work by default

> Of course, you're free to reimplement a wheel if you don't like PA.
> A similar thing can be achieved just by delaying the sound driver module
> loading at udev level, or dynamically evaluating the priority per PCI ID, at udev and assigning the
> index appropriately there. (Just an idea, though.)
>
> > You also don't mention why I should have to load a graphics driver (i915) in order to get analogue sound? That makes no sense at all...
> >
> The lack of i915 influences on the index assignment since the HDMI codec driver probe fails without i915.
> It's the reason why the secondary HD-audio codec appears as the first, eventually it's the analog audio output in your case.
>
I do not use the i915 driver at all - as far as I know, it still has the "pipe state doesn't match" bug - Xvesa doesn't require it and I use the modesetting driver with Xorg (since after more than a year we're still waiting for a stable xf86-video-intel).

You appear to be saying that, even if I work from the console prompt, I need to load the unneeded (and buggy) i915 driver in order to have analogue sound.

All credit to Intel for providing Linux drivers, but this i915/alsa/hdmi saga seems really flaky :(

Re: Intel alsa sound request for Laptops

[Takashi Iwai]

On Sun, 29 Jan 2017 09:15:27 +0100,
John Frankish wrote:
> 
> > > > > > > For two or three kernel versions of alsa divers now, HDMI has 
> > > > > > > been the default alsa device on my laptop (Dell Latitude E7240) - this does not make logical sense.
> > > > > > >
> > > > > > > In the latest kernel version I use, 4.2.9, alsa sound will not 
> > > > > > > work at all unless I load the i915 kernel driver
> > > > > > > - this does not make logical sense and means that I cannot use Xvesa.
> > > > > > > 
> > > > > > > Is it possible to make an alsa feature request for analogue 
> > > > > > > sound to be the default alsa device on laptops and for alsa sound to work without the need to load the i915 kernel driver?
> > > > > > >
> > > > > > It's a configuration issue.  Pass the module option if you prefer the secondary device:
> > > > > > 
> > > > > > options snd-hda-intel index=1,0
> > > > > > 
> > > > > Sure, I realise I can do that, but it's not the point and it's awkward to do so with the "live CD-type" distro I use (tinycorelinux).
> > > > >
> > > > > Laptop sound should work in standalone mode by default - i.e. if 
> > > > > laptop uses analogue sound for its built-in speakers then the alsa default should be analogue sound.
> > > > > 
> > > > > The above notwithstanding, analogue sound should work without needing to load the i915 kernel driver.
> > > > > 
> > > > For a smart automation, use PulseAudio.  It's exactly for such a purpose.
> > > > 
> > > > The kernel driver assigns each device just in the order how they are enumerated.
> > > > In the case of HD-audio, it's the order of PCI devices.
> > > > It's nothing different from any other PCI drivers.
> > > >
> > > OK, but I should not have to add bloat like pulseaudio in order to have basic sound functionality.
> > > 
> > For getting the basic sound functionality, you have to set up something.
> > You're asking the high-level automation, hence you need something like PA.
> >
> I'm not asking for high level automation, I'm asking that when I boot my laptop with alsa the built-in speakers work by default

Your machine has multiple audio devices, thus you have to prioritize
the device to pick up.  It's already a high level decision that the
kernel doesn't care as default, thus it requires either a high-level
automation or some manual adjustment in user-space.

You're asking a simple thing, but it's not simple as you think.

> > Of course, you're free to reimplement a wheel if you don't like PA.
> > A similar thing can be achieved just by delaying the sound driver module
> > loading at udev level, or dynamically evaluating the priority per PCI ID, at udev and assigning the
> > index appropriately there. (Just an idea, though.)
> >
> > > You also don't mention why I should have to load a graphics driver (i915) in order to get analogue sound? That makes no sense at all...
> > >
> > The lack of i915 influences on the index assignment since the HDMI codec driver probe fails without i915.
> > It's the reason why the secondary HD-audio codec appears as the first, eventually it's the analog audio output in your case.
> >
> I do not use the i915 driver at all - as far as I know, it still has the "pipe state doesn't match" bug - Xvesa doesn't require it and I use the modesetting driver with Xorg (since after more than a year we're still waiting for a stable xf86-video-intel).

How do you run modesetting X driver without i915 driver?

> You appear to be saying that, even if I work from the console prompt, I need to load the unneeded (and buggy) i915 driver in order to have analogue sound.

No, you seem to be mixing up the cause and the result.

You really should check why the audio doesn't work when you don't use
i915.  As already mentioned, it influences the probe order, as HDMI
audio device probe fails without i915.  At least, it works as is, if
you're using the latest kernel.

If it still doesn't work, report it properly with certain logs.


Takashi

Re: Intel alsa sound request for Laptops

[John Frankish]

> > > > > > > > For two or three kernel versions of alsa divers now, HDMI 
> > > > > > > > has been the default alsa device on my laptop (Dell Latitude E7240) - this does not make logical sense.
> > > > > > > >
> > > > > > > > In the latest kernel version I use, 4.2.9, alsa sound will 
> > > > > > > > not work at all unless I load the i915 kernel driver
> > > > > > > > - this does not make logical sense and means that I cannot use Xvesa.
> > > > > > > > 
> > > > > > > > Is it possible to make an alsa feature request for 
> > > > > > > > analogue sound to be the default alsa device on laptops and for alsa sound to work without the need to load the i915 kernel driver?
> > > > > > > >
> > > > > > > It's a configuration issue.  Pass the module option if you prefer the secondary device:
> > > > > > > 
> > > > > > > options snd-hda-intel index=1,0
> > > > > > > 
> > > > > > Sure, I realise I can do that, but it's not the point and it's awkward to do so with the "live CD-type" distro I use (tinycorelinux).
> > > > > >
> > > > > > Laptop sound should work in standalone mode by default - i.e. 
> > > > > > if laptop uses analogue sound for its built-in speakers then the alsa default should be analogue sound.
> > > > > > 
> > > > > > The above notwithstanding, analogue sound should work without needing to load the i915 kernel driver.
> > > > > > 
> > > > > For a smart automation, use PulseAudio.  It's exactly for such a purpose.
> > > > > 
> > > > > The kernel driver assigns each device just in the order how they are enumerated.
> > > > > In the case of HD-audio, it's the order of PCI devices.
> > > > > It's nothing different from any other PCI drivers.
> > > > >
> > > > OK, but I should not have to add bloat like pulseaudio in order to have basic sound functionality.
> > > > 
> > > For getting the basic sound functionality, you have to set up something.
> > > You're asking the high-level automation, hence you need something like PA.
> > > 
> > I'm not asking for high level automation, I'm asking that when I boot 
> > my laptop with alsa the built-in speakers work by default
> 
> Your machine has multiple audio devices, thus you have to prioritize the device to pick up.
> It's already a high level decision that the kernel doesn't care as default, thus it requires either a high-level automation
> or some manual adjustment in user-space.
> 
> You're asking a simple thing, but it's not simple as you think.
> 
I don't say that it's simple, but I believe it is a reasonably expectation.

> > > > Of course, you're free to reimplement a wheel if you don't like PA.
> > > > A similar thing can be achieved just by delaying the sound driver 
> > > > module loading at udev level, or dynamically evaluating the priority 
> > > > per PCI ID, at udev and assigning the index appropriately there. 
> > > > (Just an idea, though.)
> > > >
> > > > You also don't mention why I should have to load a graphics driver (i915) in order to get analogue sound? That makes no sense at all...
> > > >
> > > The lack of i915 influences on the index assignment since the HDMI codec driver probe fails without i915.
> > > It's the reason why the secondary HD-audio codec appears as the first, eventually it's the analog audio output in your case.
> > >
> > I do not use the i915 driver at all - as far as I know, it still has the "pipe state doesn't match" bug - 
> > Xvesa doesn't require it and I use the modesetting driver with Xorg (since after more than a year
> > we're still waiting for a stable xf86-video-intel).
> > 
> How do you run modesetting X driver without i915 driver?
> 
> > You appear to be saying that, even if I work from the console prompt, I need to load the unneeded
> > (and buggy) i915 driver in order to have analogue sound.
> > 
> No, you seem to be mixing up the cause and the result.
> 
> You really should check why the audio doesn't work when you don't use i915.
> As already mentioned, it influences the probe order, as HDMI audio device probe fails without i915.
> At least, it works as is, if you're using the latest kernel.
> 
> If it still doesn't work, report it properly with certain logs.
> 
snd_hda_intel 0000:00:03.0: enabling device (0000 -> 0002)
snd_hda_intel 0000:00:03.0: failed to add i915 component master (-19)
snd_hda_codec_realtek hdaudioC1D0: autoconfig for ALC3226: line_outs=1 (0x16/0x0/0x0/0x0/0x0) type:line
snd_hda_codec_realtek hdaudioC1D0:    speaker_outs=1 (0x14/0x0/0x0/0x0/0x0)
snd_hda_codec_realtek hdaudioC1D0:    hp_outs=1 (0x15/0x0/0x0/0x0/0x0)
snd_hda_codec_realtek hdaudioC1D0:    mono: mono_out=0x0
snd_hda_codec_realtek hdaudioC1D0:    inputs:
snd_hda_codec_realtek hdaudioC1D0:      Dock Mic=0x19
snd_hda_codec_realtek hdaudioC1D0:      Headset Mic=0x1a
snd_hda_codec_realtek hdaudioC1D0:      Internal Mic=0x12
input: HDA Intel PCH Dock Mic as /devices/pci0000:00/0000:00:1b.0/sound/card1/input11
input: HDA Intel PCH Dock Line Out as /devices/pci0000:00/0000:00:1b.0/sound/card1/input12
input: HDA Intel PCH Front Headphone as /devices/pci0000:00/0000:00:1b.0/sound/card1/input13

$ 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

Re: Intel alsa sound request for Laptops

[Takashi Iwai]

On Sun, 29 Jan 2017 10:59:08 +0100,
John Frankish wrote:
> 
> > > > > > > > > For two or three kernel versions of alsa divers now, HDMI 
> > > > > > > > > has been the default alsa device on my laptop (Dell Latitude E7240) - this does not make logical sense.
> > > > > > > > >
> > > > > > > > > In the latest kernel version I use, 4.2.9, alsa sound will 
> > > > > > > > > not work at all unless I load the i915 kernel driver
> > > > > > > > > - this does not make logical sense and means that I cannot use Xvesa.
> > > > > > > > > 
> > > > > > > > > Is it possible to make an alsa feature request for 
> > > > > > > > > analogue sound to be the default alsa device on laptops and for alsa sound to work without the need to load the i915 kernel driver?
> > > > > > > > >
> > > > > > > > It's a configuration issue.  Pass the module option if you prefer the secondary device:
> > > > > > > > 
> > > > > > > > options snd-hda-intel index=1,0
> > > > > > > > 
> > > > > > > Sure, I realise I can do that, but it's not the point and it's awkward to do so with the "live CD-type" distro I use (tinycorelinux).
> > > > > > >
> > > > > > > Laptop sound should work in standalone mode by default - i.e. 
> > > > > > > if laptop uses analogue sound for its built-in speakers then the alsa default should be analogue sound.
> > > > > > > 
> > > > > > > The above notwithstanding, analogue sound should work without needing to load the i915 kernel driver.
> > > > > > > 
> > > > > > For a smart automation, use PulseAudio.  It's exactly for such a purpose.
> > > > > > 
> > > > > > The kernel driver assigns each device just in the order how they are enumerated.
> > > > > > In the case of HD-audio, it's the order of PCI devices.
> > > > > > It's nothing different from any other PCI drivers.
> > > > > >
> > > > > OK, but I should not have to add bloat like pulseaudio in order to have basic sound functionality.
> > > > > 
> > > > For getting the basic sound functionality, you have to set up something.
> > > > You're asking the high-level automation, hence you need something like PA.
> > > > 
> > > I'm not asking for high level automation, I'm asking that when I boot 
> > > my laptop with alsa the built-in speakers work by default
> > 
> > Your machine has multiple audio devices, thus you have to prioritize the device to pick up.
> > It's already a high level decision that the kernel doesn't care as default, thus it requires either a high-level automation
> > or some manual adjustment in user-space.
> > 
> > You're asking a simple thing, but it's not simple as you think.
> > 
> I don't say that it's simple, but I believe it is a reasonably expectation.

And this expectation is already a high-level; i.e. it's more than the
kernel level.  So a reasonably expected answer is: use PA if you do
want everything working without the manual adjustment.


> > > > > Of course, you're free to reimplement a wheel if you don't like PA.
> > > > > A similar thing can be achieved just by delaying the sound driver 
> > > > > module loading at udev level, or dynamically evaluating the priority 
> > > > > per PCI ID, at udev and assigning the index appropriately there. 
> > > > > (Just an idea, though.)
> > > > >
> > > > > You also don't mention why I should have to load a graphics driver (i915) in order to get analogue sound? That makes no sense at all...
> > > > >
> > > > The lack of i915 influences on the index assignment since the HDMI codec driver probe fails without i915.
> > > > It's the reason why the secondary HD-audio codec appears as the first, eventually it's the analog audio output in your case.
> > > >
> > > I do not use the i915 driver at all - as far as I know, it still has the "pipe state doesn't match" bug - 
> > > Xvesa doesn't require it and I use the modesetting driver with Xorg (since after more than a year
> > > we're still waiting for a stable xf86-video-intel).
> > > 
> > How do you run modesetting X driver without i915 driver?
> > 
> > > You appear to be saying that, even if I work from the console prompt, I need to load the unneeded
> > > (and buggy) i915 driver in order to have analogue sound.
> > > 
> > No, you seem to be mixing up the cause and the result.
> > 
> > You really should check why the audio doesn't work when you don't use i915.
> > As already mentioned, it influences the probe order, as HDMI audio device probe fails without i915.
> > At least, it works as is, if you're using the latest kernel.
> > 
> > If it still doesn't work, report it properly with certain logs.
> > 
> snd_hda_intel 0000:00:03.0: enabling device (0000 -> 0002)
> snd_hda_intel 0000:00:03.0: failed to add i915 component master (-19)
> snd_hda_codec_realtek hdaudioC1D0: autoconfig for ALC3226: line_outs=1 (0x16/0x0/0x0/0x0/0x0) type:line
> snd_hda_codec_realtek hdaudioC1D0:    speaker_outs=1 (0x14/0x0/0x0/0x0/0x0)
> snd_hda_codec_realtek hdaudioC1D0:    hp_outs=1 (0x15/0x0/0x0/0x0/0x0)
> snd_hda_codec_realtek hdaudioC1D0:    mono: mono_out=0x0
> snd_hda_codec_realtek hdaudioC1D0:    inputs:
> snd_hda_codec_realtek hdaudioC1D0:      Dock Mic=0x19
> snd_hda_codec_realtek hdaudioC1D0:      Headset Mic=0x1a
> snd_hda_codec_realtek hdaudioC1D0:      Internal Mic=0x12
> input: HDA Intel PCH Dock Mic as /devices/pci0000:00/0000:00:1b.0/sound/card1/input11
> input: HDA Intel PCH Dock Line Out as /devices/pci0000:00/0000:00:1b.0/sound/card1/input12
> input: HDA Intel PCH Front Headphone as /devices/pci0000:00/0000:00:1b.0/sound/card1/input13
> 
> $ 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

I guess you still leave index=1,0 option even if you boot without
i915, right?  Then it breaks.  The option means that it swaps the
primary and the secondary cards.  As already mentioned, without i915,
the primary device, HDMI output is disabled, thus there will be only
device.  Still by specifying index=1,0, you set the non-existing
secondary card as card#0, thus you get such an error, as the apps
expect card#0 to be the default.  See the output above showing "card
1", not "card 0".

That said, if you boot without i915, drop the index option.

BTW, instead of index option, you can define the default PCM and the
control via ~/.asoundrc.  There you can pass the id name string
instead of the card number, so that it's persistent no matter which
card number is assigned depending on the boot condition.


Takashi

Re: Intel alsa sound request for Laptops

[John Frankish]

> > > > > > > > > > For two or three kernel versions of alsa divers now, 
> > > > > > > > > > HDMI has been the default alsa device on my laptop (Dell Latitude E7240) - this does not make logical sense.
> > > > > > > > > >
> > > > > > > > > > In the latest kernel version I use, 4.2.9, alsa sound 
> > > > > > > > > > will not work at all unless I load the i915 kernel 
> > > > > > > > > > driver
> > > > > > > > > > - this does not make logical sense and means that I cannot use Xvesa.
> > > > > > > > > > 
> > > > > > > > > > Is it possible to make an alsa feature request for 
> > > > > > > > > > analogue sound to be the default alsa device on laptops and for alsa sound to work without the need
> > > > > > > > > > to load the i915 kernel driver?
> > > > > > > > > >
> > > > > > > > > It's a configuration issue.  Pass the module option if you prefer the secondary device:
> > > > > > > > > 
> > > > > > > > > options snd-hda-intel index=1,0
> > > > > > > > > 
> > > > > > > > Sure, I realise I can do that, but it's not the point and it's awkward to do so with the "live CD-type" distro I use (tinycorelinux).
> > > > > > > >
> > > > > > > > Laptop sound should work in standalone mode by default - i.e. 
> > > > > > > > if laptop uses analogue sound for its built-in speakers then the alsa default should be analogue sound.
> > > > > > > > 
> > > > > > > > The above notwithstanding, analogue sound should work without needing to load the i915 kernel driver.
> > > > > > > > 
> > > > > > > For a smart automation, use PulseAudio.  It's exactly for such a purpose.
> > > > > > > 
> > > > > > > The kernel driver assigns each device just in the order how they are enumerated.
> > > > > > > In the case of HD-audio, it's the order of PCI devices.
> > > > > > > It's nothing different from any other PCI drivers.
> > > > > > >
> > > > > > OK, but I should not have to add bloat like pulseaudio in order to have basic sound functionality.
> > > > > > 
> > > > > For getting the basic sound functionality, you have to set up something.
> > > > > You're asking the high-level automation, hence you need something like PA.
> > > > > 
> > > > I'm not asking for high level automation, I'm asking that when I 
> > > > boot my laptop with alsa the built-in speakers work by default
> > > 
> > > Your machine has multiple audio devices, thus you have to prioritize the device to pick up.
> > > It's already a high level decision that the kernel doesn't care as 
> > > default, thus it requires either a high-level automation or some manual adjustment in user-space.
> > > 
> > > You're asking a simple thing, but it's not simple as you think.
> > > 
> > I don't say that it's simple, but I believe it is a reasonably expectation.
> > 
> And this expectation is already a high-level; i.e. it's more than the kernel level.
> So a reasonably expected answer is: use PA if you do want everything working without the manual adjustment.
> 
> > > > > > Of course, you're free to reimplement a wheel if you don't like PA.
> > > > > > A similar thing can be achieved just by delaying the sound 
> > > > > > driver module loading at udev level, or dynamically evaluating 
> > > > > > the priority per PCI ID, at udev and assigning the index appropriately there.
> > > > > > (Just an idea, though.)
> > > > > >
> > > > > > You also don't mention why I should have to load a graphics driver (i915) in order to get analogue sound? That makes no sense at all...
> > > > > >
> > > > > The lack of i915 influences on the index assignment since the HDMI codec driver probe fails without i915.
> > > > > It's the reason why the secondary HD-audio codec appears as the first, eventually it's the analog audio output in your case.
> > > > >
> > > > I do not use the i915 driver at all - as far as I know, it still 
> > > > has the "pipe state doesn't match" bug - Xvesa doesn't require it 
> > > > and I use the modesetting driver with Xorg (since after more than a year we're still waiting for a stable xf86-video-intel).
> > > > 
> > > How do you run modesetting X driver without i915 driver?
> > > 
> > > > You appear to be saying that, even if I work from the console 
> > > > prompt, I need to load the unneeded (and buggy) i915 driver in order to have analogue sound.
> > > > 
> > > No, you seem to be mixing up the cause and the result.
> > > 
> > > You really should check why the audio doesn't work when you don't use i915.
> > > As already mentioned, it influences the probe order, as HDMI audio device probe fails without i915.
> > > At least, it works as is, if you're using the latest kernel.
> > > 
> > > If it still doesn't work, report it properly with certain logs.
> > > 
> > snd_hda_intel 0000:00:03.0: enabling device (0000 -> 0002) 
> > snd_hda_intel 0000:00:03.0: failed to add i915 component master (-19) 
> > snd_hda_codec_realtek hdaudioC1D0: autoconfig for ALC3226: line_outs=1 (0x16/0x0/0x0/0x0/0x0) type:line
> > snd_hda_codec_realtek hdaudioC1D0:    speaker_outs=1 (0x14/0x0/0x0/0x0/0x0)
> > snd_hda_codec_realtek hdaudioC1D0:    hp_outs=1 (0x15/0x0/0x0/0x0/0x0)
> > snd_hda_codec_realtek hdaudioC1D0:    mono: mono_out=0x0
> > snd_hda_codec_realtek hdaudioC1D0:    inputs:
> > snd_hda_codec_realtek hdaudioC1D0:      Dock Mic=0x19
> > snd_hda_codec_realtek hdaudioC1D0:      Headset Mic=0x1a
> > snd_hda_codec_realtek hdaudioC1D0:      Internal Mic=0x12
> > input: HDA Intel PCH Dock Mic as 
> > /devices/pci0000:00/0000:00:1b.0/sound/card1/input11
> > input: HDA Intel PCH Dock Line Out as 
> > /devices/pci0000:00/0000:00:1b.0/sound/card1/input12
> > input: HDA Intel PCH Front Headphone as 
> > /devices/pci0000:00/0000:00:1b.0/sound/card1/input13
> > 
> > $ 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
> >  
> I guess you still leave index=1,0 option even if you boot without i915, right?  Then it breaks.
> The option means that it swaps the primary and the secondary cards.  As already mentioned, without i915,
> the primary device, HDMI output is disabled, thus there will be only device.  Still by specifying index=1,0,
> you set the non-existing secondary card as card#0, thus you get such an error, as the apps expect card#0
> to be the default.  See the output above showing "card 1", not "card 0".
> 
> 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)

> BTW, instead of index option, you can define the default PCM and the control via ~/.asoundrc.
> There you can pass the id name string instead of the card number, so that it's persistent no matter
> which card number is assigned depending on the boot condition.
>
Thanks, but I think I'll leave things here:

My opinion is that the laptop speakers should work by default and that I should not have to load unwanted (and buggy) graphics drivers in order to get sound to work.

Your opinion is otherwise.

The beauty of Linux is that we can agree to disagree :)

Re: Intel alsa sound request for Laptops

[Lars-Peter Clausen]

On 01/29/2017 09:15 AM, John Frankish wrote:
>>>>>>> For two or three kernel versions of alsa divers now, HDMI has 
>>>>>>> been the default alsa device on my laptop (Dell Latitude E7240) - this does not make logical sense.
>>>>>>>
>>>>>>> In the latest kernel version I use, 4.2.9, alsa sound will not 
>>>>>>> work at all unless I load the i915 kernel driver
>>>>>>> - this does not make logical sense and means that I cannot use Xvesa.
>>>>>>>
>>>>>>> Is it possible to make an alsa feature request for analogue 
>>>>>>> sound to be the default alsa device on laptops and for alsa sound to work without the need to load the i915 kernel driver?
>>>>>>>
>>>>>> It's a configuration issue.  Pass the module option if you prefer the secondary device:
>>>>>>
>>>>>> options snd-hda-intel index=1,0
>>>>>>
>>>>> Sure, I realise I can do that, but it's not the point and it's awkward to do so with the "live CD-type" distro I use (tinycorelinux).
>>>>>
>>>>> Laptop sound should work in standalone mode by default - i.e. if 
>>>>> laptop uses analogue sound for its built-in speakers then the alsa default should be analogue sound.
>>>>>
>>>>> The above notwithstanding, analogue sound should work without needing to load the i915 kernel driver.
>>>>>
>>>> For a smart automation, use PulseAudio.  It's exactly for such a purpose.
>>>>
>>>> The kernel driver assigns each device just in the order how they are enumerated.
>>>> In the case of HD-audio, it's the order of PCI devices.
>>>> It's nothing different from any other PCI drivers.
>>>>
>>> OK, but I should not have to add bloat like pulseaudio in order to have basic sound functionality.
>>>
>> For getting the basic sound functionality, you have to set up something.
>> You're asking the high-level automation, hence you need something like PA.
>>
> I'm not asking for high level automation, I'm asking that when I boot my laptop with alsa the built-in speakers work by default

That's OK and a reasonable request. But the thing is other people want to
use other default configurations, e.g. use the speakers in their HDMI
monitor by default. This is why at the kernel level ALSA does not get
involved with policy decisions and leaves this to userspace audio policy
managers such as PulseAudio.

If you don't want to use such a policy manager that's also OK, but then you
have to take care of policy management yourself by e.g. writing a ALSA
configuration file or manually specifying your preferred audio playback
device when starting a audio playback application.

Re: Intel alsa sound request for Laptops

[Takashi Iwai]

On Sun, 29 Jan 2017 14:06:43 +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.


Takashi

Re: 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

Is there any chance of that being fixed in the future?

Re: Intel alsa sound request for Laptops

[John Rigg]

On Sun, Jan 29, 2017 at 02:23:24PM +0000, John Frankish wrote:
> Great - so the expected behaviour is for it to fail :P
> 
> Is there any chance of that being fixed in the future?

Have you asked the maintainers of your Linux distribution this
question?

John

Re: Intel alsa sound request for Laptops

[Takashi Iwai]

On Sun, 29 Jan 2017 15:23:24 +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.

> Is there any chance of that being fixed in the future?

As already mentioned, the "fix" is to use PA.

As Lars pointed in this thread, the expectation using the analog
output over multiple individual devices is a policy decision, and it's
over the level the kernel manages.

In most cases, it works as is, simply because there is mostly only one
device.  But on Haswell and Broadwell platforms, the machine provides
two individual devices, and worse, in an unlucky order.

If you don't like to use PA, you'll have to adjust manually.  That is,
your distro would need some way to detect and set the index=1,0 option
depending no the system.  It can be implemented in a udev rule or in a
module config (via install script), too.  So it's the matter how
distro handles such a thing.


Takashi

Re: 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.

> > 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

Re: Intel alsa sound request for Laptops

[Takashi Iwai]

On Tue, 31 Jan 2017 07:40:06 +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.

> > > 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.


thanks,

Takashi

Re: 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.
(I'm using 4.2.9)

> > > > 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

Re: Intel alsa sound request for Laptops

[Takashi Iwai]

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

Re: 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.

Re: Intel alsa sound request for Laptops

[Takashi Iwai]

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

Re: Intel alsa sound request for Laptops

[Lars-Peter Clausen]

On 01/31/2017 10:13 AM, Takashi Iwai wrote:
[...]
>>>> $ alsamixer
>>>> cannot open mixer: No such file or directory
[...]
>> 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.

Given that alsamixer is capable of handling multiple cards and able to
switch between them at runtime we should still look into this. The
application should not refuse to launch if the default card is not available.

- Lars

Re: Intel alsa sound request for Laptops

[Takashi Iwai]

On Tue, 31 Jan 2017 11:37:22 +0100,
Lars-Peter Clausen wrote:
> 
> On 01/31/2017 10:13 AM, Takashi Iwai wrote:
> [...]
> >>>> $ alsamixer
> >>>> cannot open mixer: No such file or directory
> [...]
> >> 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.
> 
> Given that alsamixer is capable of handling multiple cards and able to
> switch between them at runtime we should still look into this. The
> application should not refuse to launch if the default card is not available.

Well, currently the "default" just points to the default card, that is
card#0.  It's the current definition.

We may change it, but it means the inconsistent behavior against the
older version, thus we must do it VERY carefully.  (e.g. an
application opening the device twice may get a different result
depending on the status when it's applied to a hotplug device.)


Takashi