Re: [RFC PATCH 1/2] ALSA: hda - Fix "PCM" name being used on one DAC when there are two DACs

[David Henningsson <david.henningsson@canonical.com>]

On 2014-10-19 01:02, Raymond Yau wrote:
>
>  > >
>  > > >> >
>  > > >> > In the scenario where there is one "Line Out", one "Speaker"
> and one
>  > > >> > "Headphone", and there are only two DACs, two outputs will
> share a DAC.
>  > > >> > Currently any mixer on such a DAC will get the "PCM" name,
> which is
>  > > >> > misleading. Instead use "Headphone+LO" or "Speaker+LO" to better
>  > > >> > specify what the volume actually controls.
>  > > >>
>  > > >> Are there any examples ?
>  > > >>
>  > > >
>  > > > I used "hda-emu
>  > > codecs/canonical/alc3226-dell-precision-m2800-ccert-201404-14986 -i
> 1" when
>  > > developing the patches.
>  > > >
>  > > > I don't have any hardware available myself that exposes this
> behavior,
>  > > but I can maybe fake one with hdajackretask, if that counts...
>  > > >
>  > >
>  > > How about adding these names to slaves of virtual master
> volume/switch ?
>  > >
>  > > hdajackretask won't help if the topology of the codecs are  different
>  > >
>  > > Seem the badness still prevent the driver to support surround 5.1 with
>  > > three rear panel jacks, internal speaker and front panel headphone for
>  > > Thinkcenter A58 using alc662
>  > >
>  > >
> https://www.mail-archive.com/alsa-user@lists.sourceforge.net/msg29203.html
>  > >
>  > > Why 3stack desktops with 6 channels codecs not using
> "Headphone+LO"  or
>  > > "Speaker+LO" ?
>  >
>  > The problem is just the lack of DACs, so it cannot cover all three
>  > outputs, no matter how the pins are chosen.  That is, it's no 6
>  > channels at all but 4 channels at most.
>  >
>  >
>
> http://shop.lenovo.com/us/en/desktops/thinkcentre/a-series/a58/
>
> The technical specification of a58
>
> 2 pin internal speaker connector
> Alc662 5.1
>
> https://bbs.archlinux.org/viewtopic.php?id=156433
>
> Seem windows support surround 5.1

Raymond, there can certainly be cases which this patch does not cover - 
after all, it's mostly a band aid given the lack of topology information 
- but do you see cases where this patch actually causes a *regression*? 
If so, could you point me to alsa-info for the machine where this patch 
causes a regression?

-- 
David Henningsson, Canonical Ltd.
https://launchpad.net/~diwic