On 02/14/2012 08:31 PM, Brian Monroe wrote:
I've been spending a lot of time on the #opensourcemusicians
talking to Ubuntu Studio users about their kernel and latency times
they're getting. Seems like most of them are using g a stock kernel with
the preemptive option enabled and they are getting great latency results
(2ms)while utilizing the @audio group on their user. I ended up
compiling my own low latency kernel and I haven't had any issues with it
yet. If this is what we are missing for the spin I'd be happy to
maintain packaging for the kernel. I know ccrma has been behind a few
Latency times are really relative things based on many factors. Have you
been getting better latency times than ta
Currently 3.2.2-1.rt10.1 is in CCRMA testing (which is only one behind
upstream which I believe Fernando has already started working on)
The patches are taken from here:
I saw the instructions for adding the real time patch for a tick less
kernel and from what I can tell it wouldn't be hard to get that rolling
I'm not entirely sure what ccrma does differently with their kernels
compared to other Linux users, and I'm still a bit of a noob so I could
be off base with this, but I would reason that we should be able to just
utilize the same settings to archive similar performance enhancements.
That question might be better directed towards CCRMA.
I haven't got that far yet but I would imagine that any kernel shipped
with a Fedora endorsed spin would have to be generated by the kernel
team (ie, from the Fedora build system). Having said that, latency times
achieved using the stock kernels w/threadirqs and our standard jack
limits.conf are more than sufficient for most users.
I thought I read that ccrma uses a unique scheduler, but if we could
a 2ms latency time without it, the point may be moot.