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

[Yang, Libin]

Hi Takashi,

> -----Original Message-----
> From: Takashi Iwai [mailto:tiwai at suse.de]
> Sent: Wednesday, October 14, 2015 12:20 AM
> To: Yang, Libin
> Cc: David Henningsson; Lin, Mengdong; tanuk at iki.fi; Girdwood, Liam
> R; alsa-devel at alsa-project.org; airlied at linux.ie
> Subject: Re: DP1.2 MST audio support discussion
> 
> On Tue, 13 Oct 2015 16:12:58 +0200,
> Yang, Libin wrote:
> >
> > Hi Takashi,
> >
> > > -----Original Message-----
> > > From: Takashi Iwai [mailto:tiwai at suse.de]
> > > Sent: Tuesday, October 13, 2015 10:04 PM
> > > To: Yang, Libin
> > > Cc: David Henningsson; Lin, Mengdong; tanuk at iki.fi; Girdwood,
> Liam
> > > R; alsa-devel at alsa-project.org; airlied at linux.ie
> > > Subject: Re: DP1.2 MST audio support discussion
> > >
> > > On Tue, 13 Oct 2015 14:31:39 +0200,
> > > Yang, Libin wrote:
> > > >
> > > > Hi Takashi,
> > > >
> > > > > -----Original Message-----
> > > > > From: Takashi Iwai [mailto:tiwai at suse.de]
> > > > > Sent: Tuesday, October 13, 2015 5:21 PM
> > > > > To: Yang, Libin
> > > > > Cc: David Henningsson; Lin, Mengdong; tanuk at iki.fi; Girdwood,
> > > Liam
> > > > > R; alsa-devel at alsa-project.org; airlied at linux.ie
> > > > > Subject: Re: DP1.2 MST audio support discussion
> > > > >
> > > > > On Tue, 13 Oct 2015 09:34:49 +0200,
> > > > > Yang, Libin wrote:
> > > > > >
> > > > > > > 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, there are a few things to implement properly:
> > > > >
> > > > > 1. The plug/unplug events are triggered at the actual graphics
> > > output
> > > > >    switching via xrandr or such, not at the time the monitor is
> > > > >    physically plugged/unplugged.
> > > > >
> > > > > 2. At switching, the unplug event must be handled at first, and
> then
> > > > >    the plug event.
> > > > >
> > > > > 3. At unplug, detach per_pin object properly from PCM.
> > > > >    We currently just notify it via jack ctl, and doesn't care the
> > > > >    rest.  Ideally, we should force to stop the PCM and detach
> > > > >    internally from the assigned pin.
> > > >
> > > > For the switching, if we stop the PCM, when the plug event
> > > > happens, does this mean we should play the sound from
> > > > the beginning for continue playing the sound?
> > > >
> > > > It seems users will more likely hope continue playing the sound?
> > >
> > > The user is expected to restart the stream from the scratch instead.
> > > My assumption is to handle it like a disconnection of a hotplug
> > > device.
> > >
> > > > Some video players may use audio clock to do the Audio-Video
> > > > Sync (I'm not very sure). If we stop the PCM, after the hotplug,
> > > > the video player will be stopped and must play the video from
> > > > the beginning?
> > >
> > > Yes.  Remember that it's a DP, i.e. always with graphics.  If you
> > > switch the graphics, you'd need to do the full change in anyway.
> >
> > OK. I see. So besides we detach the PCM from the pin, how can
> > we stop the PCM clearly? Do we notify it to userspace and let
> > userspace stop the PCM?
> 
> A similar procedure like the hot unplug is needed.  Maybe an easy way
> would be to issue snd_pcm_stop() but with
> SND_PCM_STATE_DISCONNECTED.
> As the userspace notification, the jack event should suffice.

Get it. Thanks.

> 
> An open question is about the behavior at opening an unassigned pin.
> So far, we don't care and allows to operate a PCM entry even if no
> monitor is connected.  Is this still required for probing by PA?
> Or should we better return an error if no monitor is connected (if the
> information is reliable)?
> 
> 
> Takashi