[pulseaudio-discuss] pulseaudio jack issue

[Tanu Kaskinen]

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