On 11/26/2010 01:49 PM, Takashi Iwai wrote:
At Tue, 23 Nov 2010 20:16:52 +0200,
Dave Plater wrote:
On 11/23/2010 04:16 PM, Ludwig Nussel wrote:
Dave Plater wrote:
On 11/22/2010 04:25 PM, Ludwig Nussel wrote:
>> This is stated at http://jackaudio.org/faq
and I didn't have sound from
>> jack without it, I've had those lines for a while. Obviously the user
>> has to be a member of the audio group. I'm looking for a macro to
> I'd veto such abuse of the audio group. The jack daemon needs to be started
> with appropriate privileges, ie either by a supervising root process or via
As jack is started and run as user, how would you propose to grant jack
real time scheduling?
Just as cited above :-) Either some root process needs to start jackd as
intended user with the necessary privileges (e.g. via DBus) or you need to make
jackd setuid root/grant fscaps. If jackd isn't prepared to run that way you
could also write a small wrapper for that purpose. In any case the security
team wants to review such things prior to inclusion in Factory.
Ok I'm beginning to understand what jack dbus is all about,
unfortunately most packages that use jack still depend on jack classic
and although jack can build with both interfaces it does so with a
warning and although it works when I test it, I don't trust it. I will
research the various options, making a jack that just works is on my
todo list but not that urgent.
The approach using limits.conf is some how compromise for easiness
and reliability in the past. Before that, a wrapper approach was
taken. You can find some codes in jack 0.9.x.
When only concerning about usability, adding these limits
automatically is the easiest option, of course. But, this will most
likely anger security guys :)
Using rtkit would be a good option
This looks promising, I'll look into it.
, especially for JACK2, I guess.
I haven't followed the recent development, so I have no idea whether
this is being discussed / implemented, though. Other than that, I'd
say to keep the thing as is, and provide a good documentation, at
least, README.SUSE or such, for informing users this small bit.
Adding two lines manually isn't too difficult, and user should know
the risk as well by that.
Ok then a compromise is using echo "instructions" in %post, is this
I should imagine that jack dbus overcomes this hurdle but it will take a
while for the applications that use jack to use it.
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org