[alsa-devel] [bug] Missing "front" definition for byt-max98090

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, 08 Sep 2017 13:30:48 +0200,
Tanu Kaskinen wrote:
> 
> On Thu, 2017-09-07 at 19:13 +0200, Takashi Iwai wrote:
> > On Thu, 07 Sep 2017 18:33:17 +0200,
> > Tanu Kaskinen wrote:
> > > 
> > > On Thu, 2017-09-07 at 15:54 +0200, Takashi Iwai wrote:
> > > > On Thu, 07 Sep 2017 14:25:44 +0200,
> > > > Tanu Kaskinen wrote:
> > > > > 
> > > > > PulseAudio 11 stopped using "hw:" as a fallback for analog stereo if
> > > > > "front:" doesn't work. This caused a regression on "Toshiba Chromebook
> > > > > 2 (Swanky)", because PulseAudio doesn't any more do automatic mixer
> > > > > adjustments when plugging in headphones. Apparently on this machine
> > > > > "hw:1,0" works fine as a substitute for "front:1,0", but we're not
> > > > > going to revert the change in PulseAudio, so could someone add the
> > > > > "front" definition for this machine in alsa-lib? Unfortunately I'm not
> > > > > proficient enough in the alsa-lib configuration system to make a patch
> > > > > myself.
> > > > 
> > > > Well, this is about the device that has no alsa-lib config.  So far,
> > > > we assumed that 'front' is available only when defined for the card.
> > > > But now PA mandates it...  Hmm.  I guess it's no big problem to add a
> > > > fallback to hw for the front PCM.
> > > > 
> > > > The patch below should work for such a device.  It's a patch to
> > > > alsa-lib source, but basically you can modify similarly the file
> > > > /usr/share/alsa/pcm/front.conf directly, too.
> > > > 
> > > > If it's confirmed to work, I'll merge the patch.
> > > > 
> > > > Maybe we can release alsa-lib 1.1.5 along with 4.13 kernel, so a
> > > > quicker reply would be appreciated.
> > > 
> > > The reporter said[1] that your patch works fine.
> > > 
> > > I have a concern, though: what about those cases where hw:x,0 is not an
> > > analog stereo device? The reason why PulseAudio was changed is that
> > > with the Intel HDMI LPE driver PulseAudio thought that the card had an
> > > analog stereo device, when in reality it only had HDMI. Doesn't your
> > > patch reintroduce this problem?
> > 
> > Basically "front" doesn't mean the analog output, but rather it's
> > an output from the front channels in multi speaker setups (corresponds
> > to "rear", etc).  And, so far, we have no notion of analog output
> > although we have a notion for digital output ("hdmi" and "spdif").
> > That is, "front" doesn't guarantee at all it being an analog from its
> > definition.
> 
> It would be good to at least guarantee that if both "front" and "hdmi"
> are defined, "front" is not an HDMI device. Your patch breaks this
> guarantee, so let's not apply it.
>
> > So, for HDMI LPE, can we simply have a special profile for excluding
> > the analog output in PA side?
> 
> I suppose that's the best solution. Or actually, I think the default
> configuration can be modified so that it works properly with both the
> HDMI LPE driver and with machines that don't have any alsa-lib
> configuration. PulseAudio 11 already uses hw:x,0 as a stereo device if
> everything else fails, we just need to add the mixer handling bits to
> that fallback case.

Agreed, it sounds like a more sustainable solution.


thanks,

Takashi


[Index of Archives]     [Linux Audio Users]     [AMD Graphics]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux