Hi Takashi,
-----Original Message----- From: Takashi Iwai [mailto:tiwai@suse.de] Sent: Wednesday, October 14, 2015 12:20 AM To: Yang, Libin Cc: David Henningsson; Lin, Mengdong; tanuk@iki.fi; Girdwood, Liam R; alsa-devel@alsa-project.org; airlied@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@suse.de] Sent: Tuesday, October 13, 2015 10:04 PM To: Yang, Libin Cc: David Henningsson; Lin, Mengdong; tanuk@iki.fi; Girdwood,
Liam
R; alsa-devel@alsa-project.org; airlied@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@suse.de] Sent: Tuesday, October 13, 2015 5:21 PM To: Yang, Libin Cc: David Henningsson; Lin, Mengdong; tanuk@iki.fi; Girdwood,
Liam
R; alsa-devel@alsa-project.org; airlied@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
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:
- 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.
- At switching, the unplug event must be handled at first, and
then
the plug event.
- 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