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

[Kaskinen, Tanu]

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.

I also wonder about compatibility between various combinations of
kernel, alsa-lib and PA versions. An old kernel doesn't have dynamic PCM
devices, and doesn't know about the HDMI PCM class. An old alsa-lib
doesn't support the SYSDEV parameter, and doesn't know about the HDMI
PCM class. An old PA version will only use the old-style "hdmi:x,y"
device strings, and won't check the PCM class. There are 8 cases:

1: old kernel, old alsa-lib, old PA: No chance for regressions.

2: old kernel, old alsa-lib, new PA: The old alsa-lib version won't
report the PCM class correctly. This can be handled by falling back to
the old PA behaviour when an old alsa-lib version is detected at PA
build time.

3: old kernel, new alsa-lib, old PA: No chance for regressions.

4: old kernel, new alsa-lib, new PA: The old kernel won't report the PCM
class correctly. How should this be handled? Should PA do kernel version
checking, and fall back to the old behaviour with old kernels?

5: new kernel, old alsa-lib, old PA: Do the kernel changes cause
regressions on hardware that used to work, or do the changes only affect
new hardware that has never worked?

6: new kernel, old alsa-lib, new PA: If PA uses the fallback strategy
described in case 2, then this is equivalent to case 5.

7: new kernel, new alsa-lib, old PA: Equivalent to case 5.

8: new kernel, new alsa-lib, new PA: Everything works perfectly.

-- 
Tanu