[alsa-devel] Device creation order
Heya!
PulseAudio listens for hotplugged audio devices via hal/udev. For each card ALSA creates a bunch of device nodes in /dev. Before PA can open the card it needs to make sure that all devices nodes of the card got properly created. I.e. to make sure that surround sound and SPDIF works it is not sufficient to wait until one PCM device is available, but instead that *all* devices that belong to the card are available, i.e. device nodes created with permissions and ACLs set up correctly. Unfortunately there is no signal from udev/hal/kernel that would tell me explicitly that all subdevices of a specific devices are completely enumerated and device files created for. I have been discussing this a bit with Kay Sievers and we came to the conclusion that a simple fix would be if we could rely that the control (i.e. /dev/snd/controlCxx) device is always the last device to be created for a card.
Looking at the drivers this seems to be generally the case, so I was wondering if I can rely on this? Do all drivers behave like this? Do all drivers expose a control device? Can we officially declare it part of the userspace API that the control device is the last one to be created?
Lennart
On Fri, 3 Apr 2009, Lennart Poettering wrote:
Heya!
PulseAudio listens for hotplugged audio devices via hal/udev. For each card ALSA creates a bunch of device nodes in /dev. Before PA can open the card it needs to make sure that all devices nodes of the card got properly created. I.e. to make sure that surround sound and SPDIF works it is not sufficient to wait until one PCM device is available, but instead that *all* devices that belong to the card are available, i.e. device nodes created with permissions and ACLs set up correctly. Unfortunately there is no signal from udev/hal/kernel that would tell me explicitly that all subdevices of a specific devices are completely enumerated and device files created for. I have been discussing this a bit with Kay Sievers and we came to the conclusion that a simple fix would be if we could rely that the control (i.e. /dev/snd/controlCxx) device is always the last device to be created for a card.
Looking at the drivers this seems to be generally the case, so I was wondering if I can rely on this? Do all drivers behave like this? Do all drivers expose a control device? Can we officially declare it part of the userspace API that the control device is the last one to be created?
Unfortunately, driver may use more complex scenarios like:
- some hardware requires additional firmware - in this case devices might be created, but they are not useable until firmware is loaded - dynamic device creation at runtime - for example we have an experimental HDA driver configuration code which might change the arrangement of PCM devices on request from the user space
I would suggest to wait awhile with some small timeout (0.5 sec?) for all devices to get the usual static arrangement working and handle extra dynamic cases, too.
Jaroslav
----- Jaroslav Kysela perex@perex.cz Linux Kernel Sound Maintainer ALSA Project, Red Hat, Inc.
On Fri, Apr 03, 2009 at 09:12:34AM +0200, Jaroslav Kysela wrote:
PulseAudio listens for hotplugged audio devices via hal/udev. For each card ALSA creates a bunch of device nodes in /dev. Before PA can open the card it needs to make sure that all devices nodes of the card got properly created. I.e. to make sure that surround sound and SPDIF works it is not sufficient to wait until one PCM device is available, but instead that *all* devices that belong to the card are available, i.e. device nodes created with permissions and ACLs set up correctly. Unfortunately there is no signal from udev/hal/kernel that would tell me explicitly that all subdevices of a specific devices are completely enumerated and device files created for. I have been discussing this a bit with Kay Sievers and we came to the conclusion that a simple fix would be if we could rely that the control (i.e. /dev/snd/controlCxx) device is always the last device to be created for a card.
Looking at the drivers this seems to be generally the case, so I was wondering if I can rely on this? Do all drivers behave like this? Do all drivers expose a control device? Can we officially declare it part of the userspace API that the control device is the last one to be created?
Unfortunately, driver may use more complex scenarios like:
- some hardware requires additional firmware - in this case devices might be created, but they are not useable until firmware is loaded
- dynamic device creation at runtime - for example we have an experimental HDA driver configuration code which might change the arrangement of PCM devices on request from the user space
I would suggest to wait awhile with some small timeout (0.5 sec?) for all devices to get the usual static arrangement working and handle extra dynamic cases, too.
Wouldn't the real fix be to make sure that the event from hal/udev happens after all the initialization has finished, i.e. the device got its firmware, all connected layers finished their work etc? Before all that, the audio device is not really available, right?
Daniel
On Fri, 3 Apr 2009, Daniel Mack wrote:
On Fri, Apr 03, 2009 at 09:12:34AM +0200, Jaroslav Kysela wrote:
PulseAudio listens for hotplugged audio devices via hal/udev. For each card ALSA creates a bunch of device nodes in /dev. Before PA can open the card it needs to make sure that all devices nodes of the card got properly created. I.e. to make sure that surround sound and SPDIF works it is not sufficient to wait until one PCM device is available, but instead that *all* devices that belong to the card are available, i.e. device nodes created with permissions and ACLs set up correctly. Unfortunately there is no signal from udev/hal/kernel that would tell me explicitly that all subdevices of a specific devices are completely enumerated and device files created for. I have been discussing this a bit with Kay Sievers and we came to the conclusion that a simple fix would be if we could rely that the control (i.e. /dev/snd/controlCxx) device is always the last device to be created for a card.
Looking at the drivers this seems to be generally the case, so I was wondering if I can rely on this? Do all drivers behave like this? Do all drivers expose a control device? Can we officially declare it part of the userspace API that the control device is the last one to be created?
Unfortunately, driver may use more complex scenarios like:
- some hardware requires additional firmware - in this case devices might be created, but they are not useable until firmware is loaded
- dynamic device creation at runtime - for example we have an experimental HDA driver configuration code which might change the arrangement of PCM devices on request from the user space
I would suggest to wait awhile with some small timeout (0.5 sec?) for all devices to get the usual static arrangement working and handle extra dynamic cases, too.
Wouldn't the real fix be to make sure that the event from hal/udev happens after all the initialization has finished, i.e. the device got its firmware, all connected layers finished their work etc? Before all that, the audio device is not really available, right?
But even with this extension, the user space should handle dynamic device reconfiguration (my second example case). The question is, if it makes sense to handle group of devices per card basis or just take single devices and dynamically handle device changes.
Lennart, why you need to enumerate all devices per card at one time? I think that having mixer access plus one PCM device is enough for minimal configuration for PA.
Jaroslav
----- Jaroslav Kysela perex@perex.cz Linux Kernel Sound Maintainer ALSA Project, Red Hat, Inc.
On Fri, Apr 03, 2009 at 09:31:40AM +0200, Jaroslav Kysela wrote:
Unfortunately, driver may use more complex scenarios like:
- some hardware requires additional firmware - in this case devices might be created, but they are not useable until firmware is loaded
- dynamic device creation at runtime - for example we have an experimental HDA driver configuration code which might change the arrangement of PCM devices on request from the user space
I would suggest to wait awhile with some small timeout (0.5 sec?) for all devices to get the usual static arrangement working and handle extra dynamic cases, too.
Wouldn't the real fix be to make sure that the event from hal/udev happens after all the initialization has finished, i.e. the device got its firmware, all connected layers finished their work etc? Before all that, the audio device is not really available, right?
But even with this extension, the user space should handle dynamic device reconfiguration (my second example case). The question is, if it makes sense to handle group of devices per card basis or just take single devices and dynamically handle device changes.
That's another issue IMO, which needs different attention. Signaling audio devices being added (via udev) before it's actually usable is rather a bug than a missing extension, wouldn't you say?
Daniel
'Twas brillig, and Jaroslav Kysela at 03/04/09 08:31 did gyre and gimble:
Lennart, why you need to enumerate all devices per card at one time? I think that having mixer access plus one PCM device is enough for minimal configuration for PA.
PA now has a concept of "cards". The hal-detect module will load the module-alsa-card module which in turn will probe the "card" in question to see what it supports.
As alsa does not export information such as what parts of the card can be used concurrently, the module-alsa-card has to be able to probe e.g. 5.1 output + stereo input to see if it works. From this probing, we can build up a list of "Card Profiles" so we can let the user pick their configuration[1] they want. When a user changes configuration, it will take care of loading the individual module-alsa-sink and module-alsa-source modules for dealing with the actual output/input.
Hope that explains why the whole card is needed rather than just a single PCM.
Col
See: http://colin.guthr.ie/development/configuring-card-profiles-in-pulseaudio.ht...
On Fri, 03.04.09 09:31, Jaroslav Kysela (perex@perex.cz) wrote:
I would suggest to wait awhile with some small timeout (0.5 sec?) for all devices to get the usual static arrangement working and handle extra dynamic cases, too.
Wouldn't the real fix be to make sure that the event from hal/udev happens after all the initialization has finished, i.e. the device got its firmware, all connected layers finished their work etc? Before all that, the audio device is not really available, right?
But even with this extension, the user space should handle dynamic device reconfiguration (my second example case). The question is, if it makes sense to handle group of devices per card basis or just take single devices and dynamically handle device changes.
Lennart, why you need to enumerate all devices per card at one time? I think that having mixer access plus one PCM device is enough for minimal configuration for PA.
PA has no clue how the different PCM device nodes of a card relate to each other. To my knowledge Creative cards have multiple PCM device nodes that are combined in userspace via 'multi' to make one surround device. When PA wants to open that we need to make sure that all PCM devices that are necessary for that are fully created. Since we have no clue how the PCM devices relate to each other we have no other option than to wait for all PCM devices.
Also, as Colin noted we probe a few possible combinations of how we can open the audio device to know which combinations the sound card supports. It's a bit ugly and slow but the only option right now since the name hinting API is too limited for this since it does not tell us which devices can be used simultaneously and which ones are exclusive.
Lennart
On Fri, 03.04.09 09:20, Daniel Mack (daniel@caiaq.de) wrote:
Unfortunately, driver may use more complex scenarios like:
- some hardware requires additional firmware - in this case devices might be created, but they are not useable until firmware is loaded
- dynamic device creation at runtime - for example we have an experimental HDA driver configuration code which might change the arrangement of PCM devices on request from the user space
I would suggest to wait awhile with some small timeout (0.5 sec?) for all devices to get the usual static arrangement working and handle extra dynamic cases, too.
Wouldn't the real fix be to make sure that the event from hal/udev happens after all the initialization has finished, i.e. the device got its firmware, all connected layers finished their work etc? Before all that, the audio device is not really available, right?
But still, we'd need some kind of 'end marker' to know when all devices are set up properly. Just delaying the device creation events and then triggering them all at once doesn't really fix the entire issue.
Lennart
Jaroslav Kysela wrote:
Unfortunately, driver may use more complex scenarios like:
- some hardware requires additional firmware - in this case devices might be created, but they are not useable until firmware is loaded
This is only true for drivers that load firmware with a hwdep device instead of using request_firmware(). Is there any driver that has not yet been converted? *grep* ... except usx2y?
- dynamic device creation at runtime - for example we have an experimental HDA driver configuration code which might change the arrangement of PCM devices on request from the user space
I would suggest to wait awhile with some small timeout (0.5 sec?) for all devices to get the usual static arrangement working and handle extra dynamic cases, too.
The current implementation of the ALSA framework guarantees that the control device file is that latest one to be created for all the devices created at initialization. Any devices created later depend on some userspace action, so a small timeout won't help in this case.
In other words: 1) When the control device file has been created, all other devices (that are created during sound card initialization) are available. 2) When some device file for a specific sound card is created after the card's control device, the sound card configuration has changed.
Best regards, Clemens
On Fri, 3 Apr 2009, Clemens Ladisch wrote:
Jaroslav Kysela wrote:
Unfortunately, driver may use more complex scenarios like:
- some hardware requires additional firmware - in this case devices might be created, but they are not useable until firmware is loaded
This is only true for drivers that load firmware with a hwdep device instead of using request_firmware(). Is there any driver that has not yet been converted? *grep* ... except usx2y?
Good point.
- dynamic device creation at runtime - for example we have an experimental HDA driver configuration code which might change the arrangement of PCM devices on request from the user space
I would suggest to wait awhile with some small timeout (0.5 sec?) for all devices to get the usual static arrangement working and handle extra dynamic cases, too.
The current implementation of the ALSA framework guarantees that the control device file is that latest one to be created for all the devices created at initialization. Any devices created later depend on some userspace action, so a small timeout won't help in this case.
The timeout might help to let alsactl utility to initialize the soundcard's mixer. But I agree that alsactl should send a HAL message that initial setting was done instead.
Jaroslav
----- Jaroslav Kysela perex@perex.cz Linux Kernel Sound Maintainer ALSA Project, Red Hat, Inc.
On Fri, 03.04.09 09:50, Jaroslav Kysela (perex@perex.cz) wrote:
- dynamic device creation at runtime - for example we have an experimental HDA driver configuration code which might change the arrangement of PCM devices on request from the user space
I would suggest to wait awhile with some small timeout (0.5 sec?) for all devices to get the usual static arrangement working and handle extra dynamic cases, too.
The current implementation of the ALSA framework guarantees that the control device file is that latest one to be created for all the devices created at initialization. Any devices created later depend on some userspace action, so a small timeout won't help in this case.
The timeout might help to let alsactl utility to initialize the soundcard's mixer. But I agree that alsactl should send a HAL message that initial setting was done instead.
This is not an issue AFAICS. udev will run alsactl and only *after* that finished forward the device creation events to HAL and then PA.
Lennart
On Fri, 03.04.09 09:38, Clemens Ladisch (clemens@ladisch.de) wrote:
- dynamic device creation at runtime - for example we have an experimental HDA driver configuration code which might change the arrangement of PCM devices on request from the user space
I would suggest to wait awhile with some small timeout (0.5 sec?) for all devices to get the usual static arrangement working and handle extra dynamic cases, too.
The current implementation of the ALSA framework guarantees that the control device file is that latest one to be created for all the devices created at initialization. Any devices created later depend on some userspace action, so a small timeout won't help in this case.
In other words:
- When the control device file has been created, all other devices (that are created during sound card initialization) are available.
OK. Very good. I'll then change PA to rely on this behaviour and hope that this is considered part of the ALSA userspace API and is not changed in the future...
- When some device file for a specific sound card is created after the card's control device, the sound card configuration has changed.
I'll ignore this for now since Jaroslav mentioned drivers doing this are still experimental. But eventually we'd need to know some kind of 'end notification' for this as well: i..e if the reconfiguration causes multiple device nodes to disappear/appear we also need to know when they are all complete. A possible simple fix would be to issue an udev 'change' event on the control device after the reconfiguration finished.
Lennart
On Fri, Apr 03, 2009 at 01:56:47PM +0200, Lennart Poettering wrote:
On Fri, 03.04.09 09:38, Clemens Ladisch (clemens@ladisch.de) wrote:
- dynamic device creation at runtime - for example we have an experimental HDA driver configuration code which might change the arrangement of PCM devices on request from the user space
I would suggest to wait awhile with some small timeout (0.5 sec?) for all devices to get the usual static arrangement working and handle extra dynamic cases, too.
The current implementation of the ALSA framework guarantees that the control device file is that latest one to be created for all the devices created at initialization. Any devices created later depend on some userspace action, so a small timeout won't help in this case.
In other words:
- When the control device file has been created, all other devices (that are created during sound card initialization) are available.
OK. Very good. I'll then change PA to rely on this behaviour and hope that this is considered part of the ALSA userspace API and is not changed in the future...
- When some device file for a specific sound card is created after the card's control device, the sound card configuration has changed.
I'll ignore this for now since Jaroslav mentioned drivers doing this are still experimental. But eventually we'd need to know some kind of 'end notification' for this as well: i..e if the reconfiguration causes multiple device nodes to disappear/appear we also need to know when they are all complete. A possible simple fix would be to issue an udev 'change' event on the control device after the reconfiguration finished.
btw, HDMI sink devices could be taught to generate more event types:
- hotplug The user connected/disconnected a HDMI device.
- reconfiguration The update of HDMI audio capabilities due to some user actions.
- pause/play of audio stream An advanced feature in Consumer Electronics Control (CEC) for high-level user control of HDMI-connected devices.
The HDMI audio devices will be created at module loading time, and won't be dynamically created/tear down on hotplug events. I wonder if PA is interested in the HDMI current-connectivity state?
Thanks, Fengguang
On Sun, 05.04.09 21:16, Wu Fengguang (fengguang.wu@intel.com) wrote:
I'll ignore this for now since Jaroslav mentioned drivers doing this are still experimental. But eventually we'd need to know some kind of 'end notification' for this as well: i..e if the reconfiguration causes multiple device nodes to disappear/appear we also need to know when they are all complete. A possible simple fix would be to issue an udev 'change' event on the control device after the reconfiguration finished.
btw, HDMI sink devices could be taught to generate more event types:
- hotplug The user connected/disconnected a HDMI device.
Wouldn't that overlap with the jack sensing API?
reconfiguration The update of HDMI audio capabilities due to some user actions.
pause/play of audio stream An advanced feature in Consumer Electronics Control (CEC) for high-level user control of HDMI-connected devices.
What would these be?
The HDMI audio devices will be created at module loading time, and won't be dynamically created/tear down on hotplug events. I wonder if PA is interested in the HDMI current-connectivity state?
Yes, we certainly are. I am not entirely sure though how to best expose this.
Lennart
On Sun, Apr 05, 2009 at 04:40:42PM +0200, Lennart Poettering wrote:
On Sun, 05.04.09 21:16, Wu Fengguang (fengguang.wu@intel.com) wrote:
- hotplug The user connected/disconnected a HDMI device.
Wouldn't that overlap with the jack sensing API?
Yes, although given that AIUI the HDMI port will be able to communicate with the connected device it may make more sense to expose the connected device to user space as what it is, or to do both.
On Fri, 03.04.09 09:12, Jaroslav Kysela (perex@perex.cz) wrote:
- dynamic device creation at runtime - for example we have an experimental HDA driver configuration code which might change the arrangement of PCM devices on request from the user space
Hmm, this could be handled by issueing a 'change' event on the control device after all those changes have been applied.
I would suggest to wait awhile with some small timeout (0.5 sec?) for all devices to get the usual static arrangement working and handle extra dynamic cases, too.
We used to do this. But it's ugly. If the system is loaded .5s might not be enough. We managed to get rid of all those waits for hotplugged USB sticks and everyone is enjoying it. I think it is equally advisable to do the same for audio devices.
Lennart
participants (7)
-
Clemens Ladisch -
Colin Guthrie -
Daniel Mack -
Jaroslav Kysela -
Lennart Poettering -
Mark Brown -
Wu Fengguang