On Thu, 2010-07-08 at 18:23 +0200, Tim Blechmann wrote: > >> on my workstation, i am running pulseaudio with jack as backend. however, > >> i have some troubles with this setup. i have two audio devices on this > >> machine, the onboard audio chip of the soundcard and an rme hdsp > >> (pci+multiface). > >> > >> when the multiface is not connected, the whole computer reacts very > >> slowly. like i click on a menu and it takes something like 10 seconds for > >> the dropdown menu to appear. i suppose, pulseaudio tries to start jack, > >> but doesn't succeed, because it cannot open the hdsp device ... > > > > How did you figure out that the slowdown is caused by Pulseaudio trying > > to start Jack? > > when i start jack, the machine doesn't show any hickups ... > > > >> i am not sure, what is the best way to handle this use case, but it took > >> me quite some time to figure out, that the odd desktop behavior is > >> related to pulseaudio trying to launch jack ... maybe it is possible to > >> switch the pulseaudio backend to the null backend, if jack cannot be > >> launched? > > > > AFAIK Jack autostarting happens in jack_client_open(), which we do not > > run in a loop. Instead, if it fails, the jack module loading fails. When > > that happens, it depends on the PA configuration what, if anything, will > > be used as fallback. In the default configuration a null sink is loaded > > by module-always-sink if nothing else is available. > > not sure, but i suspect, that exactly that is not happening ... how would a > configuration look like in that case? Fallback to the null sink is done simply by loading module-always-sink. (It's probably important to load it *after* any other modules that can create sinks.) > i have the default ubuntu > configuration with the addition of this: > > load-module module-jack-source > load-module module-jack-sink If that is an accurate description of your configuration, that is, all you've done is that you've added those two lines, then your configuration is broken. (Still, no system slowdown should happen.) You don't want to load both module-udev-detect and the jack modules, because if you do, Pulseaudio and Jack will fight for the Alsa devices. To get forward with finding the real issue causing the slowdown, could you get a log of Pulseaudio startup? This is how to do that: 1. Put "autospawn = no" in ~/.pulse/client.conf (the autospawn feature tends to cause pulseaudio to be started in the background immediately after killing the previous instance). 2. Run "pulseaudio -k" (that stops the currently running pulseaudio instance). 3. Run "pulseaudio -vvvv > pulse.log 2>&1" in a terminal. 4. After a while, say 10 seconds, hit ctrl-C in the terminal where you started pulseaudio. Hmmm... Now it popped to my mind that maybe it's the autospawn feature that is causing the slowdown: if you have module-udev-detect loaded, loading the jack modules probably fails, and if they are in such a place in the configuration that module load failure is considered fatal, then the pulseaudio startup fails. The autospawn feature will then immediately start pulseaudio again, and again it fails, etc... So, before anything else, could you do just the step 1 described above, and see if that helps? Now that I think some more, the problem should appear regardless of whether the RME card is connected or not, because module-udev-detect should cause all sound cards to become inaccessible to jack (unless you have configured pulseaudio to ignore the RME card, or unless pulseaudio fails to open the RME card, which might actually be the case - pulseaudio has had problems with some pro audio cards before). Anyway, I hope this incoherent mail contains something that you can use to learn more about the issue. -- Tanu Kaskinen
