[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 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. 

> 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 ?

Liam