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

[Liam Girdwood]

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. 

Liam