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

[Yang, Libin]

Hi David

> -----Original Message-----
> From: David Henningsson [mailto:david.henningsson at canonical.com]
> Sent: Tuesday, October 13, 2015 2:48 PM
> To: Yang, Libin; 'Takashi Iwai'; Lin, Mengdong; tanuk at iki.fi; Girdwood,
> Liam R
> Cc: alsa-devel at alsa-project.org; airlied at linux.ie
> Subject: Re: DP1.2 MST audio support discussion
> 
> Hi Libin,
> 
> On 2015-10-13 08:25, Yang, Libin wrote:
> > Hi Takashi and all,
> >
> > We are planning to enable DP1.2 MST (Multi-Stream Transport)
> > audio.
> 
> This was also discussed during the audio mini-summit in Dublin last
> week.

Yes, Mengdong has talked with me. And I will implement the DP1.2
MST audio based on the audio mini-summit discussion.

> 
> >
> > Based on the previous discussion, we will extend the
> > struct hdmi_spec_per_pin to support MST audio device entry.
> > So the struct hdmi_spec_per_pin can be a real pin or a device
> > entry in the pin.  The idea is to add a member dev_idx in the
> > struct hdmi_spec_per_pin. Dev_idx, together with pin_nid,
> > can represent a device entry.
> >
> > 1. Dynamic PCM assignment
> > We will use dynamic PCM assignment for MST audio. This
> > means we will create a fixed number of PCMs (the number
> > is the same convertor number). All the created PCMs will not
> > be assigned to any pin (device entry). When there is a monitor
> > connected, an available PCM will be assigned to the pin. And
> > it will be de-assigned when the monitor is disconnected.
> > Userspace can fetch the HW param when monitor connection
> > status is changed.
> 
> For the dynamic PCM assignment, the suggestion is to try to use static
> as much as possible. That is, first try the existing static mapping
> (port B -> 3, port C -> 7, port D -> 8), and only if that PCM is already
> being used, try another PCM.

Do you mean the each pin has its prefer PCM? It should be OK.

> 
> One could then allocate two extra PCMs from the start (9 and 10) to
> try
> in case the other PCM is busy (my preference), or one could steal one
> of
> the existing non-busy ones (Takashi's preference).

We will create the PCMs based on converter. This means we will
create 3 PCMs. And it will not support dynamically allocating PCM.
As there are only 3 converters, no more PCMs will be supported.
Each PCM will use one converter. If 3 PCMs are all used, connecting
monitor will not create new PCM.

Yes, if we are not using the PCM, we can re-assign the PCM to another
monitor. Currently, user can't decide which PCM is used for which
monitor. Image the scenario PCM 3 is assigned to monitor 1, PCM 7 is 
assigned to monitor 2, PCM 8 is assigned to monitor 3. Monitor 4 is
connected, no PCM is available, and driver don't know whether it
should steal one PCM for the monitor 4 and user can't change the
mapping currently.

Actually, before sending the email, I was thinking to export
an interface to userspace to let user select which PCM will be bound
to the monitor. But it is a little complex.

> 
> > I'm not sure how to notify the userspace, such as notifying
> > pulseaudio the PCM is assigned or de-assigned. Any ideas?
> 
> Userspace will receive change events on Jack and ELD kctls which can
> be
> used for this. However, there's not yet code in PulseAudio that will
> re-probe a PCM when a Jack event is received.

Do you mean to use the existed notifiers for PCM and no
new notifier is needed?

> 
> > 2. Compatibility.
> > We will patch patch_hdmi.c to support the MST audio.
> > Will we use mst audio driver to support the old mode
> > or we use a flag, when HW doesn't support MST audio,
> > we will use the old code? Suppose MST audio driver should
> > be able support both MST audio and non-MST audio.
> 
> Apparently, the suggestion seems to be three hdmi codec drivers for
> the
> same hardware? One with MST audio, one without MST audio, and
> one ported
> to the ASoC framework :-/

Not sure, I think we can use one hdmi codec driver for HD Audio, another
one for ASoC. It's based on the conclusion of the discussion.

Regards,
Libin

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