[pulseaudio-discuss] Wait on sound cards before starting PA, and stream routing

[Colin Guthrie]

'Twas brillig, and David Henningsson at 16/08/10 20:38 did gyre and gimble:
> We had a problem with PA a few days ago which I analyzed as the following:
> 
> PA started up for the first time, i e without a .pulse directory.
> 
> Due to racy startup conditions (we're all trying to boot up as quick as
> possible nowadays), sometimes the start order was as follows:
>   1) Sound card #2 was probed and announced from the kernel
>   2) PA was started up and found sound card #2
>   3) Some client or module asked for the fallback/default device
>   4) Since there was no current default device, it was auto-set to sound
> card #2
>   5) Sound card #1 was probed and announced from the kernel, but was not
> selected as default - even if the priority was higher, since the default
> had already been set.
> 
> My workaround was to write a simple wait-on-file-access module that
> waited for /dev/snd/controlC0 and /dev/snd/controlC1 before continuing,
> and then I placed that one on the top of /etc/pulse/default.pa for this
> particular hardware. I found it the least ugly workaround at the time,
> and should upstream be interested in merging this module, I'd be happy
> to prepare a git patch for either master or stable-queue as you see fit.
> 
> The long-term solution - and this is more my own thoughts than an
> official standpoint from Canonical - probably would include writing
> something that takes on the entire problem of deciding stream routing,
> because now we have many modules which all try to solve their piece of
> the puzzle, but instead end up shooting each other's feet.
> I know Colin have done a lot of work in this area already (thank you
> Colin!), and so Colin, it would be nice to have a little status update:
>   - Did the implementation turn out the same way you described in your
> February blog post?
>   - Is this ready for testing in pulseaudio git master?
>   - What remains until this is ready for everyday usage?

Well I've not had much time to make practical progress. Primarily
because I couldn't finish off the discussions regarding it with Lennart.
There are still several threads hanging on the list that really need his
input, but due to systemd distractions he's not had time lately.

I didn't want to start any solid implementations if the general concept
was not acceptable to Lennart.

I still believe that personally the approach I outlined is a valid one
and the right way forward, with the only significant problem being no
longer able to move an individual stream from a given application to a
different device than all other streams of that application (that's not
strictly true, but I wont go into the details right now (mainly because
I've forgotten them and I'd need to look up the mail archive :D) - but
it's easily mitigated at the application level for those few apps that
need multiple independent streams via the use of proper role tagging or
by setting a different identifier for that particular stream). Overall
it's no more a limitation than currently where a track-change or some
other tear-down/recreation of the sink-input would result in an
unwanted/unexpected device change (i.e. it's broken now anyway, but in a
different way that *appears* to work at first glance, but will fail at
some point in the future anyway).

But the proposal was quite different to how things work now and I really
do need to sit down with Lennart and ensure that it's going to be
accepted before I (or anyone else) crack on with the implementation. The
last comment I think Lennart made on the topic was still referring to
the stream-restore-id property which was something that was factored out
completely, so really need to make sure that point is understood
properly before we can discuss further.

Lennart, if you're able to set aside a couple hours or so for such a
discussions please let me know and we can schedule in a time when we're
both available?


Going back to your specific problem, it sounds like it would indeed be
solved/worked around by the approach I outlined, so it probably is the
right way forward. I don't really expect the implementation to take all
that long once the principles of operation are agreed upon.

Hope that helps.

Col

-- 

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/]