Device creation order

Device creation order

[Lennart Poettering]

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

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net         ICQ# 11060553
http://0pointer.net/lennart/           GnuPG 0x1A015CC4

Re: Device creation order

[Jaroslav Kysela]

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.

Re: Device creation order

[Daniel Mack]

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

Re: Device creation order

[Jaroslav Kysela]

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.

Re: Device creation order

[Daniel Mack]

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

Re: Device creation order

[Colin Guthrie]

'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.html

-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
   Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
   Mandriva Linux Contributor [http://www.mandriva.com/]
   PulseAudio Hacker [http://www.pulseaudio.org/]
   Trac Hacker [http://trac.edgewall.org/]

Re: Device creation order

[Lennart Poettering]

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

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net         ICQ# 11060553
http://0pointer.net/lennart/           GnuPG 0x1A015CC4

Re: Device creation order

[Lennart Poettering]

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

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net         ICQ# 11060553
http://0pointer.net/lennart/           GnuPG 0x1A015CC4

Re: Device creation order

[Clemens Ladisch]

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

Re: Device creation order

[Jaroslav Kysela]

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.

Re: Device creation order

[Lennart Poettering]

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

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net         ICQ# 11060553
http://0pointer.net/lennart/           GnuPG 0x1A015CC4

Re: Device creation order

[Lennart Poettering]

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:
> 1) 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...

> 2) 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

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net         ICQ# 11060553
http://0pointer.net/lennart/           GnuPG 0x1A015CC4

Re: Device creation order

[Wu Fengguang]

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:
> > 1) 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...
> 
> > 2) 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

Re: Device creation order

[Lennart Poettering]

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

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net         ICQ# 11060553
http://0pointer.net/lennart/           GnuPG 0x1A015CC4

Re: Device creation order

[Mark Brown]

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.

Re: Device creation order

[Lennart Poettering]

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

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net         ICQ# 11060553
http://0pointer.net/lennart/           GnuPG 0x1A015CC4