Am 25.04.2013 20:57, schrieb david:
I have found a hint now, that though pulseaudio is not directly
responsible, something that comes from the pulse-package *could* be
Here we have the ghastly ReserverDevice1 thing.
As I read this, the problem is caused by 2 things:
1.) the priority of the process, that tries to start Jack is lower than
the one that has a grip upon the device at startup. How this priority is
exactly set I do not know, I have raised the realtime-priority for Jack
from 10 to 66 - simply this is the only whatever priority I see a way to
2.) Lennart Poettering recommends to spawn a usefull message that could
help the user to find out, what is happening:
Optionally the owner of the device access may export a few
172 properties with a bit of descriptive information about
173 itself. This is supposed to be useful to show a nice message
174 to the user: "Application %s is blocking device %s. Please
175 close this application or make sure it closes the access to
176 that device." with ApplicationName and ApplicationDeviceName
177 filled in.
whoever is in charge have chosen just to spawn:
"A handler is already registered"
which have made me search for about 3 days now only to find the
And still I am far from a sane solution....
best regards and thank you all for your help.
Linux-audio-user mailing list