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

[Yang, Libin]

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?

Regards,
Libin

> 
> 
> Takashi