[alsa-devel] DP1.2 MST audio support discussion
Hi Takashi and all,
We are planning to enable DP1.2 MST (Multi-Stream Transport) audio.
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.
I'm not sure how to notify the userspace, such as notifying pulseaudio the PCM is assigned or de-assigned. Any ideas?
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.
Regards, Libin
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.
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.
- 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.
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).
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.
- 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 :-/
Hi David
-----Original Message----- From: David Henningsson [mailto:david.henningsson@canonical.com] Sent: Tuesday, October 13, 2015 2:48 PM To: Yang, Libin; 'Takashi Iwai'; Lin, Mengdong; tanuk@iki.fi; Girdwood, Liam R Cc: alsa-devel@alsa-project.org; airlied@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.
- 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?
- 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
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.
4. At plug, assign the monitor to the free per_pin object.
So what we've discussed is about the last step; how to map the new monitor to per_pin object. This requires the other steps beforehand which assures a free per_pin is present at plug time.
Takashi
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 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:
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? 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?
Regards, Libin
- At plug, assign the monitor to the free per_pin object.
So what we've discussed is about the last step; how to map the new monitor to per_pin object. This requires the other steps beforehand which assures a free per_pin is present at plug time.
Takashi
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 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:
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.
Takashi
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?
Regards, Libin
Takashi
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.
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
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
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:
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.
At plug, assign the monitor to the free per_pin object.
So what we've discussed is about the last step; how to map the new monitor to per_pin object. This requires the other steps beforehand which assures a free per_pin is present at plug time.
Do it mean that only one DP MST port and no HDMI port on the same graphic card ?
If DP MST are dasiy chained, the unplug of the first monitor from Display Port will cause all DP monitor in the dasiy chain disconnect
+ intel gfx experts.
Hi Raymond,
From: Raymond Yau [mailto:superquad.vortex2@gmail.com] Sent: Wednesday, October 14, 2015 7:52 AM To: Takashi Iwai Cc: ALSA Development Mailing List; David Henningsson; tanuk@iki.fi; airlied@linux.ie; Yang, Libin; Girdwood, Liam R; Lin, Mengdong Subject: Re: [alsa-devel] DP1.2 MST audio support discussion
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:
- 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.
- At plug, assign the monitor to the free per_pin object.
So what we've discussed is about the last step; how to map the new monitor to per_pin object. This requires the other steps beforehand which assures a free per_pin is present at plug time.
Do it mean that only one DP MST port and no HDMI port on the same graphic card ?
[Libin] It support DP MST and HDMI both on the same graphic card. On intel platform, it is using DDI port, support both DP and HDMI.
If DP MST are dasiy chained, the unplug of the first monitor from Display Port will cause all DP monitor in the dasiy chain disconnect [Libin] In this mode, multiple interrupts should occur? If so we can handle the daisy chained mode easily. Anyway, as the monitors are on the same pin, we can always know whether there is monitor on the pin. Thanks for reminding it.
On Wed, 14 Oct 2015 01:52:08 +0200, Raymond Yau 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:
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.
At plug, assign the monitor to the free per_pin object.
So what we've discussed is about the last step; how to map the new monitor to per_pin object. This requires the other steps beforehand which assures a free per_pin is present at plug time.
Do it mean that only one DP MST port and no HDMI port on the same graphic card ?
No.
If DP MST are dasiy chained, the unplug of the first monitor from Display Port will cause all DP monitor in the dasiy chain disconnect
Yes.
Takashi
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 ?
Will three three display port monitor playback devices always play different stream even when the displays are in clone mode ?
If DP MST are dasiy chained, the unplug of the first monitor from
Display
Port will cause all DP monitor in the dasiy chain disconnect
Yes.
Do the power off of the Display Port in the middle of the dasiy chain also affect the last display port mointor in the dasiy chain ?
On Fri, 16 Oct 2015 02:32:50 +0200, Raymond Yau wrote:
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
Yes, and the mapping doesn't change in this case as before.
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 ?
It's one of the models we've considered. Basically the number of devices can be up to 64 (or such) per pin. For Intel case, due to the limitation of converters, it's up to 3. For other GPUs that may drive more simultaneous outputs, the number increases in square. If a GPU may handle 16 outputs, it'll be 256 entries.
Although the 256 entries are certainly manageable as kctl, whether this is the best representation for user-space is a question.
Will three three display port monitor playback devices always play different stream even when the displays are in clone mode ?
The clone mode is another messy part...
If DP MST are dasiy chained, the unplug of the first monitor from
Display
Port will cause all DP monitor in the dasiy chain disconnect
Yes.
Do the power off of the Display Port in the middle of the dasiy chain also affect the last display port mointor in the dasiy chain ?
Possibly. But it's not what we really care, as this is the thing the graphics side should handle.
Takashi
Hi Takashi,
-----Original Message----- From: Takashi Iwai [mailto:tiwai@suse.de] Sent: Friday, October 16, 2015 2:38 PM To: Raymond Yau Cc: Yang, Libin; ALSA Development Mailing List; airlied@linux.ie; Lin, Mengdong; Girdwood, Liam R; tanuk@iki.fi; David Henningsson Subject: Re: [alsa-devel] DP1.2 MST audio support discussion
On Fri, 16 Oct 2015 02:32:50 +0200, Raymond Yau wrote:
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
Yes, and the mapping doesn't change in this case as before.
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 ?
It's one of the models we've considered. Basically the number of devices can be up to 64 (or such) per pin. For Intel case, due to the limitation of converters, it's up to 3. For other GPUs that may drive more simultaneous outputs, the number increases in square. If a GPU may handle 16 outputs, it'll be 256 entries.
Although the 256 entries are certainly manageable as kctl, whether this is the best representation for user-space is a question.
This is what I concern. Each device entry should have one tag for unsol event. This means each device entry will create a jack?
Will three three display port monitor playback devices always play different stream even when the displays are in clone mode ?
The clone mode is another messy part...
If DP MST are dasiy chained, the unplug of the first monitor from
Display
Port will cause all DP monitor in the dasiy chain disconnect
Yes.
Do the power off of the Display Port in the middle of the dasiy chain
also
affect the last display port mointor in the dasiy chain ?
Possibly. But it's not what we really care, as this is the thing the graphics side should handle.
Takashi
On Fri, 16 Oct 2015 10:51:30 +0200, Yang, Libin wrote:
Hi Takashi,
-----Original Message----- From: Takashi Iwai [mailto:tiwai@suse.de] Sent: Friday, October 16, 2015 2:38 PM To: Raymond Yau Cc: Yang, Libin; ALSA Development Mailing List; airlied@linux.ie; Lin, Mengdong; Girdwood, Liam R; tanuk@iki.fi; David Henningsson Subject: Re: [alsa-devel] DP1.2 MST audio support discussion
On Fri, 16 Oct 2015 02:32:50 +0200, Raymond Yau wrote:
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
Yes, and the mapping doesn't change in this case as before.
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 ?
It's one of the models we've considered. Basically the number of devices can be up to 64 (or such) per pin. For Intel case, due to the limitation of converters, it's up to 3. For other GPUs that may drive more simultaneous outputs, the number increases in square. If a GPU may handle 16 outputs, it'll be 256 entries.
Although the 256 entries are certainly manageable as kctl, whether this is the best representation for user-space is a question.
This is what I concern. Each device entry should have one tag for unsol event. This means each device entry will create a jack?
Yes, and essentially each entry corresponds to a PCM, so we'll end up with 256 PCM (sub)streams :) This doesn't scale.
So, thinking of this issue again, I'm convinced now that static PCM entries with extra dynamic PCM slots as David suggested would work more safely. The number of dynamic PCMs can be either a fixed number per driver type, a constant, or variable via module option.
Takashi
Hi Takashi,
-----Original Message----- From: Takashi Iwai [mailto:tiwai@suse.de] Sent: Friday, October 16, 2015 5:01 PM To: Yang, Libin Cc: Raymond Yau; ALSA Development Mailing List; airlied@linux.ie; Lin, Mengdong; Girdwood, Liam R; tanuk@iki.fi; David Henningsson Subject: Re: [alsa-devel] DP1.2 MST audio support discussion
On Fri, 16 Oct 2015 10:51:30 +0200, Yang, Libin wrote:
Hi Takashi,
-----Original Message----- From: Takashi Iwai [mailto:tiwai@suse.de] Sent: Friday, October 16, 2015 2:38 PM To: Raymond Yau Cc: Yang, Libin; ALSA Development Mailing List; airlied@linux.ie; Lin, Mengdong; Girdwood, Liam R; tanuk@iki.fi; David Henningsson Subject: Re: [alsa-devel] DP1.2 MST audio support discussion
On Fri, 16 Oct 2015 02:32:50 +0200, Raymond Yau wrote:
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
Yes, and the mapping doesn't change in this case as before.
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 ?
It's one of the models we've considered. Basically the number of devices can be up to 64 (or such) per pin. For Intel case, due to the limitation of converters, it's up to 3. For other GPUs that may drive more simultaneous outputs, the number increases in square. If a
GPU
may handle 16 outputs, it'll be 256 entries.
Although the 256 entries are certainly manageable as kctl, whether this is the best representation for user-space is a question.
This is what I concern. Each device entry should have one tag for unsol event. This means each device entry will create a jack?
Yes, and essentially each entry corresponds to a PCM, so we'll end up with 256 PCM (sub)streams :) This doesn't scale.
So, thinking of this issue again, I'm convinced now that static PCM entries with extra dynamic PCM slots as David suggested would work more safely. The number of dynamic PCMs can be either a fixed number per driver type, a constant, or variable via module option.
Yes, we will use static PCM allocation and dynamic PCM attachment. :)
For the Jack, I think I need do some investigation on the HW whether I can use dynamic attachment or not.
Takashi
Hi,
-----Original Message----- From: Takashi Iwai [mailto:tiwai@suse.de] Sent: Friday, October 16, 2015 2:38 PM To: Raymond Yau Cc: Yang, Libin; ALSA Development Mailing List; airlied@linux.ie; Lin, Mengdong; Girdwood, Liam R; tanuk@iki.fi; David Henningsson Subject: Re: [alsa-devel] DP1.2 MST audio support discussion
On Fri, 16 Oct 2015 02:32:50 +0200, Raymond Yau wrote:
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
Yes, and the mapping doesn't change in this case as before.
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 ?
It's one of the models we've considered. Basically the number of devices can be up to 64 (or such) per pin. For Intel case, due to the limitation of converters, it's up to 3. For other GPUs that may drive more simultaneous outputs, the number increases in square. If a GPU may handle 16 outputs, it'll be 256 entries.
Although the 256 entries are certainly manageable as kctl, whether this is the best representation for user-space is a question.
Will three three display port monitor playback devices always play different stream even when the displays are in clone mode ?
The clone mode is another messy part...
After checking internally, we will not support clone mode atm based on the HW suggestion.
If DP MST are dasiy chained, the unplug of the first monitor from
Display
Port will cause all DP monitor in the dasiy chain disconnect
Yes.
Do the power off of the Display Port in the middle of the dasiy chain
also
affect the last display port mointor in the dasiy chain ?
Possibly. But it's not what we really care, as this is the thing the graphics side should handle.
Takashi
Hi Raymond,
From: Raymond Yau [mailto:superquad.vortex2@gmail.com] Sent: Friday, October 16, 2015 8:33 AM To: Takashi Iwai Cc: airlied@linux.ie; tanuk@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?
Regards, Libin
Will three three display port monitor playback devices always play different stream even when the displays are in clone mode ?
If DP MST are dasiy chained, the unplug of the first monitor from
Display
Port will cause all DP monitor in the dasiy chain disconnect
Yes.
Do the power off of the Display Port in the middle of the dasiy chain also affect the last display port mointor in the dasiy chain ?
On 2015-10-22 03:31, Yang, Libin wrote:
Hi Raymond,
From: Raymond Yau [mailto:superquad.vortex2@gmail.com] Sent: Friday, October 16, 2015 8:33 AM To: Takashi Iwai Cc: airlied@linux.ie; tanuk@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/mixe...
-----Original Message----- From: David Henningsson [mailto:david.henningsson@canonical.com] Sent: Thursday, October 22, 2015 2:52 PM To: Yang, Libin; Raymond Yau; Takashi Iwai Cc: airlied@linux.ie; tanuk@iki.fi; Lin, Mengdong; Girdwood, Liam R; ALSA Development Mailing List Subject: Re: [alsa-devel] DP1.2 MST audio support discussion
On 2015-10-22 03:31, Yang, Libin wrote:
Hi Raymond,
From: Raymond Yau [mailto:superquad.vortex2@gmail.com] Sent: Friday, October 16, 2015 8:33 AM To: Takashi Iwai Cc: airlied@linux.ie; tanuk@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?
Regards, Libin
-- David Henningsson, Canonical Ltd. https://launchpad.net/~diwic
On 2015-10-22 08:56, Yang, Libin wrote:
-----Original Message----- From: David Henningsson [mailto:david.henningsson@canonical.com] Sent: Thursday, October 22, 2015 2:52 PM To: Yang, Libin; Raymond Yau; Takashi Iwai Cc: airlied@linux.ie; tanuk@iki.fi; Lin, Mengdong; Girdwood, Liam R; ALSA Development Mailing List Subject: Re: [alsa-devel] DP1.2 MST audio support discussion
On 2015-10-22 03:31, Yang, Libin wrote:
Hi Raymond,
From: Raymond Yau [mailto:superquad.vortex2@gmail.com] Sent: Friday, October 16, 2015 8:33 AM To: Takashi Iwai Cc: airlied@linux.ie; tanuk@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".
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.
From: Raymond Yau [mailto:superquad.vortex2@gmail.com] Sent: Friday, October 16, 2015 8:33 AM To: Takashi Iwai Cc: airlied@linux.ie; tanuk@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.
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.
Regards, Libin
-- David Henningsson, Canonical Ltd. https://launchpad.net/~diwic _______________________________________________ Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
On 2015-10-22 09:40, Yang, Libin wrote:
From: Raymond Yau [mailto:superquad.vortex2@gmail.com] Sent: Friday, October 16, 2015 8:33 AM To: Takashi Iwai Cc: airlied@linux.ie; tanuk@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.)
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.)
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.
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?
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.
-----Original Message----- From: David Henningsson [mailto:david.henningsson@canonical.com] Sent: Thursday, October 22, 2015 4:53 PM To: Yang, Libin; Raymond Yau; Takashi Iwai Cc: airlied@linux.ie; tanuk@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@gmail.com] > Sent: Friday, October 16, 2015 8:33 AM > To: Takashi Iwai > Cc: airlied@linux.ie; tanuk@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
On Thu, 22 Oct 2015 10:52:59 +0200, David Henningsson wrote:
On 2015-10-22 09:40, Yang, Libin wrote:
> From: Raymond Yau [mailto:superquad.vortex2@gmail.com] > Sent: Friday, October 16, 2015 8:33 AM > To: Takashi Iwai > Cc: airlied@linux.ie; tanuk@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.)
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.)
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.
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?
Well, the only question is how PA reacts if we return -ENODEV or whatever for opening an unassigned PCM. I thought PA relies on the PCM open for probing streams at start?
Takashi
-----Original Message----- From: David Henningsson [mailto:david.henningsson@canonical.com] Sent: Thursday, October 22, 2015 4:53 PM
[snip]
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.)
Hi David,
Would you please clarify why PA needs such a fixed binding between PCM 3,7, 8 and pin 0x05,6,7?
And how will PA handle PCM 9,10 in a different way? They are not bound to pins, and even not able to dev indexes. In practice, a platform will usually support either a DP port or a HDMI port from the Intel integrated GPU for cost consideration. But theoretically i915 can use same device index on two different pins to connect monitors, e.g. pin 0x05, dev index 2 for one monitor and pin 0x06, dev index 2 for the other.
On Intel platforms, the max dev indices is 2. Not sure about Nvidia and AMD.
Thanks Mengdong
On Fri, 23 Oct 2015 07:30:12 +0200, Lin, Mengdong wrote:
-----Original Message----- From: David Henningsson [mailto:david.henningsson@canonical.com] Sent: Thursday, October 22, 2015 4:53 PM
[snip]
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.)
Hi David,
Would you please clarify why PA needs such a fixed binding between PCM 3,7, 8 and pin 0x05,6,7?
It's not PA's requirement. The only concern here is for people who uses ALSA device directly, e.g. via aplay -Dhdmi:2. The first monitor is guaranteed to be mapped to the compatible position for such people.
And how will PA handle PCM 9,10 in a different way? They are not bound to pins, and even not able to dev indexes. In practice, a platform will usually support either a DP port or a HDMI port from the Intel integrated GPU for cost consideration. But theoretically i915 can use same device index on two different pins to connect monitors, e.g. pin 0x05, dev index 2 for one monitor and pin 0x06, dev index 2 for the other.
On Intel platforms, the max dev indices is 2. Not sure about Nvidia and AMD.
The whole number should be min(pins * 2 - 1, pins * 64). It's two for Intel, and 7 or more on AMD/Nvidia.
As we've discussed, this "reserved" area is basically optional. We have them for keeping compatibility more easily. Even if this are is exhausted, you can still try to map to any empty slot as the last resort. So, in practice, maybe adding just two extra for this reserved area should suffice. That is, the scheme is:
- Try a static mapping at first - If already occupied, try a dynamic mapping in reserved area - If a dynamic mapping area is exhausted, try to find any empty slot
The device index number doesn't matter. If it conflicts, try another.
Takashi
-----Original Message----- From: Takashi Iwai [mailto:tiwai@suse.de] Sent: Friday, October 23, 2015 1:54 PM
On Fri, 23 Oct 2015 07:30:12 +0200, Lin, Mengdong wrote:
-----Original Message----- From: David Henningsson [mailto:david.henningsson@canonical.com] Sent: Thursday, October 22, 2015 4:53 PM
[snip]
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.)
Hi David,
Would you please clarify why PA needs such a fixed binding between PCM
3,7, 8 and pin 0x05,6,7?
It's not PA's requirement. The only concern here is for people who uses ALSA device directly, e.g. via aplay -Dhdmi:2. The first monitor is guaranteed to be mapped to the compatible position for such people.
Excuse me, could you share more background info here? Even before DP MST support, it seems that such people need to know what pin is used to connect a monitor. Why?
The user can enumerate the PCM devices, and the PCM's jack ioctl can show whether a monitor is available behind this PCM device, no matter the driver uses fixed or dynamic binding between the PCM and pins. So people can always choose a PCM to use a monitor. I feel they need not care which pin is used for the monitor.
And how will PA handle PCM 9,10 in a different way? They are not bound to pins, and even not able to dev indexes. In practice, a platform will usually support either a DP port or a HDMI port
from the Intel integrated GPU for cost consideration.
But theoretically i915 can use same device index on two different pins to
connect monitors, e.g. pin 0x05, dev index 2 for one monitor and pin 0x06, dev index 2 for the other.
On Intel platforms, the max dev indices is 2. Not sure about Nvidia and
AMD.
The whole number should be min(pins * 2 - 1, pins * 64). It's two for Intel, and 7 or more on AMD/Nvidia.
As we've discussed, this "reserved" area is basically optional. We have them for keeping compatibility more easily. Even if this are is exhausted, you can still try to map to any empty slot as the last resort. So, in practice, maybe adding just two extra for this reserved area should suffice. That is, the scheme is:
- Try a static mapping at first
- If already occupied, try a dynamic mapping in reserved area
- If a dynamic mapping area is exhausted, try to find any empty slot
The device index number doesn't matter. If it conflicts, try another.
Thanks for your clarification! This scheme should work. I misunderstood "prefer" as "fixed binding" in David's suggestion.
Regards Mengdong
On Fri, 23 Oct 2015 10:35:26 +0200, Lin, Mengdong wrote:
-----Original Message----- From: Takashi Iwai [mailto:tiwai@suse.de] Sent: Friday, October 23, 2015 1:54 PM
On Fri, 23 Oct 2015 07:30:12 +0200, Lin, Mengdong wrote:
-----Original Message----- From: David Henningsson [mailto:david.henningsson@canonical.com] Sent: Thursday, October 22, 2015 4:53 PM
[snip]
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.)
Hi David,
Would you please clarify why PA needs such a fixed binding between PCM
3,7, 8 and pin 0x05,6,7?
It's not PA's requirement. The only concern here is for people who uses ALSA device directly, e.g. via aplay -Dhdmi:2. The first monitor is guaranteed to be mapped to the compatible position for such people.
Excuse me, could you share more background info here? Even before DP MST support, it seems that such people need to know what pin is used to connect a monitor. Why?
On the existing machines, if you connect to a certain DP port, it's always assigned to the same device. This is guaranteed, so it's perfectly fine to use this device statically for your purpose.
The user can enumerate the PCM devices, and the PCM's jack ioctl can show whether a monitor is available behind this PCM device, no matter the driver uses fixed or dynamic binding between the PCM and pins. So people can always choose a PCM to use a monitor. I feel they need not care which pin is used for the monitor.
People *can* choose, but it doesn't mean people *must* reselect another number out of sudden. If they have to, it may be called a regression.
Takashi
-----Original Message----- From: Takashi Iwai [mailto:tiwai@suse.de] Sent: Friday, October 23, 2015 4:44 PM
On Fri, 23 Oct 2015 10:35:26 +0200, Lin, Mengdong wrote:
-----Original Message----- From: Takashi Iwai [mailto:tiwai@suse.de] Sent: Friday, October 23, 2015 1:54 PM
On Fri, 23 Oct 2015 07:30:12 +0200, Lin, Mengdong wrote:
-----Original Message----- From: David Henningsson
[mailto:david.henningsson@canonical.com]
Sent: Thursday, October 22, 2015 4:53 PM
[snip]
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.)
Hi David,
Would you please clarify why PA needs such a fixed binding between PCM
3,7, 8 and pin 0x05,6,7?
It's not PA's requirement. The only concern here is for people who uses ALSA device directly, e.g. via aplay -Dhdmi:2. The first monitor is guaranteed to be mapped to the compatible position for such
people.
Excuse me, could you share more background info here? Even before DP MST support, it seems that such people need to know what
pin is used to connect a monitor. Why?
On the existing machines, if you connect to a certain DP port, it's always assigned to the same device. This is guaranteed, so it's perfectly fine to use this device statically for your purpose.
The user can enumerate the PCM devices, and the PCM's jack ioctl can
show whether a monitor is available behind this PCM device, no matter the driver uses fixed or dynamic binding between the PCM and pins.
So people can always choose a PCM to use a monitor. I feel they need not
care which pin is used for the monitor.
People *can* choose, but it doesn't mean people *must* reselect another number out of sudden. If they have to, it may be called a regression.
Okay. So the target is trying to assure a monitor uses the same PCM device statically as long as it's physically connected, over display mode change and power cycle. And your and David's scheme to add 2 extra PCM devices in the reserved area should assure this for common configurations on Intel platforms, usually at most 1 DP + 1 HDMI.
We can check the length of device entries for a pin and add (Len -1) PCM devices. This can also work for Nvidia & AMD.
Thanks again for your clarification.
Regards Mengdong
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.)
Hi David,
Would you please clarify why PA needs such a fixed binding between PCM
3,7, 8 and pin 0x05,6,7?
It's not PA's requirement. The only concern here is for people who uses ALSA device directly, e.g. via aplay -Dhdmi:2. The first monitor is guaranteed to be mapped to the compatible position for such people.
And how will PA handle PCM 9,10 in a different way? They are not bound to pins, and even not able to dev indexes. In practice, a platform will usually support either a DP port or a HDMI
port from the Intel integrated GPU for cost consideration.
But theoretically i915 can use same device index on two different pins
to connect monitors, e.g. pin 0x05, dev index 2 for one monitor and pin 0x06, dev index 2 for the other.
On Intel platforms, the max dev indices is 2. Not sure about Nvidia and
AMD.
The whole number should be min(pins * 2 - 1, pins * 64). It's two for Intel, and 7 or more on AMD/Nvidia.
As we've discussed, this "reserved" area is basically optional. We have them for keeping compatibility more easily. Even if this are is exhausted, you can still try to map to any empty slot as the last resort. So, in practice, maybe adding just two extra for this reserved area should suffice. That is, the scheme is:
- Try a static mapping at first
- If already occupied, try a dynamic mapping in reserved area
- If a dynamic mapping area is exhausted, try to find any empty slot
The device index number doesn't matter. If it conflicts, try another.
How do those pcm assigned when the controller have HDMI and two display ports ?
http://www.intel.com/support/motherboards/desktop/sb/CS-034199.htm
Intel® NUC Kit DC53427HYE and Intel® NUC Board D53427RKE
In this configuration, the two displays that you connect to the mini DisplayPort ports must be native DisplayPort-capable. Adapters that change DisplayPort to HDMI or DVI will not work. It is also best that the first display be HDMI without any adapters.
First display HDMI on Intel NUC connected to HDMI or DVI on monitor/TV Max resolution: 1920x1200 Second display Mini-DisplayPort 1 on Intel NUC connected to DisplayPort on monitor/TV Max resolution: 1920x1200 Third display Mini-DisplayPort 2 on Intel NUC connected to DisplayPort on monitor/TV Max resolution: 1920x1200
On 2015-10-23 07:30, Lin, Mengdong wrote:
-----Original Message----- From: David Henningsson [mailto:david.henningsson@canonical.com] Sent: Thursday, October 22, 2015 4:53 PM
[snip]
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.)
Hi David,
Would you please clarify why PA needs such a fixed binding between PCM 3,7, 8 and pin 0x05,6,7?
PulseAudio saves information about profile and volume, and does so on what in PA terminology is called a "port". PA binds this port to a specific Jack kctl and a PCM device. How this fits together is configured in the files in /usr/share/pulseaudio/alsa-mixer/ .
E g, if both one HDMI and one DP monitor are both connected, the user might set the volume (through PA) of the HDMI monitor to high and the DP monitor to low. The user then reboots. Now, the PCM-to-monitor (and Jack kctl-to-monitor) mapping needs to remain the same after a reboot, otherwise PA might restore the volume to the wrong monitor.
And how will PA handle PCM 9,10 in a different way?
PA will handle PCM 9 and 10 in the same way.
They are not bound to pins, and even not able to dev indexes. In practice, a platform will usually support either a DP port or a HDMI port from the Intel integrated GPU for cost consideration. But theoretically i915 can use same device index on two different pins to connect monitors, e.g. pin 0x05, dev index 2 for one monitor and pin 0x06, dev index 2 for the other.
In theory, there are certainly cases where the PCM device allocation can cause problems for PA. What I'm trying to achieve is that these cases will be so few that no one will ever notice.
On Intel platforms, the max dev indices is 2. Not sure about Nvidia and AMD.
Ok, thanks for the clarification.
-----Original Message----- From: David Henningsson [mailto:david.henningsson@canonical.com] Sent: Friday, October 23, 2015 6:56 PM
On 2015-10-23 07:30, Lin, Mengdong wrote:
-----Original Message----- From: David Henningsson [mailto:david.henningsson@canonical.com] Sent: Thursday, October 22, 2015 4:53 PM
[snip]
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.)
Hi David,
Would you please clarify why PA needs such a fixed binding between PCM
3,7, 8 and pin 0x05,6,7?
PulseAudio saves information about profile and volume, and does so on what in PA terminology is called a "port". PA binds this port to a specific Jack kctl and a PCM device. How this fits together is configured in the files in /usr/share/pulseaudio/alsa-mixer/ .
E g, if both one HDMI and one DP monitor are both connected, the user might set the volume (through PA) of the HDMI monitor to high and the DP monitor to low. The user then reboots. Now, the PCM-to-monitor (and Jack kctl-to-monitor) mapping needs to remain the same after a reboot, otherwise PA might restore the volume to the wrong monitor.
I see. Thank you for the info! Random binding can break static mapping since the order of hot-plug unsol events is out of our control.
And how will PA handle PCM 9,10 in a different way?
PA will handle PCM 9 and 10 in the same way.
They are not bound to pins, and even not able to dev indexes. In practice, a platform will usually support either a DP port or a HDMI port
from the Intel integrated GPU for cost consideration.
But theoretically i915 can use same device index on two different pins to
connect monitors, e.g. pin 0x05, dev index 2 for one monitor and pin 0x06, dev index 2 for the other.
In theory, there are certainly cases where the PCM device allocation can cause problems for PA. What I'm trying to achieve is that these cases will be so few that no one will ever notice.
I agree. Your suggestion can keep static mapping between monitors and PCM devices during various display mode change and power cycle for common use cases.
Regards Mengdong
On Intel platforms, the max dev indices is 2. Not sure about Nvidia and
AMD.
Ok, thanks for the clarification.
-- David Henningsson, Canonical Ltd. https://launchpad.net/~diwic
Hi Takashi and David,
There are still some opens. Would you please help to comment?
1. SPDIF kctl. This SPDIF number will be the same as PCM and be bound to the PCM. The pin nid of SPDIF will not be initialized. And the pin nid will be assigned After PCM is bound to the pin. (How to assign?)
2. chmap. The chmap will use the old method. Each virtual pin has its own chmap.
3. lock. When accessing the register, the device entries in the same pin will impact on each other. So when operating on a device entry, it need acquire a lock. Do we need create each lock for each pin or just use one lock for all pins?
4. power management If we close the PCM when disconnecting monitor, the driver will return -ENODEV, and we assume user space will close the PCM at once . Thus the refcount will decrease automatically. So the codec has a chance to enter D3 and release the shared power with GPU. GPU requires to release the power as soon as the monitor is disconnected.
Regards, Libin
-----Original Message----- From: Lin, Mengdong Sent: Friday, October 23, 2015 8:35 PM To: David Henningsson; Yang, Libin; Raymond Yau; Takashi Iwai Cc: airlied@linux.ie; tanuk@iki.fi; ALSA Development Mailing List; Girdwood, Liam R Subject: RE: [alsa-devel] DP1.2 MST audio support discussion
-----Original Message----- From: David Henningsson [mailto:david.henningsson@canonical.com] Sent: Friday, October 23, 2015 6:56 PM
On 2015-10-23 07:30, Lin, Mengdong wrote:
-----Original Message----- From: David Henningsson
[mailto:david.henningsson@canonical.com]
Sent: Thursday, October 22, 2015 4:53 PM
[snip]
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.)
Hi David,
Would you please clarify why PA needs such a fixed binding
between PCM
3,7, 8 and pin 0x05,6,7?
PulseAudio saves information about profile and volume, and does so
on
what in PA terminology is called a "port". PA binds this port to a
specific Jack
kctl and a PCM device. How this fits together is configured in the files
in
/usr/share/pulseaudio/alsa-mixer/ .
E g, if both one HDMI and one DP monitor are both connected, the
user
might set the volume (through PA) of the HDMI monitor to high and
the DP
monitor to low. The user then reboots. Now, the PCM-to-monitor
(and Jack
kctl-to-monitor) mapping needs to remain the same after a reboot, otherwise PA might restore the volume to the wrong monitor.
I see. Thank you for the info! Random binding can break static mapping since the order of hot-plug unsol events is out of our control.
And how will PA handle PCM 9,10 in a different way?
PA will handle PCM 9 and 10 in the same way.
They are not bound to pins, and even not able to dev indexes. In practice, a platform will usually support either a DP port or a
HDMI port
from the Intel integrated GPU for cost consideration.
But theoretically i915 can use same device index on two different
pins to
connect monitors, e.g. pin 0x05, dev index 2 for one monitor and pin
0x06,
dev index 2 for the other.
In theory, there are certainly cases where the PCM device allocation
can
cause problems for PA. What I'm trying to achieve is that these cases
will be
so few that no one will ever notice.
I agree. Your suggestion can keep static mapping between monitors and PCM devices during various display mode change and power cycle for common use cases.
Regards Mengdong
On Intel platforms, the max dev indices is 2. Not sure about Nvidia
and
AMD.
Ok, thanks for the clarification.
-- David Henningsson, Canonical Ltd. https://launchpad.net/~diwic
On Tue, 27 Oct 2015 09:45:17 +0100, Yang, Libin wrote:
Hi Takashi and David,
There are still some opens. Would you please help to comment?
- SPDIF kctl.
This SPDIF number will be the same as PCM and be bound to the PCM. The pin nid of SPDIF will not be initialized. And the pin nid will be assigned After PCM is bound to the pin. (How to assign?)
I don't understand the question. Could you elaborate?
- chmap.
The chmap will use the old method. Each virtual pin has its own chmap.
Yes, and this doesn't change. The chmap is assigned to each PCM stream, basically, so it's tied to the assigned MST dev.
- lock.
When accessing the register, the device entries in the same pin will impact on each other. So when operating on a device entry, it need acquire a lock. Do we need create each lock for each pin or just use one lock for all pins?
It's is no big deal in either way, just choose the simpler one.
- power management
If we close the PCM when disconnecting monitor, the driver will return -ENODEV, and we assume user space will close the PCM at once .
... if we implement it. Actually this behavior (returning -ENODEV) is not mandatory and needs investigation beforehand, whether this breaks any applications, especially PA.
Thus the refcount will decrease automatically. So the codec has a chance to enter D3 and release the shared power with GPU. GPU requires to release the power as soon as the monitor is disconnected.
Is this a problem? The PM scheme doesn't change, after all.
Takashi
Regards, Libin
-----Original Message----- From: Lin, Mengdong Sent: Friday, October 23, 2015 8:35 PM To: David Henningsson; Yang, Libin; Raymond Yau; Takashi Iwai Cc: airlied@linux.ie; tanuk@iki.fi; ALSA Development Mailing List; Girdwood, Liam R Subject: RE: [alsa-devel] DP1.2 MST audio support discussion
-----Original Message----- From: David Henningsson [mailto:david.henningsson@canonical.com] Sent: Friday, October 23, 2015 6:56 PM
On 2015-10-23 07:30, Lin, Mengdong wrote:
-----Original Message----- From: David Henningsson
[mailto:david.henningsson@canonical.com]
Sent: Thursday, October 22, 2015 4:53 PM
[snip]
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.)
Hi David,
Would you please clarify why PA needs such a fixed binding
between PCM
3,7, 8 and pin 0x05,6,7?
PulseAudio saves information about profile and volume, and does so
on
what in PA terminology is called a "port". PA binds this port to a
specific Jack
kctl and a PCM device. How this fits together is configured in the files
in
/usr/share/pulseaudio/alsa-mixer/ .
E g, if both one HDMI and one DP monitor are both connected, the
user
might set the volume (through PA) of the HDMI monitor to high and
the DP
monitor to low. The user then reboots. Now, the PCM-to-monitor
(and Jack
kctl-to-monitor) mapping needs to remain the same after a reboot, otherwise PA might restore the volume to the wrong monitor.
I see. Thank you for the info! Random binding can break static mapping since the order of hot-plug unsol events is out of our control.
And how will PA handle PCM 9,10 in a different way?
PA will handle PCM 9 and 10 in the same way.
They are not bound to pins, and even not able to dev indexes. In practice, a platform will usually support either a DP port or a
HDMI port
from the Intel integrated GPU for cost consideration.
But theoretically i915 can use same device index on two different
pins to
connect monitors, e.g. pin 0x05, dev index 2 for one monitor and pin
0x06,
dev index 2 for the other.
In theory, there are certainly cases where the PCM device allocation
can
cause problems for PA. What I'm trying to achieve is that these cases
will be
so few that no one will ever notice.
I agree. Your suggestion can keep static mapping between monitors and PCM devices during various display mode change and power cycle for common use cases.
Regards Mengdong
On Intel platforms, the max dev indices is 2. Not sure about Nvidia
and
AMD.
Ok, thanks for the clarification.
-- David Henningsson, Canonical Ltd. https://launchpad.net/~diwic
There are still some opens. Would you please help to comment?
- SPDIF kctl.
This SPDIF number will be the same as PCM and be bound to the PCM. The pin nid of SPDIF will not be initialized. And the pin nid will be
assigned
After PCM is bound to the pin. (How to assign?)
I don't understand the question. Could you elaborate?
Are there any difference between three display ports in dasiy chain ?
As they are physically connected to the same complex, do they have own playback switches or only one mute switch for three displayports ?
-----Original Message----- From: alsa-devel-bounces@alsa-project.org [mailto:alsa-devel- bounces@alsa-project.org] On Behalf Of Raymond Yau Sent: Sunday, November 01, 2015 4:53 PM To: Takashi Iwai Cc: Yang, Libin; ALSA Development Mailing List; airlied@linux.ie; Lin, Mengdong; Girdwood, Liam R; tanuk@iki.fi; Lu, Han; David Henningsson Subject: Re: [alsa-devel] DP1.2 MST audio support discussion
There are still some opens. Would you please help to comment?
- SPDIF kctl.
This SPDIF number will be the same as PCM and be bound to the
PCM.
The pin nid of SPDIF will not be initialized. And the pin nid will be
assigned
After PCM is bound to the pin. (How to assign?)
I don't understand the question. Could you elaborate?
Are there any difference between three display ports in dasiy chain ?
As they are physically connected to the same complex, do they have own playback switches or only one mute switch for three displayports ?
I have tried: 2 monitors are connected to a DP MST hub, and the DP MST hub is connected the computer. Each PCM can be muted independently.
I haven't tried: the first monitor is connected the computer and another monitor is connected to the first monitor.
Suppose it should be the same (I'm not very sure). As you know, we use converter to control the mute. Each PCM/device entry uses a different converter.
Regards, Libin
Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
-----Original Message----- From: Takashi Iwai [mailto:tiwai@suse.de] Sent: Friday, October 30, 2015 7:27 PM To: Yang, Libin Cc: Lin, Mengdong; David Henningsson; Raymond Yau; airlied@linux.ie; tanuk@iki.fi; ALSA Development Mailing List; Girdwood, Liam R; Lu, Han Subject: Re: [alsa-devel] DP1.2 MST audio support discussion
On Tue, 27 Oct 2015 09:45:17 +0100, Yang, Libin wrote:
Hi Takashi and David,
There are still some opens. Would you please help to comment?
- SPDIF kctl.
This SPDIF number will be the same as PCM and be bound to the PCM. The pin nid of SPDIF will not be initialized. And the pin nid will be
assigned
After PCM is bound to the pin. (How to assign?)
I don't understand the question. Could you elaborate?
In alsamixer for HDMI, we can see S/PDIF ctl to control mute/unmute. Also in driver, we can see it creates the ctls with snd_hda_create_dig_out_ctls() in build_controls() based on pin number. I wonder whether user space use these ctls based on pin or pcm? Suppose it should be also based on PCM, right?
- chmap.
The chmap will use the old method. Each virtual pin has its own
chmap.
Yes, and this doesn't change. The chmap is assigned to each PCM stream, basically, so it's tied to the assigned MST dev.
Thanks.
- lock.
When accessing the register, the device entries in the same pin will
impact on
each other. So when operating on a device entry, it need acquire a
lock.
Do we need create each lock for each pin or just use one lock for all
pins?
It's is no big deal in either way, just choose the simpler one.
Get it. Thanks.
- power management
If we close the PCM when disconnecting monitor, the driver will
return
-ENODEV, and we assume user space will close the PCM at once .
... if we implement it. Actually this behavior (returning -ENODEV) is not mandatory and needs investigation beforehand, whether this breaks any applications, especially PA.
Yes. I heard that PA has dummy PCM and when there is no HW to play the audio, PA can smoothly move the PCM from HW to dummy PCM. If it's true, stopping PCM will not break PA, I think.
Thus the refcount will decrease automatically. So the codec has a
chance
to enter D3 and release the shared power with GPU. GPU requires to release the power as soon as the monitor is disconnected.
Is this a problem? The PM scheme doesn't change, after all.
Get it. Thanks.
Regards, Libin
Takashi
Regards, Libin
-----Original Message----- From: Lin, Mengdong Sent: Friday, October 23, 2015 8:35 PM To: David Henningsson; Yang, Libin; Raymond Yau; Takashi Iwai Cc: airlied@linux.ie; tanuk@iki.fi; ALSA Development Mailing List; Girdwood, Liam R Subject: RE: [alsa-devel] DP1.2 MST audio support discussion
-----Original Message----- From: David Henningsson
[mailto:david.henningsson@canonical.com]
Sent: Friday, October 23, 2015 6:56 PM
On 2015-10-23 07:30, Lin, Mengdong wrote:
-----Original Message----- From: David Henningsson
[mailto:david.henningsson@canonical.com]
Sent: Thursday, October 22, 2015 4:53 PM
[snip]
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.)
Hi David,
Would you please clarify why PA needs such a fixed binding
between PCM
3,7, 8 and pin 0x05,6,7?
PulseAudio saves information about profile and volume, and does
so
on
what in PA terminology is called a "port". PA binds this port to a
specific Jack
kctl and a PCM device. How this fits together is configured in the
files
in
/usr/share/pulseaudio/alsa-mixer/ .
E g, if both one HDMI and one DP monitor are both connected,
the
user
might set the volume (through PA) of the HDMI monitor to high
and
the DP
monitor to low. The user then reboots. Now, the PCM-to-
monitor
(and Jack
kctl-to-monitor) mapping needs to remain the same after a
reboot,
otherwise PA might restore the volume to the wrong monitor.
I see. Thank you for the info! Random binding can break static mapping since the order of hot-
plug
unsol events is out of our control.
And how will PA handle PCM 9,10 in a different way?
PA will handle PCM 9 and 10 in the same way.
They are not bound to pins, and even not able to dev indexes. In practice, a platform will usually support either a DP port or a
HDMI port
from the Intel integrated GPU for cost consideration.
But theoretically i915 can use same device index on two
different
pins to
connect monitors, e.g. pin 0x05, dev index 2 for one monitor and
pin
0x06,
dev index 2 for the other.
In theory, there are certainly cases where the PCM device
allocation
can
cause problems for PA. What I'm trying to achieve is that these
cases
will be
so few that no one will ever notice.
I agree. Your suggestion can keep static mapping between
monitors
and PCM devices during various display mode change and power
cycle
for common use cases.
Regards Mengdong
On Intel platforms, the max dev indices is 2. Not sure about
Nvidia
and
AMD.
Ok, thanks for the clarification.
-- David Henningsson, Canonical Ltd. https://launchpad.net/~diwic
On Mon, 02 Nov 2015 08:30:19 +0100, Yang, Libin wrote:
-----Original Message----- From: Takashi Iwai [mailto:tiwai@suse.de] Sent: Friday, October 30, 2015 7:27 PM To: Yang, Libin Cc: Lin, Mengdong; David Henningsson; Raymond Yau; airlied@linux.ie; tanuk@iki.fi; ALSA Development Mailing List; Girdwood, Liam R; Lu, Han Subject: Re: [alsa-devel] DP1.2 MST audio support discussion
On Tue, 27 Oct 2015 09:45:17 +0100, Yang, Libin wrote:
Hi Takashi and David,
There are still some opens. Would you please help to comment?
- SPDIF kctl.
This SPDIF number will be the same as PCM and be bound to the PCM. The pin nid of SPDIF will not be initialized. And the pin nid will be
assigned
After PCM is bound to the pin. (How to assign?)
I don't understand the question. Could you elaborate?
In alsamixer for HDMI, we can see S/PDIF ctl to control mute/unmute. Also in driver, we can see it creates the ctls with snd_hda_create_dig_out_ctls() in build_controls() based on pin number. I wonder whether user space use these ctls based on pin or pcm? Suppose it should be also based on PCM, right?
Right, these are for PCMs
Takashi
On 2015-11-02 08:30, Yang, Libin wrote:
- power management
If we close the PCM when disconnecting monitor, the driver will
return
-ENODEV, and we assume user space will close the PCM at once .
... if we implement it. Actually this behavior (returning -ENODEV) is not mandatory and needs investigation beforehand, whether this breaks any applications, especially PA.
Yes. I heard that PA has dummy PCM and when there is no HW to play the audio, PA can smoothly move the PCM from HW to dummy PCM. If it's true, stopping PCM will not break PA, I think.
Well, in most cases (not all) there will be an analog output available, so we're more likely to move there than to a dummy PCM. The problem is that PA does not currently figure out that a -ENODEV means that one should switch from a digital to an analog profile. So, at least at this point, don't expect a "smooth move".
I'm not sure if this is a good idea or not, but just brainstorming here:
If PA (or other application) tries to play back to a PCM, and that PCM is currently unassigned. What would happen if we actually assigned a converter node at that point, but no pin node connected to that converter node? Would that give a backwards compatible behaviour? I e, audio userspace could successfully play back audio through the converter node, but then the audio goes nowhere because there is no pin node assigned?
(Or perhaps we PA developers should actually start supporting this properly like we said that we should do, for like three years or something...)
// David
+ Jani, who is from Intel gfx team.
-----Original Message----- From: David Henningsson [mailto:david.henningsson@canonical.com] Sent: Monday, November 02, 2015 3:55 PM To: Yang, Libin; Takashi Iwai Cc: Lin, Mengdong; Raymond Yau; airlied@linux.ie; tanuk@iki.fi; ALSA Development Mailing List; Girdwood, Liam R; Lu, Han Subject: Re: [alsa-devel] DP1.2 MST audio support discussion
On 2015-11-02 08:30, Yang, Libin wrote:
- power management
If we close the PCM when disconnecting monitor, the driver will
return
-ENODEV, and we assume user space will close the PCM at once .
... if we implement it. Actually this behavior (returning -ENODEV) is not mandatory and needs investigation beforehand, whether this breaks any applications, especially PA.
Yes. I heard that PA has dummy PCM and when there is no HW to play the audio, PA can smoothly move the PCM from HW to dummy PCM. If it's true, stopping PCM will not break PA, I think.
Well, in most cases (not all) there will be an analog output available, so we're more likely to move there than to a dummy PCM. The problem is that PA does not currently figure out that a -ENODEV means that one should switch from a digital to an analog profile. So, at least at this point, don't expect a "smooth move".
I'm not sure if this is a good idea or not, but just brainstorming here:
If PA (or other application) tries to play back to a PCM, and that PCM is currently unassigned. What would happen if we actually assigned a converter node at that point, but no pin node connected to that converter node? Would that give a backwards compatible behaviour? I e, audio userspace could successfully play back audio through the converter node, but then the audio goes nowhere because there is no pin node assigned?
GFX team hope us that if there is no monitor connected, audio should release gfx so gfx driver can enter power save mode. Based on the requirement, audio driver may need stop playback as soon as the monitor is disconnected.
(Or perhaps we PA developers should actually start supporting this properly like we said that we should do, for like three years or something...)
// David
On Wed, 04 Nov 2015, "Yang, Libin" libin.yang@intel.com wrote:
- Jani, who is from Intel gfx team.
-----Original Message----- From: David Henningsson [mailto:david.henningsson@canonical.com] Sent: Monday, November 02, 2015 3:55 PM To: Yang, Libin; Takashi Iwai Cc: Lin, Mengdong; Raymond Yau; airlied@linux.ie; tanuk@iki.fi; ALSA Development Mailing List; Girdwood, Liam R; Lu, Han Subject: Re: [alsa-devel] DP1.2 MST audio support discussion
On 2015-11-02 08:30, Yang, Libin wrote:
- power management
If we close the PCM when disconnecting monitor, the driver will
return
-ENODEV, and we assume user space will close the PCM at once .
... if we implement it. Actually this behavior (returning -ENODEV) is not mandatory and needs investigation beforehand, whether this breaks any applications, especially PA.
Yes. I heard that PA has dummy PCM and when there is no HW to play the audio, PA can smoothly move the PCM from HW to dummy PCM. If it's true, stopping PCM will not break PA, I think.
Well, in most cases (not all) there will be an analog output available, so we're more likely to move there than to a dummy PCM. The problem is that PA does not currently figure out that a -ENODEV means that one should switch from a digital to an analog profile. So, at least at this point, don't expect a "smooth move".
I'm not sure if this is a good idea or not, but just brainstorming here:
If PA (or other application) tries to play back to a PCM, and that PCM is currently unassigned. What would happen if we actually assigned a converter node at that point, but no pin node connected to that converter node? Would that give a backwards compatible behaviour? I e, audio userspace could successfully play back audio through the converter node, but then the audio goes nowhere because there is no pin node assigned?
GFX team hope us that if there is no monitor connected, audio should release gfx so gfx driver can enter power save mode. Based on the requirement, audio driver may need stop playback as soon as the monitor is disconnected.
Rather, as soon as the userspace responding to hotplug uevents has reacted and disabled the display. See [1] for a better explanation. In other words, it would be desirable that you call the put power hook in response to intel_audio_codec_disable().
BR, Jani.
[1] https://bugs.freedesktop.org/show_bug.cgi?id=90447#c19
(Or perhaps we PA developers should actually start supporting this properly like we said that we should do, for like three years or something...)
// David
On 2015-11-04 15:17, Yang, Libin wrote:
- Jani, who is from Intel gfx team.
-----Original Message----- From: David Henningsson [mailto:david.henningsson@canonical.com] Sent: Monday, November 02, 2015 3:55 PM To: Yang, Libin; Takashi Iwai Cc: Lin, Mengdong; Raymond Yau; airlied@linux.ie; tanuk@iki.fi; ALSA Development Mailing List; Girdwood, Liam R; Lu, Han Subject: Re: [alsa-devel] DP1.2 MST audio support discussion
On 2015-11-02 08:30, Yang, Libin wrote:
- power management
If we close the PCM when disconnecting monitor, the driver will
return
-ENODEV, and we assume user space will close the PCM at once .
... if we implement it. Actually this behavior (returning -ENODEV) is not mandatory and needs investigation beforehand, whether this breaks any applications, especially PA.
Yes. I heard that PA has dummy PCM and when there is no HW to play the audio, PA can smoothly move the PCM from HW to dummy PCM. If it's true, stopping PCM will not break PA, I think.
Well, in most cases (not all) there will be an analog output available, so we're more likely to move there than to a dummy PCM. The problem is that PA does not currently figure out that a -ENODEV means that one should switch from a digital to an analog profile. So, at least at this point, don't expect a "smooth move".
I'm not sure if this is a good idea or not, but just brainstorming here:
If PA (or other application) tries to play back to a PCM, and that PCM is currently unassigned. What would happen if we actually assigned a converter node at that point, but no pin node connected to that converter node? Would that give a backwards compatible behaviour? I e, audio userspace could successfully play back audio through the converter node, but then the audio goes nowhere because there is no pin node assigned?
GFX team hope us that if there is no monitor connected, audio should release gfx so gfx driver can enter power save mode. Based on the requirement, audio driver may need stop playback as soon as the monitor is disconnected.
I'm not talking about continuous playback here, so power consumption should not be a big concern. E g, if it takes a second or so before PA reroutes audio somewhere else, it's not a big deal from a power save perspective.
So I'm asking my question again. What would happen (on Intel hardware), if you stream audio to a converter node on the audio codec, and there is no pin node connected to that converter node?
So I'm asking my question again. What would happen (on Intel hardware),
if you stream audio to a converter node on the audio codec, and there is no pin node connected to that converter node?
https://git.kernel.org/cgit/linux/kernel/git/tiwai/sound.git/commit/sound/pc...
For alt analog playback device , it return EBUSY when DAC of HP is not available (independent switch is OFF)
BTW, as pulseaudio does not support multi streaming (e.g. playing different audio stream to HP and rear panel of desktop)
How can pulseaudio support displayport multi streaming ?
Hi David,
-----Original Message----- From: David Henningsson [mailto:david.henningsson@canonical.com] Sent: Thursday, November 05, 2015 5:07 PM To: Yang, Libin; Takashi Iwai Cc: Lin, Mengdong; Raymond Yau; airlied@linux.ie; tanuk@iki.fi; ALSA Development Mailing List; Girdwood, Liam R; Lu, Han; Nikula, Jani Subject: Re: [alsa-devel] DP1.2 MST audio support discussion
On 2015-11-04 15:17, Yang, Libin wrote:
- Jani, who is from Intel gfx team.
-----Original Message----- From: David Henningsson [mailto:david.henningsson@canonical.com] Sent: Monday, November 02, 2015 3:55 PM To: Yang, Libin; Takashi Iwai Cc: Lin, Mengdong; Raymond Yau; airlied@linux.ie; tanuk@iki.fi; ALSA Development Mailing List; Girdwood, Liam R; Lu, Han Subject: Re: [alsa-devel] DP1.2 MST audio support discussion
On 2015-11-02 08:30, Yang, Libin wrote:
- power management
If we close the PCM when disconnecting monitor, the driver will
return
-ENODEV, and we assume user space will close the PCM at once .
... if we implement it. Actually this behavior (returning -ENODEV) is not mandatory and needs investigation beforehand, whether this breaks any applications, especially PA.
Yes. I heard that PA has dummy PCM and when there is no HW to play the audio, PA can smoothly move the PCM from HW to dummy PCM. If it's true, stopping PCM will not break PA, I think.
Well, in most cases (not all) there will be an analog output available, so we're more likely to move there than to a dummy PCM. The problem is that PA does not currently figure out that a -ENODEV means that one should switch from a digital to an analog profile. So, at least at this point, don't expect a "smooth move".
I'm not sure if this is a good idea or not, but just brainstorming here:
If PA (or other application) tries to play back to a PCM, and that PCM is currently unassigned. What would happen if we actually assigned a converter node at that point, but no pin node connected to that converter node? Would that give a backwards compatible behaviour?
I
e, audio userspace could successfully play back audio through the converter node, but then the audio goes nowhere because there is no pin node assigned?
GFX team hope us that if there is no monitor connected, audio should release gfx so gfx driver can enter power save mode. Based on the requirement, audio driver may need stop playback as soon as the monitor is disconnected.
I'm not talking about continuous playback here, so power consumption should not be a big concern. E g, if it takes a second or so before PA reroutes audio somewhere else, it's not a big deal from a power save perspective.
So I'm asking my question again. What would happen (on Intel hardware), if you stream audio to a converter node on the audio codec, and there is no pin node connected to that converter node?
I changed the audio driver and did the test today. The test is: 1. Pin 5 connect to converter 2 and playback, there is sound from pin 5. 2. Pin 5 connect to converter 2 (no other pin is connected to cvt2), no sound. 3. Pin 5 connect back to cvt 2, there is sound, playback is normal.
And in step 2, the playback is still ongoing but no sound is out from any pin.
-- David Henningsson, Canonical Ltd. https://launchpad.net/~diwic
On 2015-11-10 07:46, Yang, Libin wrote:
Hi David,
-----Original Message----- From: David Henningsson [mailto:david.henningsson@canonical.com] Sent: Thursday, November 05, 2015 5:07 PM To: Yang, Libin; Takashi Iwai Cc: Lin, Mengdong; Raymond Yau; airlied@linux.ie; tanuk@iki.fi; ALSA Development Mailing List; Girdwood, Liam R; Lu, Han; Nikula, Jani Subject: Re: [alsa-devel] DP1.2 MST audio support discussion
So I'm asking my question again. What would happen (on Intel hardware), if you stream audio to a converter node on the audio codec, and there is no pin node connected to that converter node?
I changed the audio driver and did the test today. The test is:
- Pin 5 connect to converter 2 and playback, there is sound from pin 5.
- Pin 5 connect to converter 2 (no other pin is connected to cvt2), no sound.
- Pin 5 connect back to cvt 2, there is sound, playback is normal.
And in step 2, the playback is still ongoing but no sound is out from any pin.
Sounds good to me, thanks for testing. Is this workaround something we could utilize in order to not break userspace? (This is a question for both you and Takashi.)
What we'll end up is essentially three types of objects:
* PCM device (5 devices, 3,7,8,9,10) - all five devices are allocated when the driver initializes - all kcontrols are always bound to the PCM device (jack kctl, eld kctl, iec958 kctls etc)
* Monitor (pin + MST index) - dynamically bound to a PCM at monitor plug-in time, according to a scheme that maximises the possibility for a monitor to always end up at the same PCM (as specified in earlier emails)
* Converter node (3 nodes for Intel hardware) - dynamically bound to a PCM at playback open time (regardless of whether the PCM has a monitor or not) - return -EBUSY in case there is no free converter node
-----Original Message----- From: David Henningsson [mailto:david.henningsson@canonical.com] Sent: Tuesday, November 10, 2015 3:45 PM To: Yang, Libin; Takashi Iwai Cc: Lin, Mengdong; Raymond Yau; airlied@linux.ie; tanuk@iki.fi; ALSA Development Mailing List; Girdwood, Liam R; Lu, Han; Nikula, Jani Subject: Re: [alsa-devel] DP1.2 MST audio support discussion
On 2015-11-10 07:46, Yang, Libin wrote:
Hi David,
-----Original Message----- From: David Henningsson [mailto:david.henningsson@canonical.com] Sent: Thursday, November 05, 2015 5:07 PM To: Yang, Libin; Takashi Iwai Cc: Lin, Mengdong; Raymond Yau; airlied@linux.ie; tanuk@iki.fi; ALSA Development Mailing List; Girdwood, Liam R; Lu, Han; Nikula, Jani Subject: Re: [alsa-devel] DP1.2 MST audio support discussion
So I'm asking my question again. What would happen (on Intel
hardware),
if you stream audio to a converter node on the audio codec, and there
is
no pin node connected to that converter node?
I changed the audio driver and did the test today. The test is:
- Pin 5 connect to converter 2 and playback, there is sound from pin 5.
- Pin 5 connect to converter 2 (no other pin is connected to cvt2), no
sound.
- Pin 5 connect back to cvt 2, there is sound, playback is normal.
And in step 2, the playback is still ongoing but no sound is out from any
pin.
Sounds good to me, thanks for testing. Is this workaround something we could utilize in order to not break userspace? (This is a question for both you and Takashi.)
What we'll end up is essentially three types of objects:
- PCM device (5 devices, 3,7,8,9,10)
- all five devices are allocated when the driver initializes
This should be for Intel platform, right? The actually number should be: pin number + device entry number - 1. On intel platform, pin_num = 3, dev_num = 3, so it will be 5.
- all kcontrols are always bound to the PCM device (jack kctl, eld
kctl, iec958 kctls etc)
Sure, I agree on it.
- Monitor (pin + MST index)
- dynamically bound to a PCM at monitor plug-in time, according to a
scheme that maximises the possibility for a monitor to always end up at the same PCM (as specified in earlier emails)
- Converter node (3 nodes for Intel hardware)
- dynamically bound to a PCM at playback open time (regardless of
whether the PCM has a monitor or not)
If so, we still need use converter on codec. This means we can't turn off the power well in i915.
To save the power, i915 suggests that if no monitor is connected, we should not use the HDMI codec. This means open a PCM with no pin attached will fail. Disconnecting monitor when the corresponding PCM is playback will trigger stop PCM.
To help move to the new method smoothly, I will add a flag. User can decide whether to use the aggressive power saving solution or not.
- return -EBUSY in case there is no free converter node
Regards, Libin
-- David Henningsson, Canonical Ltd. https://launchpad.net/~diwic
-----Original Message----- From: Yang, Libin Sent: Wednesday, November 11, 2015 10:04 AM To: David Henningsson; Takashi Iwai Cc: Lin, Mengdong; Raymond Yau; airlied@linux.ie; tanuk@iki.fi; ALSA Development Mailing List; Girdwood, Liam R; Lu, Han; Nikula, Jani Subject: RE: [alsa-devel] DP1.2 MST audio support discussion
-----Original Message----- From: David Henningsson [mailto:david.henningsson@canonical.com] Sent: Tuesday, November 10, 2015 3:45 PM To: Yang, Libin; Takashi Iwai Cc: Lin, Mengdong; Raymond Yau; airlied@linux.ie; tanuk@iki.fi; ALSA Development Mailing List; Girdwood, Liam R; Lu, Han; Nikula, Jani Subject: Re: [alsa-devel] DP1.2 MST audio support discussion
On 2015-11-10 07:46, Yang, Libin wrote:
Hi David,
-----Original Message----- From: David Henningsson
[mailto:david.henningsson@canonical.com]
Sent: Thursday, November 05, 2015 5:07 PM To: Yang, Libin; Takashi Iwai Cc: Lin, Mengdong; Raymond Yau; airlied@linux.ie; tanuk@iki.fi;
ALSA
Development Mailing List; Girdwood, Liam R; Lu, Han; Nikula, Jani Subject: Re: [alsa-devel] DP1.2 MST audio support discussion
So I'm asking my question again. What would happen (on Intel
hardware),
if you stream audio to a converter node on the audio codec, and
there
is
no pin node connected to that converter node?
I changed the audio driver and did the test today. The test is:
- Pin 5 connect to converter 2 and playback, there is sound from pin
- Pin 5 connect to converter 2 (no other pin is connected to cvt2), no
sound.
- Pin 5 connect back to cvt 2, there is sound, playback is normal.
And in step 2, the playback is still ongoing but no sound is out from
any
pin.
Sounds good to me, thanks for testing. Is this workaround something
we
could utilize in order to not break userspace? (This is a question for both you and Takashi.)
What we'll end up is essentially three types of objects:
- PCM device (5 devices, 3,7,8,9,10)
- all five devices are allocated when the driver initializes
This should be for Intel platform, right? The actually number should be: pin number + device entry number - 1. On intel platform, pin_num = 3, dev_num = 3, so it will be 5.
- all kcontrols are always bound to the PCM device (jack kctl, eld
kctl, iec958 kctls etc)
Sure, I agree on it.
- Monitor (pin + MST index)
- dynamically bound to a PCM at monitor plug-in time, according to a
scheme that maximises the possibility for a monitor to always end up at the same PCM (as specified in earlier emails)
- Converter node (3 nodes for Intel hardware)
- dynamically bound to a PCM at playback open time (regardless of
whether the PCM has a monitor or not)
If so, we still need use converter on codec. This means we can't turn off the power well in i915.
To save the power, i915 suggests that if no monitor is connected, we should not use the HDMI codec. This means open a PCM with no pin attached will fail. Disconnecting monitor when the corresponding PCM is playback will trigger stop PCM.
To help move to the new method smoothly, I will add a flag. User can decide whether to use the aggressive power saving solution or not.
In hdmi_pcm_open(), it will judge whether pin_idx is valid, if not it will return -EINVAL. So for dynamic PCM assignment, open will fail if no monitor is connected.
If we want to support open on PCM without monitor, many code must be rewrited. And it seems open a PCM without monitor is not a good behavior. As Raymond said in previous email, For alt analog playback device , it return EBUSY when DAC of HP is not available. I think for HDMI audio we can have the aligned behavior? And -ENODEV may be better.
Regards, Libin
- return -EBUSY in case there is no free converter nodeRegards, Libin
-- David Henningsson, Canonical Ltd. https://launchpad.net/~diwic
On Wed, 11 Nov 2015 08:58:29 +0100, Yang, Libin wrote:
-----Original Message----- From: Yang, Libin Sent: Wednesday, November 11, 2015 10:04 AM To: David Henningsson; Takashi Iwai Cc: Lin, Mengdong; Raymond Yau; airlied@linux.ie; tanuk@iki.fi; ALSA Development Mailing List; Girdwood, Liam R; Lu, Han; Nikula, Jani Subject: RE: [alsa-devel] DP1.2 MST audio support discussion
-----Original Message----- From: David Henningsson [mailto:david.henningsson@canonical.com] Sent: Tuesday, November 10, 2015 3:45 PM To: Yang, Libin; Takashi Iwai Cc: Lin, Mengdong; Raymond Yau; airlied@linux.ie; tanuk@iki.fi; ALSA Development Mailing List; Girdwood, Liam R; Lu, Han; Nikula, Jani Subject: Re: [alsa-devel] DP1.2 MST audio support discussion
On 2015-11-10 07:46, Yang, Libin wrote:
Hi David,
-----Original Message----- From: David Henningsson
[mailto:david.henningsson@canonical.com]
Sent: Thursday, November 05, 2015 5:07 PM To: Yang, Libin; Takashi Iwai Cc: Lin, Mengdong; Raymond Yau; airlied@linux.ie; tanuk@iki.fi;
ALSA
Development Mailing List; Girdwood, Liam R; Lu, Han; Nikula, Jani Subject: Re: [alsa-devel] DP1.2 MST audio support discussion
So I'm asking my question again. What would happen (on Intel
hardware),
if you stream audio to a converter node on the audio codec, and
there
is
no pin node connected to that converter node?
I changed the audio driver and did the test today. The test is:
- Pin 5 connect to converter 2 and playback, there is sound from pin
- Pin 5 connect to converter 2 (no other pin is connected to cvt2), no
sound.
- Pin 5 connect back to cvt 2, there is sound, playback is normal.
And in step 2, the playback is still ongoing but no sound is out from
any
pin.
Sounds good to me, thanks for testing. Is this workaround something
we
could utilize in order to not break userspace? (This is a question for both you and Takashi.)
What we'll end up is essentially three types of objects:
- PCM device (5 devices, 3,7,8,9,10)
- all five devices are allocated when the driver initializes
This should be for Intel platform, right? The actually number should be: pin number + device entry number - 1. On intel platform, pin_num = 3, dev_num = 3, so it will be 5.
- all kcontrols are always bound to the PCM device (jack kctl, eld
kctl, iec958 kctls etc)
Sure, I agree on it.
- Monitor (pin + MST index)
- dynamically bound to a PCM at monitor plug-in time, according to a
scheme that maximises the possibility for a monitor to always end up at the same PCM (as specified in earlier emails)
- Converter node (3 nodes for Intel hardware)
- dynamically bound to a PCM at playback open time (regardless of
whether the PCM has a monitor or not)
If so, we still need use converter on codec. This means we can't turn off the power well in i915.
To save the power, i915 suggests that if no monitor is connected, we should not use the HDMI codec. This means open a PCM with no pin attached will fail. Disconnecting monitor when the corresponding PCM is playback will trigger stop PCM.
To help move to the new method smoothly, I will add a flag. User can decide whether to use the aggressive power saving solution or not.
In hdmi_pcm_open(), it will judge whether pin_idx is valid, if not it will return -EINVAL. So for dynamic PCM assignment, open will fail if no monitor is connected.
If we want to support open on PCM without monitor, many code must be rewrited. And it seems open a PCM without monitor is not a good behavior. As Raymond said in previous email, For alt analog playback device , it return EBUSY when DAC of HP is not available. I think for HDMI audio we can have the aligned behavior? And -ENODEV may be better.
Libin, it's why I've been repeated asking to split the patches, instead of posting a big iron patch. Then we can test and evaluate whether this part is really working in general.
Takashi
Hi Takashi,
-----Original Message----- From: Takashi Iwai [mailto:tiwai@suse.de] Sent: Wednesday, November 11, 2015 4:06 PM To: Yang, Libin Cc: 'David Henningsson'; Lin, Mengdong; 'Raymond Yau'; 'airlied@linux.ie'; 'tanuk@iki.fi'; 'ALSA Development Mailing List'; Girdwood, Liam R; Lu, Han; Nikula, Jani Subject: Re: [alsa-devel] DP1.2 MST audio support discussion
On Wed, 11 Nov 2015 08:58:29 +0100, Yang, Libin wrote:
-----Original Message----- From: Yang, Libin Sent: Wednesday, November 11, 2015 10:04 AM To: David Henningsson; Takashi Iwai Cc: Lin, Mengdong; Raymond Yau; airlied@linux.ie; tanuk@iki.fi; ALSA Development Mailing List; Girdwood, Liam R; Lu, Han; Nikula, Jani Subject: RE: [alsa-devel] DP1.2 MST audio support discussion
-----Original Message----- From: David Henningsson
[mailto:david.henningsson@canonical.com]
Sent: Tuesday, November 10, 2015 3:45 PM To: Yang, Libin; Takashi Iwai Cc: Lin, Mengdong; Raymond Yau; airlied@linux.ie; tanuk@iki.fi;
ALSA
Development Mailing List; Girdwood, Liam R; Lu, Han; Nikula, Jani Subject: Re: [alsa-devel] DP1.2 MST audio support discussion
On 2015-11-10 07:46, Yang, Libin wrote:
Hi David,
-----Original Message----- From: David Henningsson
[mailto:david.henningsson@canonical.com]
Sent: Thursday, November 05, 2015 5:07 PM To: Yang, Libin; Takashi Iwai Cc: Lin, Mengdong; Raymond Yau; airlied@linux.ie; tanuk@iki.fi;
ALSA
Development Mailing List; Girdwood, Liam R; Lu, Han; Nikula,
Jani
Subject: Re: [alsa-devel] DP1.2 MST audio support discussion
So I'm asking my question again. What would happen (on Intel
hardware),
if you stream audio to a converter node on the audio codec, and
there
is
no pin node connected to that converter node?
I changed the audio driver and did the test today. The test is:
- Pin 5 connect to converter 2 and playback, there is sound from
pin
- Pin 5 connect to converter 2 (no other pin is connected to cvt2),
no
sound.
- Pin 5 connect back to cvt 2, there is sound, playback is normal.
And in step 2, the playback is still ongoing but no sound is out from
any
pin.
Sounds good to me, thanks for testing. Is this workaround
something
we
could utilize in order to not break userspace? (This is a question for both you and Takashi.)
What we'll end up is essentially three types of objects:
- PCM device (5 devices, 3,7,8,9,10)
- all five devices are allocated when the driver initializes
This should be for Intel platform, right? The actually number should be: pin number + device entry number - 1. On intel platform, pin_num = 3, dev_num = 3, so it will be 5.
- all kcontrols are always bound to the PCM device (jack kctl, eld
kctl, iec958 kctls etc)
Sure, I agree on it.
- Monitor (pin + MST index)
- dynamically bound to a PCM at monitor plug-in time, according
to a
scheme that maximises the possibility for a monitor to always end
up at
the same PCM (as specified in earlier emails)
- Converter node (3 nodes for Intel hardware)
- dynamically bound to a PCM at playback open time (regardless
of
whether the PCM has a monitor or not)
If so, we still need use converter on codec. This means we can't turn off the power well in i915.
To save the power, i915 suggests that if no monitor is connected, we should not use the HDMI codec. This means open a PCM with no pin attached will fail. Disconnecting monitor when the
corresponding
PCM is playback will trigger stop PCM.
To help move to the new method smoothly, I will add a flag. User can decide whether to use the aggressive power saving solution or not.
In hdmi_pcm_open(), it will judge whether pin_idx is valid, if not it will return -EINVAL. So for dynamic PCM assignment, open will fail if no monitor is connected.
If we want to support open on PCM without monitor, many code must be rewrited. And it seems open a PCM without monitor is not a good behavior. As Raymond said in previous email, For alt analog playback device , it return EBUSY when DAC of HP is not available. I think for HDMI audio we can have the aligned behavior? And -ENODEV may be better.
Libin, it's why I've been repeated asking to split the patches, instead of posting a big iron patch. Then we can test and evaluate whether this part is really working in general.
Yes, I understand. :) The patches are being split. Suppose these 2 days patches should be ready for review.
Regards, Libin
Takashi
On Wed, 11 Nov 2015 09:11:49 +0100, Yang, Libin wrote:
Hi Takashi,
-----Original Message----- From: Takashi Iwai [mailto:tiwai@suse.de] Sent: Wednesday, November 11, 2015 4:06 PM To: Yang, Libin Cc: 'David Henningsson'; Lin, Mengdong; 'Raymond Yau'; 'airlied@linux.ie'; 'tanuk@iki.fi'; 'ALSA Development Mailing List'; Girdwood, Liam R; Lu, Han; Nikula, Jani Subject: Re: [alsa-devel] DP1.2 MST audio support discussion
On Wed, 11 Nov 2015 08:58:29 +0100, Yang, Libin wrote:
-----Original Message----- From: Yang, Libin Sent: Wednesday, November 11, 2015 10:04 AM To: David Henningsson; Takashi Iwai Cc: Lin, Mengdong; Raymond Yau; airlied@linux.ie; tanuk@iki.fi; ALSA Development Mailing List; Girdwood, Liam R; Lu, Han; Nikula, Jani Subject: RE: [alsa-devel] DP1.2 MST audio support discussion
-----Original Message----- From: David Henningsson
[mailto:david.henningsson@canonical.com]
Sent: Tuesday, November 10, 2015 3:45 PM To: Yang, Libin; Takashi Iwai Cc: Lin, Mengdong; Raymond Yau; airlied@linux.ie; tanuk@iki.fi;
ALSA
Development Mailing List; Girdwood, Liam R; Lu, Han; Nikula, Jani Subject: Re: [alsa-devel] DP1.2 MST audio support discussion
On 2015-11-10 07:46, Yang, Libin wrote:
Hi David,
> -----Original Message----- > From: David Henningsson
[mailto:david.henningsson@canonical.com]
> Sent: Thursday, November 05, 2015 5:07 PM > To: Yang, Libin; Takashi Iwai > Cc: Lin, Mengdong; Raymond Yau; airlied@linux.ie; tanuk@iki.fi;
ALSA
> Development Mailing List; Girdwood, Liam R; Lu, Han; Nikula,
Jani
> Subject: Re: [alsa-devel] DP1.2 MST audio support discussion > > > > So I'm asking my question again. What would happen (on Intel
hardware),
> if you stream audio to a converter node on the audio codec, and
there
is
> no pin node connected to that converter node?
I changed the audio driver and did the test today. The test is:
- Pin 5 connect to converter 2 and playback, there is sound from
pin
- Pin 5 connect to converter 2 (no other pin is connected to cvt2),
no
sound.
- Pin 5 connect back to cvt 2, there is sound, playback is normal.
And in step 2, the playback is still ongoing but no sound is out from
any
pin.
Sounds good to me, thanks for testing. Is this workaround
something
we
could utilize in order to not break userspace? (This is a question for both you and Takashi.)
What we'll end up is essentially three types of objects:
- PCM device (5 devices, 3,7,8,9,10)
- all five devices are allocated when the driver initializes
This should be for Intel platform, right? The actually number should be: pin number + device entry number - 1. On intel platform, pin_num = 3, dev_num = 3, so it will be 5.
- all kcontrols are always bound to the PCM device (jack kctl, eld
kctl, iec958 kctls etc)
Sure, I agree on it.
- Monitor (pin + MST index)
- dynamically bound to a PCM at monitor plug-in time, according
to a
scheme that maximises the possibility for a monitor to always end
up at
the same PCM (as specified in earlier emails)
- Converter node (3 nodes for Intel hardware)
- dynamically bound to a PCM at playback open time (regardless
of
whether the PCM has a monitor or not)
If so, we still need use converter on codec. This means we can't turn off the power well in i915.
To save the power, i915 suggests that if no monitor is connected, we should not use the HDMI codec. This means open a PCM with no pin attached will fail. Disconnecting monitor when the
corresponding
PCM is playback will trigger stop PCM.
To help move to the new method smoothly, I will add a flag. User can decide whether to use the aggressive power saving solution or not.
In hdmi_pcm_open(), it will judge whether pin_idx is valid, if not it will return -EINVAL. So for dynamic PCM assignment, open will fail if no monitor is connected.
If we want to support open on PCM without monitor, many code must be rewrited. And it seems open a PCM without monitor is not a good behavior. As Raymond said in previous email, For alt analog playback device , it return EBUSY when DAC of HP is not available. I think for HDMI audio we can have the aligned behavior? And -ENODEV may be better.
Libin, it's why I've been repeated asking to split the patches, instead of posting a big iron patch. Then we can test and evaluate whether this part is really working in general.
Yes, I understand. :) The patches are being split. Suppose these 2 days patches should be ready for review.
Well, you don't have to post full patchset at all. Rather in such a case, a gradual test is preferred. That is, cook this functionality patch(es) quickly, and let people test it. Once after it's confirmed, start working on the rest. It's not worth to wait for a week for each respin because of the size and the features of of the whole patchset.
Takashi
Hi Takashi,
-----Original Message----- From: Takashi Iwai [mailto:tiwai@suse.de] Sent: Wednesday, November 11, 2015 4:27 PM To: Yang, Libin Cc: 'David Henningsson'; Lin, Mengdong; 'Raymond Yau'; 'airlied@linux.ie'; 'tanuk@iki.fi'; 'ALSA Development Mailing List'; Girdwood, Liam R; Lu, Han; Nikula, Jani Subject: Re: [alsa-devel] DP1.2 MST audio support discussion
On Wed, 11 Nov 2015 09:11:49 +0100, Yang, Libin wrote:
Hi Takashi,
-----Original Message----- From: Takashi Iwai [mailto:tiwai@suse.de] Sent: Wednesday, November 11, 2015 4:06 PM To: Yang, Libin Cc: 'David Henningsson'; Lin, Mengdong; 'Raymond Yau';
'airlied@linux.ie';
'tanuk@iki.fi'; 'ALSA Development Mailing List'; Girdwood, Liam R; Lu, Han; Nikula, Jani Subject: Re: [alsa-devel] DP1.2 MST audio support discussion
On Wed, 11 Nov 2015 08:58:29 +0100, Yang, Libin wrote:
-----Original Message----- From: Yang, Libin Sent: Wednesday, November 11, 2015 10:04 AM To: David Henningsson; Takashi Iwai Cc: Lin, Mengdong; Raymond Yau; airlied@linux.ie; tanuk@iki.fi;
ALSA
Development Mailing List; Girdwood, Liam R; Lu, Han; Nikula, Jani Subject: RE: [alsa-devel] DP1.2 MST audio support discussion
-----Original Message----- From: David Henningsson
[mailto:david.henningsson@canonical.com]
Sent: Tuesday, November 10, 2015 3:45 PM To: Yang, Libin; Takashi Iwai Cc: Lin, Mengdong; Raymond Yau; airlied@linux.ie; tanuk@iki.fi;
ALSA
Development Mailing List; Girdwood, Liam R; Lu, Han; Nikula,
Jani
Subject: Re: [alsa-devel] DP1.2 MST audio support discussion
On 2015-11-10 07:46, Yang, Libin wrote: > Hi David, > > >> -----Original Message----- >> From: David Henningsson
[mailto:david.henningsson@canonical.com]
>> Sent: Thursday, November 05, 2015 5:07 PM >> To: Yang, Libin; Takashi Iwai >> Cc: Lin, Mengdong; Raymond Yau; airlied@linux.ie;
tanuk@iki.fi;
ALSA
>> Development Mailing List; Girdwood, Liam R; Lu, Han; Nikula,
Jani
>> Subject: Re: [alsa-devel] DP1.2 MST audio support discussion >> >> >> >> So I'm asking my question again. What would happen (on
Intel
hardware), >> if you stream audio to a converter node on the audio codec,
and
there
is >> no pin node connected to that converter node? > > I changed the audio driver and did the test today. The test is: > 1. Pin 5 connect to converter 2 and playback, there is sound
from
pin
> 2. Pin 5 connect to converter 2 (no other pin is connected to
cvt2),
no
sound. > 3. Pin 5 connect back to cvt 2, there is sound, playback is
normal.
> > And in step 2, the playback is still ongoing but no sound is out
from
any
pin.
Sounds good to me, thanks for testing. Is this workaround
something
we
could utilize in order to not break userspace? (This is a question
for
both you and Takashi.)
What we'll end up is essentially three types of objects:
- PCM device (5 devices, 3,7,8,9,10)
- all five devices are allocated when the driver initializes
This should be for Intel platform, right? The actually number should be: pin number + device entry number - 1. On intel platform, pin_num = 3, dev_num = 3, so it will be 5.
- all kcontrols are always bound to the PCM device (jack kctl,
eld
kctl, iec958 kctls etc)
Sure, I agree on it.
- Monitor (pin + MST index)
- dynamically bound to a PCM at monitor plug-in time,
according
to a
scheme that maximises the possibility for a monitor to always
end
up at
the same PCM (as specified in earlier emails)
- Converter node (3 nodes for Intel hardware)
- dynamically bound to a PCM at playback open time
(regardless
of
whether the PCM has a monitor or not)
If so, we still need use converter on codec. This means we can't
turn
off the power well in i915.
To save the power, i915 suggests that if no monitor is connected, we should not use the HDMI codec. This means open a PCM with no pin attached will fail. Disconnecting monitor when the
corresponding
PCM is playback will trigger stop PCM.
To help move to the new method smoothly, I will add a flag. User can decide whether to use the aggressive power saving solution or not.
In hdmi_pcm_open(), it will judge whether pin_idx is valid, if not it will return -EINVAL. So for dynamic PCM assignment, open will fail if no monitor is connected.
If we want to support open on PCM without monitor, many code must be rewrited. And it seems open a PCM without monitor is not a good behavior. As Raymond said in previous email, For alt analog playback device , it return EBUSY when DAC of HP is not available. I think for HDMI audio we can have the aligned behavior? And -ENODEV may be better.
Libin, it's why I've been repeated asking to split the patches, instead of posting a big iron patch. Then we can test and evaluate whether this part is really working in general.
Yes, I understand. :) The patches are being split. Suppose these 2 days patches should be ready for review.
Well, you don't have to post full patchset at all. Rather in such a case, a gradual test is preferred. That is, cook this functionality patch(es) quickly, and let people test it. Once after it's confirmed, start working on the rest. It's not worth to wait for a week for each respin because of the size and the features of of the whole patchset.
Get it. I will submit the patches if any is ready.
BTW: for the DP MST audio, can we put the patches into a new branch first and wait all patches for MST audio are ready and mature, and then move the patches to master branch?
Takashi
On Wed, 11 Nov 2015 09:33:18 +0100, Yang, Libin wrote:
Hi Takashi,
-----Original Message----- From: Takashi Iwai [mailto:tiwai@suse.de] Sent: Wednesday, November 11, 2015 4:27 PM To: Yang, Libin Cc: 'David Henningsson'; Lin, Mengdong; 'Raymond Yau'; 'airlied@linux.ie'; 'tanuk@iki.fi'; 'ALSA Development Mailing List'; Girdwood, Liam R; Lu, Han; Nikula, Jani Subject: Re: [alsa-devel] DP1.2 MST audio support discussion
On Wed, 11 Nov 2015 09:11:49 +0100, Yang, Libin wrote:
Hi Takashi,
-----Original Message----- From: Takashi Iwai [mailto:tiwai@suse.de] Sent: Wednesday, November 11, 2015 4:06 PM To: Yang, Libin Cc: 'David Henningsson'; Lin, Mengdong; 'Raymond Yau';
'airlied@linux.ie';
'tanuk@iki.fi'; 'ALSA Development Mailing List'; Girdwood, Liam R; Lu, Han; Nikula, Jani Subject: Re: [alsa-devel] DP1.2 MST audio support discussion
On Wed, 11 Nov 2015 08:58:29 +0100, Yang, Libin wrote:
-----Original Message----- From: Yang, Libin Sent: Wednesday, November 11, 2015 10:04 AM To: David Henningsson; Takashi Iwai Cc: Lin, Mengdong; Raymond Yau; airlied@linux.ie; tanuk@iki.fi;
ALSA
Development Mailing List; Girdwood, Liam R; Lu, Han; Nikula, Jani Subject: RE: [alsa-devel] DP1.2 MST audio support discussion
> -----Original Message----- > From: David Henningsson
[mailto:david.henningsson@canonical.com]
> Sent: Tuesday, November 10, 2015 3:45 PM > To: Yang, Libin; Takashi Iwai > Cc: Lin, Mengdong; Raymond Yau; airlied@linux.ie; tanuk@iki.fi;
ALSA
> Development Mailing List; Girdwood, Liam R; Lu, Han; Nikula,
Jani
> Subject: Re: [alsa-devel] DP1.2 MST audio support discussion > > > > On 2015-11-10 07:46, Yang, Libin wrote: > > Hi David, > > > > > >> -----Original Message----- > >> From: David Henningsson [mailto:david.henningsson@canonical.com] > >> Sent: Thursday, November 05, 2015 5:07 PM > >> To: Yang, Libin; Takashi Iwai > >> Cc: Lin, Mengdong; Raymond Yau; airlied@linux.ie;
tanuk@iki.fi;
ALSA > >> Development Mailing List; Girdwood, Liam R; Lu, Han; Nikula,
Jani
> >> Subject: Re: [alsa-devel] DP1.2 MST audio support discussion > >> > >> > >> > >> So I'm asking my question again. What would happen (on
Intel
> hardware), > >> if you stream audio to a converter node on the audio codec,
and
there > is > >> no pin node connected to that converter node? > > > > I changed the audio driver and did the test today. The test is: > > 1. Pin 5 connect to converter 2 and playback, there is sound
from
pin
> > 2. Pin 5 connect to converter 2 (no other pin is connected to
cvt2),
no
> sound. > > 3. Pin 5 connect back to cvt 2, there is sound, playback is
normal.
> > > > And in step 2, the playback is still ongoing but no sound is out
from
any > pin. > > Sounds good to me, thanks for testing. Is this workaround
something
we > could utilize in order to not break userspace? (This is a question
for
> both you and Takashi.) > > What we'll end up is essentially three types of objects: > > * PCM device (5 devices, 3,7,8,9,10) > - all five devices are allocated when the driver initializes
This should be for Intel platform, right? The actually number should be: pin number + device entry number - 1. On intel platform, pin_num = 3, dev_num = 3, so it will be 5.
> - all kcontrols are always bound to the PCM device (jack kctl,
eld
> kctl, iec958 kctls etc)
Sure, I agree on it.
> > * Monitor (pin + MST index) > - dynamically bound to a PCM at monitor plug-in time,
according
to a
> scheme that maximises the possibility for a monitor to always
end
up at
> the same PCM (as specified in earlier emails) > > * Converter node (3 nodes for Intel hardware) > - dynamically bound to a PCM at playback open time
(regardless
of
> whether the PCM has a monitor or not)
If so, we still need use converter on codec. This means we can't
turn
off the power well in i915.
To save the power, i915 suggests that if no monitor is connected, we should not use the HDMI codec. This means open a PCM with no pin attached will fail. Disconnecting monitor when the
corresponding
PCM is playback will trigger stop PCM.
To help move to the new method smoothly, I will add a flag. User can decide whether to use the aggressive power saving solution or not.
In hdmi_pcm_open(), it will judge whether pin_idx is valid, if not it will return -EINVAL. So for dynamic PCM assignment, open will fail if no monitor is connected.
If we want to support open on PCM without monitor, many code must be rewrited. And it seems open a PCM without monitor is not a good behavior. As Raymond said in previous email, For alt analog playback device , it return EBUSY when DAC of HP is not available. I think for HDMI audio we can have the aligned behavior? And -ENODEV may be better.
Libin, it's why I've been repeated asking to split the patches, instead of posting a big iron patch. Then we can test and evaluate whether this part is really working in general.
Yes, I understand. :) The patches are being split. Suppose these 2 days patches should be ready for review.
Well, you don't have to post full patchset at all. Rather in such a case, a gradual test is preferred. That is, cook this functionality patch(es) quickly, and let people test it. Once after it's confirmed, start working on the rest. It's not worth to wait for a week for each respin because of the size and the features of of the whole patchset.
Get it. I will submit the patches if any is ready.
BTW: for the DP MST audio, can we put the patches into a new branch first and wait all patches for MST audio are ready and mature, and then move the patches to master branch?
On my tree? It's fine, but it means that the patches aren't tested by linux-next. Or if you have your own git tree and it's published, you can keep the changes there, instead.
Takashi
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/mixe...
Why do we use "hdmi" when MST is only supported by Display Port ?
https://bugs.freedesktop.org/show_bug.cgi?id=72795#c56
It seem the graphic driver use different name for HDMI and DP
DP1-1 , DP1-2 and DP1-3 , HDMI1
-----Original Message----- From: Raymond Yau [mailto:superquad.vortex2@gmail.com] Sent: Friday, October 23, 2015 5:40 PM
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/mixe...
Why do we use "hdmi" when MST is only supported by Display Port ? https://bugs.freedesktop.org/show_bug.cgi?id=72795#c56 It seem the graphic driver use different name for HDMI and DP DP1-1 , DP1-2 and DP1-3 , HDMI1
Maybe I cannot give the best answer.
I feel there can be two reasons: - HDMI came to the market earlier than DP. So the name "hdmi" is used at first. - For GFX, the difference between HDMI and DP processing sequence is big. But for audio, there is little difference. In audio driver, DP and HDMI pins are handled in the same way, probably the only difference is the audio infoframe format. And this reflects the HW: audio codec is only a GPU interface to feed audio data to its display pipelines. And GPU mixes the audio and video and translate the stream to different formats for HDMI and DP.
Thanks Mengdong
Please check the attachment for details.
Regards, Libin
-----Original Message----- From: Yang, Libin Sent: Tuesday, October 13, 2015 2:26 PM To: 'Takashi Iwai'; Lin, Mengdong; tanuk@iki.fi; David Henningsson; Girdwood, Liam R Cc: alsa-devel@alsa-project.org; airlied@linux.ie Subject: DP1.2 MST audio support discussion
Hi Takashi and all,
We are planning to enable DP1.2 MST (Multi-Stream Transport) audio.
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.
- 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.
I'm not sure how to notify the userspace, such as notifying pulseaudio the PCM is assigned or de-assigned. Any ideas?
- 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.
Regards, Libin
participants (6)
-
David Henningsson -
Jani Nikula -
Lin, Mengdong -
Raymond Yau -
Takashi Iwai -
Yang, Libin