On 02/23/2011 06:24 PM, Daniel Poelzleithner wrote:
On 02/23/2011 11:10 AM, Olivier Guilyardi wrote:
The dynamic cgroups solution seems good.
On Android there basically is one priviledged and trusted audio process,
audioflinger, the sound server, which performs mixing and access the
On Fri, Feb 25, 2011 at 10:23 AM, Olivier Guilyardi l...@samalyse.com wrote:
But let's take JACK for example. It handles setting up realtime scheduling
transparently when one creates a jack client. There isn't any extra step
necessary. As a supposition, could you imagine that ulatencyd
On 02/25/2011 04:53 PM, Olivier Guilyardi wrote:
Wouldn't this be an improvement in regard to security?
About this, security really doesn't seem like a pointless question to me.
Otherwise, why would all major distributions grant absolutely no realtime
privileges/runtime by default? Reading the
On Fri, Feb 25, 2011 at 10:53 AM, Olivier Guilyardi l...@samalyse.com wrote:
Let's now consider that clients runs as user(s) which do not have realtime
privileges by default, but that it's JACK which grant them such privileges and
assign them a certain CPU time share dynamically. In this
On Fri, Feb 25, 2011 at 11:31 AM, Olivier Guilyardi l...@samalyse.com wrote:
On 02/25/2011 04:53 PM, Olivier Guilyardi wrote:
Wouldn't this be an improvement in regard to security?
About this, security really doesn't seem like a pointless question to me.
Otherwise, why would all major
On 02/25/2011 05:33 PM, Paul Davis wrote:
the point is that both OS X and contemporary linux have mechanisms
that prevent RT scheduling from locking up the system.
linux distributions have not adapted to this reality and thus they
still continue to make RT scheduling inaccessible to users
On Fri, Feb 25, 2011 at 11:49 AM, Olivier Guilyardi l...@samalyse.com wrote:
In these circumstances, maybe that a JACK specific solution could make sense.
It
would only need jackd to run as a privileged user (I don't mean root). Maybe
that this would make its way into major distributions
Hello Robin,
On 02/23/2011 08:28 PM, Robin Gareus wrote:
On 02/23/2011 11:22 AM, Olivier Guilyardi wrote:
Hi,
On 02/17/2011 10:53 PM, Robin Gareus wrote:
/proc/sys/kernel/sched_rt_runtime_us
/proc/sys/kernel/sched_rt_period_us
kernel-source/Documentation/scheduler/sched-rt-group.txt
On 02/24/2011 03:59 PM, Olivier Guilyardi wrote:
Hello Robin,
Now, say I'm only focusing on playback now. Is there something wrong with
calling a blocking output API from a realtime thread as I ask below?
mmh. it depends on how the blocking is done. If it is a spin-lock it
will consume CPU
On 02/24/2011 07:01 PM, Robin Gareus wrote:
On 02/24/2011 03:59 PM, Olivier Guilyardi wrote:
Hello Robin,
Now, say I'm only focusing on playback now. Is there something wrong with
calling a blocking output API from a realtime thread as I ask below?
mmh. it depends on how the blocking is
Hello Daniel,
thanks for sharing your experience.
On 02/18/2011 02:43 PM, Daniel Poelzleithner wrote:
On 02/17/2011 09:40 PM, Olivier Guilyardi wrote:
I have written a dynamic system optimizer for linux called ulatencyd. I
stumbled more by accident over rt issues my self. I use dynamic
On 02/23/2011 11:10 AM, Olivier Guilyardi wrote:
The dynamic cgroups solution seems good.
On Android there basically is one priviledged and trusted audio process,
audioflinger, the sound server, which performs mixing and access the hardware.
All audio clients are untrusted. I think there is
On 02/23/2011 11:22 AM, Olivier Guilyardi wrote:
Hi,
On 02/17/2011 10:53 PM, Robin Gareus wrote:
/proc/sys/kernel/sched_rt_runtime_us
/proc/sys/kernel/sched_rt_period_us
kernel-source/Documentation/scheduler/sched-rt-group.txt
There's something which confuses me. But I'm not sure how
On Thu, Feb 17, 2011 at 10:04:31PM +, Fons Adriaensen wrote:
On Thu, Feb 17, 2011 at 10:53:54PM +0100, Robin Gareus wrote:
/proc/sys/kernel/sched_rt_runtime_us
/proc/sys/kernel/sched_rt_period_us
I've been told than on OSX, when a process runs in realtime, it is only
allowed
On 02/17/2011 11:04 PM, Fons Adriaensen wrote:
On Thu, Feb 17, 2011 at 10:53:54PM +0100, Robin Gareus wrote:
/proc/sys/kernel/sched_rt_runtime_us
/proc/sys/kernel/sched_rt_period_us
I've been told than on OSX, when a process runs in realtime, it is only
allowed
to use a certain ratio of
Paul Davis:
On Thu, Feb 17, 2011 at 4:53 PM, Robin Gareus ro...@gareus.org wrote:
Aside of that, what about locks? I've many times been told that one mustn't do
anything that could block in a realtime thread. What are the consequences of
that? Could a malicious app freeze the system by
On 02/17/2011 09:40 PM, Olivier Guilyardi wrote:
The one thing about Android is that it has a strict security model. Every app
is
considered potentially harmful and is thus sandboxed. Here, this for example
means that apps can lower their threads priority, but not increase it. And of
course
Hi everyone,
I am currently spending a lot of time working on Android, and on the andraudio
mailing list [1] we are discussing about possible improvements to the internal
Android audio system. Currently, latencies are very high, over 100ms, and we're
looking for ways to improve the situation.
In
On Thu, Feb 17, 2011 at 3:40 PM, Olivier Guilyardi l...@samalyse.com wrote:
Or is there some other ways to achieve this? Some kernel patch maybe?
in earlier versions of 2.6, the kernel patch to allow SCHED_FIFO for
everyone was incredibly simple. i recall kjetil posting a couple of
lines, at
On 02/17/2011 09:48 PM, Paul Davis wrote:
On Thu, Feb 17, 2011 at 3:40 PM, Olivier Guilyardi l...@samalyse.com wrote:
in earlier versions of 2.6, the kernel patch to allow SCHED_FIFO for
everyone was incredibly simple. i recall kjetil posting a couple of
lines, at most.
whether this a
On 02/17/2011 10:27 PM, Olivier Guilyardi wrote:
On 02/17/2011 09:48 PM, Paul Davis wrote:
On Thu, Feb 17, 2011 at 3:40 PM, Olivier Guilyardi l...@samalyse.com wrote:
in earlier versions of 2.6, the kernel patch to allow SCHED_FIFO for
everyone was incredibly simple. i recall kjetil posting a
On Thu, Feb 17, 2011 at 10:53:54PM +0100, Robin Gareus wrote:
/proc/sys/kernel/sched_rt_runtime_us
/proc/sys/kernel/sched_rt_period_us
I've been told than on OSX, when a process runs in realtime, it is only
allowed
to use a certain ratio of CPU time. And if it goes over this limit, it
22 matches
Mail list logo
