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