[alsa-devel] Dynamic HDMI PCM creation
Hi David,
as we discussed at Plumbers, I tried some hack to create/delete HDMI/DP PCM stream per hotplug/unplug. Test patches are found in sound-unstable git tree topic/hdmi-dynamic-pcm branch git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-unstable.git
The patches are all small and easy, but it's still in a pretty rough cut. It won't handle some cases, e.g. unplug during suspend, or such, I'm afraid. After all, it's just a test.
With these patches, the PCM device appears and disappears properly upon HDMI/DP hotplug/unplug on my system. On mine, it appears as /dev/snd/pcmC0D8 as it's an Intel on-board. So far, so good.
Now the problem is that PA gets confused when this happens. It can switch to HDMI/DP, but then the analog output disappears from PA's profile. You cannot switch back to analog output after that, even after you unplug HDMI/DP cable.
Or, it might be my PA version... I'll check newer one. But it'd be good if you also check in your side.
thanks,
Takashi
On 09/10/2012 03:01 PM, Takashi Iwai wrote:
Hi David,
as we discussed at Plumbers, I tried some hack to create/delete HDMI/DP PCM stream per hotplug/unplug. Test patches are found in sound-unstable git tree topic/hdmi-dynamic-pcm branch git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-unstable.git
The patches are all small and easy, but it's still in a pretty rough cut. It won't handle some cases, e.g. unplug during suspend, or such, I'm afraid. After all, it's just a test.
With these patches, the PCM device appears and disappears properly upon HDMI/DP hotplug/unplug on my system. On mine, it appears as /dev/snd/pcmC0D8 as it's an Intel on-board. So far, so good.
Now the problem is that PA gets confused when this happens. It can switch to HDMI/DP, but then the analog output disappears from PA's profile. You cannot switch back to analog output after that, even after you unplug HDMI/DP cable.
Or, it might be my PA version... I'll check newer one. But it'd be good if you also check in your side.
Hmm.
As you probably know, PA does extensively test opening device strings at startup, and then never again. As such, I can understand that PA gets confused if you start adding and removing PCM devices, because that changes whether and how different device strings can be opened.
Looking forward, with HDMI, it's a reality that this will happen. And therefore we need to deal with it in PA somehow, even if this is non-trivial. So the first question would be - what notification mechanism should we have to trigger "reprobing"? Are we recommended to use the jack detection kcontrol API, or is there something else that tells us that suddenly "hdmi:1,2" will actually be worth trying again?
At Mon, 17 Sep 2012 12:15:23 +0200, David Henningsson wrote:
On 09/10/2012 03:01 PM, Takashi Iwai wrote:
Hi David,
as we discussed at Plumbers, I tried some hack to create/delete HDMI/DP PCM stream per hotplug/unplug. Test patches are found in sound-unstable git tree topic/hdmi-dynamic-pcm branch git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-unstable.git
The patches are all small and easy, but it's still in a pretty rough cut. It won't handle some cases, e.g. unplug during suspend, or such, I'm afraid. After all, it's just a test.
With these patches, the PCM device appears and disappears properly upon HDMI/DP hotplug/unplug on my system. On mine, it appears as /dev/snd/pcmC0D8 as it's an Intel on-board. So far, so good.
Now the problem is that PA gets confused when this happens. It can switch to HDMI/DP, but then the analog output disappears from PA's profile. You cannot switch back to analog output after that, even after you unplug HDMI/DP cable.
Or, it might be my PA version... I'll check newer one. But it'd be good if you also check in your side.
Hmm.
As you probably know, PA does extensively test opening device strings at startup, and then never again. As such, I can understand that PA gets confused if you start adding and removing PCM devices, because that changes whether and how different device strings can be opened.
Looking forward, with HDMI, it's a reality that this will happen. And therefore we need to deal with it in PA somehow, even if this is non-trivial. So the first question would be - what notification mechanism should we have to trigger "reprobing"? Are we recommended to use the jack detection kcontrol API, or is there something else that tells us that suddenly "hdmi:1,2" will actually be worth trying again?
The kcontrol API is already implemented, so it's good to support for it.
If we do check the dynamic PCM probing for HDMI, I'd propose for adding a new PCM class SNDRV_PCM_CLASS_HDMI or such, and set this class in patch_hdmi.c. Then PA can check the sysfs entry and decide whether to reprobe the HDMI entry.
Takashi
Date 17.9.2012 12:40, Takashi Iwai wrote:
At Mon, 17 Sep 2012 12:15:23 +0200, David Henningsson wrote:
On 09/10/2012 03:01 PM, Takashi Iwai wrote:
Hi David,
as we discussed at Plumbers, I tried some hack to create/delete HDMI/DP PCM stream per hotplug/unplug. Test patches are found in sound-unstable git tree topic/hdmi-dynamic-pcm branch git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-unstable.git
The patches are all small and easy, but it's still in a pretty rough cut. It won't handle some cases, e.g. unplug during suspend, or such, I'm afraid. After all, it's just a test.
With these patches, the PCM device appears and disappears properly upon HDMI/DP hotplug/unplug on my system. On mine, it appears as /dev/snd/pcmC0D8 as it's an Intel on-board. So far, so good.
Now the problem is that PA gets confused when this happens. It can switch to HDMI/DP, but then the analog output disappears from PA's profile. You cannot switch back to analog output after that, even after you unplug HDMI/DP cable.
Or, it might be my PA version... I'll check newer one. But it'd be good if you also check in your side.
Hmm.
As you probably know, PA does extensively test opening device strings at startup, and then never again. As such, I can understand that PA gets confused if you start adding and removing PCM devices, because that changes whether and how different device strings can be opened.
Looking forward, with HDMI, it's a reality that this will happen. And therefore we need to deal with it in PA somehow, even if this is non-trivial. So the first question would be - what notification mechanism should we have to trigger "reprobing"? Are we recommended to use the jack detection kcontrol API, or is there something else that tells us that suddenly "hdmi:1,2" will actually be worth trying again?
The kcontrol API is already implemented, so it's good to support for it.
You refer ELD interface?
If we do check the dynamic PCM probing for HDMI, I'd propose for adding a new PCM class SNDRV_PCM_CLASS_HDMI or such, and set this
I'm not sure if HDMI devices are different than others. For example, for digital S/PDIF inputs, the input stream parameters can change too including the signal presence. It would be good to propose one mechanism for all plug-and-play wiring schemas.
class in patch_hdmi.c. Then PA can check the sysfs entry and decide whether to reprobe the HDMI entry.
Please, could you describe more, why we need to have dynamic PCMs for HDMI? I would prefer to have just a notification, if the cable is connected and the PCM layer is ready (ELD stuff). Also, if some physical connectors are not used on some hardware, they should/may be blacklisted so the driver won't create PCM devices for them.
Also, the stream parameter checks seems missing in the HDMI PCM implementation. It may be good to fail with -EIO when the cable is not connected or unplugged and, eventually, if the end-point PCM parameters are changed.
If the dynamic HDMI PCMs are implemented, are the device numbers fixed (related) to physical connectors?
Thanks, Jaroslav
At Mon, 17 Sep 2012 13:03:56 +0200, Jaroslav Kysela wrote:
Date 17.9.2012 12:40, Takashi Iwai wrote:
At Mon, 17 Sep 2012 12:15:23 +0200, David Henningsson wrote:
On 09/10/2012 03:01 PM, Takashi Iwai wrote:
Hi David,
as we discussed at Plumbers, I tried some hack to create/delete HDMI/DP PCM stream per hotplug/unplug. Test patches are found in sound-unstable git tree topic/hdmi-dynamic-pcm branch git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-unstable.git
The patches are all small and easy, but it's still in a pretty rough cut. It won't handle some cases, e.g. unplug during suspend, or such, I'm afraid. After all, it's just a test.
With these patches, the PCM device appears and disappears properly upon HDMI/DP hotplug/unplug on my system. On mine, it appears as /dev/snd/pcmC0D8 as it's an Intel on-board. So far, so good.
Now the problem is that PA gets confused when this happens. It can switch to HDMI/DP, but then the analog output disappears from PA's profile. You cannot switch back to analog output after that, even after you unplug HDMI/DP cable.
Or, it might be my PA version... I'll check newer one. But it'd be good if you also check in your side.
Hmm.
As you probably know, PA does extensively test opening device strings at startup, and then never again. As such, I can understand that PA gets confused if you start adding and removing PCM devices, because that changes whether and how different device strings can be opened.
Looking forward, with HDMI, it's a reality that this will happen. And therefore we need to deal with it in PA somehow, even if this is non-trivial. So the first question would be - what notification mechanism should we have to trigger "reprobing"? Are we recommended to use the jack detection kcontrol API, or is there something else that tells us that suddenly "hdmi:1,2" will actually be worth trying again?
The kcontrol API is already implemented, so it's good to support for it.
You refer ELD interface?
No, the jack detection kcontrols.
If we do check the dynamic PCM probing for HDMI, I'd propose for adding a new PCM class SNDRV_PCM_CLASS_HDMI or such, and set this
I'm not sure if HDMI devices are different than others. For example, for digital S/PDIF inputs, the input stream parameters can change too including the signal presence. It would be good to propose one mechanism for all plug-and-play wiring schemas.
In that case, it's fine. PA has no special treatment for such devices. (Or, it might face the same problem when it's listed as "spdif".)
From what I've seen, there is no big issue in the driver side at all about dynamic creation/deletion of PCM streams. All the problem is about PA, and PA _is_ the reason we need a better hotplug PCM handling. So, you cannot think of any solution without considering how PA would behave.
class in patch_hdmi.c. Then PA can check the sysfs entry and decide whether to reprobe the HDMI entry.
Please, could you describe more, why we need to have dynamic PCMs for HDMI?
It's not about "have to". It's a possible solution for feasible HDMI hotplug handling we've discussed since the last year's audio BoF. As the same topic came up in Plumbers, I stated the patch just as a proof-of-concept.
I would prefer to have just a notification, if the cable is connected and the PCM layer is ready (ELD stuff). Also, if some physical connectors are not used on some hardware, they should/may be blacklisted so the driver won't create PCM devices for them.
Using kcontrol notifier is the current solution indeed. But the whole coding is missing in PA side, so far. OTOH, PA has already the handling of dynamic PCM device creation/deletion (e.g. for USB-audio). So, it can be more natural to provide the dynamic PCM from the kernel for HDMI, too. The patch was posted to evaluate that.
Also, the stream parameter checks seems missing in the HDMI PCM implementation. It may be good to fail with -EIO when the cable is not connected or unplugged and, eventually, if the end-point PCM parameters are changed.
Well, then PA will face a similar problem like this patch. PA probes the available HDMI devices at start up. If the device returns an error -EIO at open when unplugged, PA will continue to ignore the device. It's what I understand. I might be wrong about that in the recent PA versions, though.
If the dynamic HDMI PCMs are implemented, are the device numbers fixed (related) to physical connectors?
In my patch, it's still fixed. Just creation is delayed and the slot is kept. But it's just my patch, and it doesn't correlate directly with the idea of dynamic creation/deletion of PCM devices.
Takashi
Date 17.9.2012 13:46, Takashi Iwai wrote:
At Mon, 17 Sep 2012 13:03:56 +0200, Jaroslav Kysela wrote:
Date 17.9.2012 12:40, Takashi Iwai wrote:
At Mon, 17 Sep 2012 12:15:23 +0200, David Henningsson wrote:
On 09/10/2012 03:01 PM, Takashi Iwai wrote:
Hi David,
as we discussed at Plumbers, I tried some hack to create/delete HDMI/DP PCM stream per hotplug/unplug. Test patches are found in sound-unstable git tree topic/hdmi-dynamic-pcm branch git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-unstable.git
The patches are all small and easy, but it's still in a pretty rough cut. It won't handle some cases, e.g. unplug during suspend, or such, I'm afraid. After all, it's just a test.
With these patches, the PCM device appears and disappears properly upon HDMI/DP hotplug/unplug on my system. On mine, it appears as /dev/snd/pcmC0D8 as it's an Intel on-board. So far, so good.
Now the problem is that PA gets confused when this happens. It can switch to HDMI/DP, but then the analog output disappears from PA's profile. You cannot switch back to analog output after that, even after you unplug HDMI/DP cable.
Or, it might be my PA version... I'll check newer one. But it'd be good if you also check in your side.
Hmm.
As you probably know, PA does extensively test opening device strings at startup, and then never again. As such, I can understand that PA gets confused if you start adding and removing PCM devices, because that changes whether and how different device strings can be opened.
Looking forward, with HDMI, it's a reality that this will happen. And therefore we need to deal with it in PA somehow, even if this is non-trivial. So the first question would be - what notification mechanism should we have to trigger "reprobing"? Are we recommended to use the jack detection kcontrol API, or is there something else that tells us that suddenly "hdmi:1,2" will actually be worth trying again?
The kcontrol API is already implemented, so it's good to support for it.
You refer ELD interface?
No, the jack detection kcontrols.
Yep, ok.
If we do check the dynamic PCM probing for HDMI, I'd propose for adding a new PCM class SNDRV_PCM_CLASS_HDMI or such, and set this
I'm not sure if HDMI devices are different than others. For example, for digital S/PDIF inputs, the input stream parameters can change too including the signal presence. It would be good to propose one mechanism for all plug-and-play wiring schemas.
In that case, it's fine. PA has no special treatment for such devices. (Or, it might face the same problem when it's listed as "spdif".)
From what I've seen, there is no big issue in the driver side at all about dynamic creation/deletion of PCM streams. All the problem is about PA, and PA _is_ the reason we need a better hotplug PCM handling. So, you cannot think of any solution without considering how PA would behave.
I believe we should do it in one consistent way. The kctl wire status report / jack presence report should be sufficient to detect, if the PCM device can be re-probed. I don't understand why to do more work in the driver, because the user space application is broken or lacking a feature.
class in patch_hdmi.c. Then PA can check the sysfs entry and decide whether to reprobe the HDMI entry.
Please, could you describe more, why we need to have dynamic PCMs for HDMI?
It's not about "have to". It's a possible solution for feasible HDMI hotplug handling we've discussed since the last year's audio BoF. As the same topic came up in Plumbers, I stated the patch just as a proof-of-concept.
I would prefer to have just a notification, if the cable is connected and the PCM layer is ready (ELD stuff). Also, if some physical connectors are not used on some hardware, they should/may be blacklisted so the driver won't create PCM devices for them.
Using kcontrol notifier is the current solution indeed. But the whole coding is missing in PA side, so far. OTOH, PA has already the handling of dynamic PCM device creation/deletion (e.g. for USB-audio). So, it can be more natural to provide the dynamic PCM from the kernel for HDMI, too. The patch was posted to evaluate that.
I think that USB-Audio is a different thing. Our driver creates new card for a newly plugged USB hardware and it seems that PA supports only dynamic card handling, not dynamic device handling.
Also, the stream parameter checks seems missing in the HDMI PCM implementation. It may be good to fail with -EIO when the cable is not connected or unplugged and, eventually, if the end-point PCM parameters are changed.
Well, then PA will face a similar problem like this patch. PA probes the available HDMI devices at start up. If the device returns an error -EIO at open when unplugged, PA will continue to ignore the device. It's what I understand. I might be wrong about that in the recent PA versions, though.
I believe that PA should be fixed. For me, it seems unlogical to feed a stream to hardware which is silent, because the stream parameters do not match or the wire is not connected.
If the dynamic HDMI PCMs are implemented, are the device numbers fixed (related) to physical connectors?
In my patch, it's still fixed. Just creation is delayed and the slot is kept. But it's just my patch, and it doesn't correlate directly with the idea of dynamic creation/deletion of PCM devices.
OK, fine.
Jaroslav
[added pulseaudio-discuss to cc]
On 09/17/2012 02:20 PM, Jaroslav Kysela wrote:
Date 17.9.2012 13:46, Takashi Iwai wrote:
I would prefer to have just a notification, if the cable is connected and the PCM layer is ready (ELD stuff). Also, if some physical connectors are not used on some hardware, they should/may be blacklisted so the driver won't create PCM devices for them.
It might be that we could send a snd_ctl_notify on the ELD kcontrol. Would that make sense?
Using kcontrol notifier is the current solution indeed. But the whole coding is missing in PA side, so far. OTOH, PA has already the handling of dynamic PCM device creation/deletion (e.g. for USB-audio). So, it can be more natural to provide the dynamic PCM from the kernel for HDMI, too. The patch was posted to evaluate that.
I think that USB-Audio is a different thing. Our driver creates new card for a newly plugged USB hardware and it seems that PA supports only dynamic card handling, not dynamic device handling.
This is correct. PA supports dynamic cards, not dynamic devices on a card. Cards are much simpler because they are always independent of each other.
Another question PA needs to deal with is, when this new HDMI PCM device is plugged in, what other streams can coexist with this new HDMI stream? What if we have an analog + HDMI combined card, but the controller only supports one stream to either of them? In that case, we can not even probe the HDMI device without disturbing the stream potentially being played back through analog.
Brainstorming idea for PA developers: However, if combined analog + HDMI combined cards *always* can play back HDMI and analog independent of each other, we could actually try to map them as two different cards in PulseAudio. Then that HDMI card could disappear as the HDMI cable is unplugged.
Another question PA needs to deal with is, when this new HDMI PCM device
is plugged in, what other streams can coexist with this new HDMI stream? What if we have an analog + HDMI combined card, but the controller only supports one stream to either of them? In that case, we can not even probe the HDMI device without disturbing the stream potentially being played back through analog.
Refer to ICH8 datasheet
Independent Bus Master logic for eight general purpose streams: four input and four output Support four external Codecs
does it mean that for those hda codecs which support two independent spdif , the driver can be configured to support two spdif device instead of slaves ?
e.g. alc1200
Node 0x11 [Pin Complex] wcaps 0x400300: Mono Digital Pincap 0x00000010: OUT Pin Default 0x99430140: [Fixed] SPDIF Out at Int ATAPI Conn = ATAPI, Color = Unknown DefAssociation = 0x4, Sequence = 0x0 Misc = NO_PRESENCE Pin-ctls: 0x40: OUT Connection: 1 0x10
Node 0x1e [Pin Complex] wcaps 0x400300: Mono Digital Pincap 0x00000010: OUT Pin Default 0x01456130: [Jack] SPDIF Out at Ext Rear Conn = Optical, Color = Orange DefAssociation = 0x3, Sequence = 0x0 Misc = NO_PRESENCE Pin-ctls: 0x40: OUT Connection: 1 0x06
http://git.kernel.org/?p=linux/kernel/git/tiwai/sound.git;a=commit;h=6a05ac4...
http://git.kernel.org/?p=linux/kernel/git/tiwai/sound.git;a=commit;h=0852d7a...
The other case is audio codec and hdmi codec with NVidia controller
can the hda controller support more than two streams?
**** List of PLAYBACK Hardware Devices **** card 0: NVidia [HDA NVidia], device 0: AD198x Analog [AD198x Analog] Subdevices: 0/1 Subdevice #0: subdevice #0 card 0: NVidia [HDA NVidia], device 1: AD198x Digital [AD198x Digital] Subdevices: 1/1 Subdevice #0: subdevice #0 card 0: NVidia [HDA NVidia], device 3: HDMI 0 [HDMI 0] Subdevices: 1/1 Subdevice #0: subdevice #0
On 09/10/2012 03:01 PM, Takashi Iwai wrote:
Hi David,
as we discussed at Plumbers, I tried some hack to create/delete HDMI/DP PCM stream per hotplug/unplug. Test patches are found in sound-unstable git tree topic/hdmi-dynamic-pcm branch git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-unstable.git
The patches are all small and easy, but it's still in a pretty rough cut. It won't handle some cases, e.g. unplug during suspend, or such, I'm afraid. After all, it's just a test.
With these patches, the PCM device appears and disappears properly upon HDMI/DP hotplug/unplug on my system. On mine, it appears as /dev/snd/pcmC0D8 as it's an Intel on-board. So far, so good.
Now the problem is that PA gets confused when this happens. It can switch to HDMI/DP, but then the analog output disappears from PA's profile. You cannot switch back to analog output after that, even after you unplug HDMI/DP cable.
Or, it might be my PA version... I'll check newer one.
Which PA version are you testing with?
But it'd be good if you also check in your side.
Trying to figure out what's happening here - could you give the output of "pacmd list" both before and after things go wrong, as well as a more detailed instruction of what you do in what order?
It seems very strange that a profile would disappear during a card's lifetime, so probably it's something different happening.
Also; just to clarify - by default PulseAudio only tries one output + one input during its probing, which means that if you have a card which has both analog and HDMI outputs, by default it does not support simultaneous output to both. As such it seems that "cannot switch back to analog output" is the troublesome point here, so exactly how are you trying to switch back, and do you get an error message?
participants (4)
-
David Henningsson -
Jaroslav Kysela -
Raymond Yau -
Takashi Iwai