From: Daniel Mack <daniel@caiaq.de>
To: Jaroslav Kysela <perex@perex.cz>
Cc: ALSA Development Mailing List <alsa-devel@alsa-project.org>,
Lennart Poettering <mznyfn@0pointer.de>
Subject: Re: Device creation order
Date: Fri, 3 Apr 2009 09:20:30 +0200 [thread overview]
Message-ID: <20090403072030.GB15466@buzzloop.caiaq.de> (raw)
In-Reply-To: <alpine.LNX.2.00.0904030904160.17368@eeebox2.perex-int.cz>
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
next prev parent reply other threads:[~2009-04-03 7:20 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-04-03 1:54 Device creation order Lennart Poettering
2009-04-03 7:12 ` Jaroslav Kysela
2009-04-03 7:20 ` Daniel Mack [this message]
2009-04-03 7:31 ` Jaroslav Kysela
2009-04-03 7:40 ` Daniel Mack
2009-04-03 10:34 ` Colin Guthrie
2009-04-03 11:51 ` Lennart Poettering
2009-04-03 11:43 ` Lennart Poettering
2009-04-03 7:38 ` Clemens Ladisch
2009-04-03 7:50 ` Jaroslav Kysela
2009-04-03 11:58 ` Lennart Poettering
2009-04-03 11:56 ` Lennart Poettering
2009-04-05 13:16 ` Wu Fengguang
2009-04-05 14:40 ` Lennart Poettering
2009-04-05 20:29 ` Mark Brown
2009-04-03 11:42 ` Lennart Poettering
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20090403072030.GB15466@buzzloop.caiaq.de \
--to=daniel@caiaq.de \
--cc=alsa-devel@alsa-project.org \
--cc=mznyfn@0pointer.de \
--cc=perex@perex.cz \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.