[alsa-devel] [Intel-gfx] [PATCH 3/4] snd: add support for displayport multi-stream to hda codec.

[Kaskinen, Tanu]

On Thu, 2015-06-25 at 10:44 +0100, Liam Girdwood wrote:
> On Wed, 2015-06-24 at 20:47 +0000, Kaskinen, Tanu wrote:
> > On Wed, 2015-06-24 at 14:06 +0100, Liam Girdwood wrote:
> > > On Wed, 2015-06-24 at 12:41 +0000, Kaskinen, Tanu wrote:
> > > > On Tue, 2015-06-23 at 10:06 +0200, Takashi Iwai wrote:
> > > > > At Tue, 23 Jun 2015 07:51:22 +0000,
> > > > > Kaskinen, Tanu wrote:
> > > > > > 
> > > > > > (Added pulseaudio-discuss to CC.)
> > > > > > 
> > > > > > On Mon, 2015-06-22 at 17:44 +0200, Takashi Iwai wrote:
> > > > > > > At Mon, 22 Jun 2015 15:21:16 +0000,
> > > > > > > Kaskinen, Tanu wrote:
> > > > > > > > 
> > > > > > > > On Mon, 2015-06-22 at 14:29 +0100, Liam Girdwood wrote:
> > > > 
> > > > <snip>
> > > > 
> > > > > > > > > Tanu, what's your take on the effort for dynamically created PCMs
> > > > > > > > > support for pulseaudio ?
> > > > > > > > 
> > > > > > > > It's a significant amount of work, but I think PulseAudio should be
> > > > > > > > improved to support this in any case, if other approaches make life
> > > > > > > > miserable for driver developers.
> > > > > > > > 
> > > > > > > > What would be the interface for getting notifications about new and
> > > > > > > > removed PCM devices? udev?
> > > > > > > 
> > > > > > > In general, yes.
> > > > > > > 
> > > > > > > > PulseAudio (mostly) doesn't use the hw:X devices directly. Instead, it
> > > > > > > > uses logical names like "front", "hdmi", "iec958", etc. Speaking of HDMI
> > > > > > > > specifically, PulseAudio uses devices from "hdmi:X,0" to "hdmi:X,7".
> > > > > > > > With this new dynamic PCM system, do these logical names still work?
> > > > > > > 
> > > > > > > Unfortunately, this doesn't work for HDA as is, because of the
> > > > > > > terribly arcane secret.  For keeping the compatibility with the old
> > > > > > > config, there is a static mapping of the hdmi:x,y and hw:x,z.
> > > > > > > 
> > > > > > > Maybe we should introduce a new device class for dynamic HDMI/DP
> > > > > > > device, something like dhdmi:x,y, to make things straightforward.
> > > > > > > (Just a concept -- I'm not good at naming.)
> > > > > > > 
> > > > > > > Alternatively, we may introduce a new argument to hdmi PCM to access
> > > > > > > like "hdmi:CARD=x,SYSDEV=y".
> > > > > > 
> > > > > > What happens if PulseAudio tries to open "dhdmi:x,y" or
> > > > > > "hdmi:CARD=x,SYSDEV=y", when y points to a non-HDMI device? If it fails,
> > > > > > then PulseAudio can replace its current "hdmi:x,[0-7]" devices with
> > > > > > "hdmi:CARD=X,SYSDEV=[0-13]" and blindly try every hw PCM device. But if
> > > > > > opening a non-HDMI device through "hdmi:CARD=x,SYSDEV=y" succeeds, then
> > > > > > how is PulseAudio supposed to know which hw PCM devices are HDMI
> > > > > > devices?
> > > > > 
> > > > > It's a good question.  I think this is the core part of the missing
> > > > > pieces.
> > > > > 
> > > > > What I have in my mind is to extend SNDRV_PCM_CLASS_* definition for
> > > > > dedicated to HDMI/DP, e.g. SNDRV_PCM_CLASS_HDMI.  The difference
> > > > > between DP and HDMI can be specified in subclass optionally.
> > > > 
> > > > Sounds good. Knowing the difference between HDMI, DisplayPort and
> > > > Thunderbolt would be very nice too. It would enable better labelling in
> > > > UIs.
> > > > 
> > > > I have one minor concern, though: what if a PCM device isn't statically
> > > > assigned to one output connector? Is it possible that some DSP is able
> > > > to dynamically change the PCM routing between different outputs? In
> > > > those cases the PCM class would be useless information (unless there are
> > > > notifications when the class changes). I don't have any better ideas,
> > > > though.
> > > > 
> > > 
> > > This is possible atm, we can route from one PCM to multiple outputs
> > > depending on DSP and codec mixer settings. The outputs can even be on
> > > different physical interfaces. 
> > 
> > Hmm, my question was a bit silly. It has been possible forever to switch
> > between e.g. headphones and speakers using just the mixer. And in this
> > case that we're discussing, the question was irrelevant anyway, because
> > surely the dynamically created PCM would be dedicated to the plugged-in
> > HDMI port, otherwise the dynamic creation wouldn't really make sense.
> > So, setting the PCM class should work at least in this case.
> > 
> > If there are cases where the DSP may route the same PCM to either HDMI
> > or non-HDMI output depending on mixer settings, then that's when the PCM
> > class would be less useful.
> > 
> 
> Yeah, we may need to provide other hints here. DSPs make it possible now
> to route one PCM to multiple HW endpoints. 

Getting information to userspace about the hw endpoints and how each hw
PCM and the endpoints are related would probably also solve this dynamic
HDMI PCM issue, but it would probably be much more complicated than just
adding a couple of bits to the PCM info. I suggest that we leave the
dynamically routed PCM problem alone for now, and only focus on the
dynamic HDMI PCM issue, even if that means that we devise a solution for
the HDMI PCM issue that will become obsolete later.

> > In any case, PulseAudio needs to figure out whether it should ignore the
> > PCM class and use "hdmi:x,y" or whether it should check the PCM class
> > and use "hdmi:CARD=x,SYSDEV=y". How should that be done? Is checking the
> > kernel (and alsa-lib) version a good approach, or is some other
> > mechanism needed? Checking the versions should work, if all HDMI audio
> > drivers start to set the PCM class at the same time, but if some drivers
> > set it and some don't, then version checking isn't a reliable solution.
> 
> struct snd_pcm_info does have some reserved space (64 bytes currently
> set as 0) that could be used to differentiate and provide information on
> the PCM ?

Yes, snd_pcm_info could have e.g. a version field. If the version is 0,
then PulseAudio should handle HDMI devices as before (blindly try
"hdmi:x,[0-7]"), and if it's 1, then PulseAudio should check the PCM
class, and use "hdmi:CARD=x,SYSDEV=y" if the class is HDMI.

-- 
Tanu