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 _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
