[alsa-devel] DP1.2 MST audio support discussion

[Yang, Libin]

> -----Original Message-----
> From: David Henningsson [mailto:david.henningsson at canonical.com]
> Sent: Thursday, October 22, 2015 4:53 PM
> To: Yang, Libin; Raymond Yau; Takashi Iwai
> Cc: airlied at linux.ie; tanuk at iki.fi; ALSA Development Mailing List;
> Girdwood, Liam R; Lin, Mengdong
> Subject: Re: [alsa-devel] DP1.2 MST audio support discussion
> 
> 
> 
> On 2015-10-22 09:40, Yang, Libin wrote:
> >
> >>>>>> From: Raymond Yau [mailto:superquad.vortex2 at gmail.com]
> >>>>>> Sent: Friday, October 16, 2015 8:33 AM
> >>>>>> To: Takashi Iwai
> >>>>>> Cc: airlied at linux.ie; tanuk at iki.fi; David Henningsson; Yang,
> Libin;
> >>>> Lin,
> >>>>>> Mengdong; Girdwood, Liam R; ALSA Development Mailing List
> >>>>>> Subject: Re: [alsa-devel] DP1.2 MST audio support discussion
> >>>>>>
> >>>>>>
> >>>>>>>>
> >>>>>>>> Do it mean that only one DP MST port and no HDMI port on
> >> the
> >>>>>> same graphic
> >>>>>>>> card ?
> >>>>>>>
> >>>>>>> No.
> >>>>>> If there is only one HDMI and one Display Port, this mean that
> >> there
> >>>>>> are two pin complexes
> >>>>>> How about the name of jack detection kctl of three Display
> Port
> >>>>>> monitors  which are created on the same pin complex but
> >> different
> >>>>>> dev_index ?
> >>>>>
> >>>>> For the jack name, what do you think if we change to
> >>>>> "HDMI/DP, pin=n, dev=m" format? Will it impact on pulseaudio?
> >>>>
> >>>> Yes, it will impact PulseAudio. It will require changes to files in
> >>>>
> >>>>
> >>
> http://cgit.freedesktop.org/pulseaudio/pulseaudio/tree/src/modules/
> >>>> alsa/mixer/paths
> >>>
> >>> So does this mean we should not change the name
> "HDMI/DP,pcm=3
> >> Jack"
> >>> to "HDMI/DP,pin=n, dev=m Jack", otherwise the old PA will not
> work
> >> with
> >>> the new driver?
> >>
> >> Yes. And I don't understand why you need to do it, either - if you
> have
> >> three display port monitors on one pin, then they will all get
> different
> >> PCMs (8, 9 and 10), and they will signal their Jack status through
> >> "HDMI/DP,pcm=8 Jack", "HDMI/DP,pcm=9 Jack" and
> >> "HDMI/DP,pcm=10 Jack".
> >
> > OK, I see. Thanks. I will not change the jack kctl name.
> > BTW, the PCM number will be the same as converter, which means
> > it will be 3 on Intel platforms.
> 
> I'll try to explain my suggestion (which I believe Takashi's buying too)
> one more time then:
> 
> First, when a monitor is plugged in, we need to dynamically assign this
> monitor to five PCM devices. I believe this scheme will be best:
> 
> For a monitor at pin nid 0x05, dev index 0, it will prefer PCM 3.
> For a monitor at pin nid 0x06, dev index 0, it will prefer PCM 7.
> For a monitor at pin nid 0x07, dev index 0, it will prefer PCM 8.
> For a monitor at dev index 1 (any pin), it will prefer PCM 9.
> For a monitor at dev index 2 (any pin), it will prefer PCM 10.
> 
> For monitors at dev indices > 2 (can that happen?), or if the PCM is
> already assigned to something else, try PCMs in this order: 9, 10, 3, 7,
> 8.
> (Subject to discussion perhaps, I don't think the order matters too
> much, because conflicts will be rare in practice.)

Oh, it seems my understand is wrong. OK, so the pcm number will be:
Pin number + max (device entry number per pin) - 1. For example,
on intel platform, it is 5.

> 
> The jack and ELD kctls - one per PCM device - will follow what monitor
> the PCM is currently assigned to. (kctls belonging to a PCM device that
> is unassigned will report presence_detect=0 and eld_valid=0.)

It makes sense. This should be mostly friendly to userspace. I will do it.

> 
> Then, at playback open time, a free converter node will be dynamically
> assigned to the PCM. If there are no free converter nodes, return -
> EBUSY.

Yes, this is what I think.

> 
> Now remains the case when an unassigned PCM is opened. This needs
> additional thinking, but the more backwards compatibility we can keep
> for this case, the better. But I'm not sure about how possible it is to
> let streams "freewheel" in this new DSP MST world?

Do you mean playing on unassigned PCM should work as the monitor is
connected? I remember Takashi mentioned disconnecting monitor when
playback should trigger stop PCM. This case should follow the same policy
and return -ENODEV or -EINVAL?

> 
> >> Given that my proposed mapping algorithm will never change pin to
> >> PCM
> >> mapping (unless you have two displayport outputs and use MST on
> >> both), I
> >> think we can get away with not exposing the actual pin to
> userspace.
> >> And should this later become necessary, we can add a separate kctl
> for
> >> that.
> >
> > My current thought is to expose the same jack kctls (same number
> and
> > same name) to userspace while we will create hda_jack_tbl for each
> device
> > entry. When pcm is bound to the device entry, the corresponding
> > jack kctl will be bound to the device entry.
> 
> --
> David Henningsson, Canonical Ltd.
> https://launchpad.net/~diwic