> On Fri, Mar 7, 2008 at 2:37 PM, Marc-Olivier Barre
> <[hidden email]> wrote:
>> On Fri, Mar 7, 2008 at 6:58 PM, Paul Davis
>> <[hidden email]> wrote:
>>> On Fri, 2008-03-07 at 12:31 -0500, Lee Revell wrote:
>>>> On Fri, Mar 7, 2008 at 2:04 PM, Esben Stien <b0ef@esben-
>>>> stien.name> wrote:
>>>>> Is there a reason why real time is not default?
>>>> Most systems will not do real time as a normal user out of the box.
>>>> If you make it the default you'll just have even more users
>>>> asking on
>>>> IRC why JACK will not start at all.
>>> damn, i should keep my mouth shut again. lee is right. jackd
>>> will fail
>>> to start if -R is requested but not available. is this true for
>> Wait !
>> Isn't *that* what is supposed to change ? wouldn't that be user
>> experience ? instead of simply failing, why not test (ulimit -r) if
>> the user can run realtime and cleanly fallback to non-realtime if
>> not available (with some kind of notification of course)
> The original problem was that the user explicitly requested -R, but
> jackd decided to run anyway if permissions were inadequate. It was
> easy to miss the error message at startup time and not notice that
> the permissions were the problem.
> The current behavior could be retained when given and explicit -R
> but relaxed for the default. In effect, the default would be changed
> from "non-realtime" to "realtime if possible".
> That seems like a good idea to me. We might want to add and
> explicity "non-realtime" option to request the current default