Btw, some OS`s boost threads. Threads that can occupy some time, but seconds sounds quite odd though.
Check if there are any threads set to realtime etc.
I am just going to ignore your comment on 1000hz.
Lol. Not Average. FYI the kernel can go to ca 4000hz. And ofcourse it can easily be extended. Con has also done that. But when you want to do that nowadays I am not sure. Turn on tickless and be happy.
This is a kernelconfig for 0.33 ms latency. http://www.paradoxuncreated.com/tmp/.config39
Tested to work with intel dual-core, decent mobo, and firewire audio-card. Professional sound in other words.
And Nvidia gfx.. All the nice h/w one would want.
If you have lame-ass mobochip sound, that doesn`t seem to work with that low latencies. Maybe lazy policies in the driverwriting department, since it has been reduced from almost working at 1ms to, to almost working at 0.5, where before it did not work at all at 0.5ms.
And how do you know you're getting 0.33ms? I can setup JACK for 0.167ms with BFS (16 FP, 192kHz, 2 P/B) and it works without a glitch. But it does not mean that this is the latency you actually get!
(And this would be ridiculous anyway; 8ms is more than enough for any audio work.)
You remind me of this guy: http://www.youtube.com/watch?v=foS84bEZSO4
This generic kernel would not perform as well as the same kernel using the BFS patch set (not on either of my Core2duo's, not on my AMD Phenom II 965 x4, and i doubt it would on my i7 ~ although that machine is newer, and i haven't/won't test it). 2.6.39 was just before linux-rt-3.0 came out. For the entire time between 2.6.33-rt and 3.0.1-rt -> i was using BFS kernels, as i had some hardware that didn't play nice with 2.6.33-rt - and subsequently ended up using BFS on all my systems, because it worked noticably betterthan CFS on the same kernel, during that period. On all machines (using 2.6.39, when it came out) BFS ran smoother / more stable & reliably for proaudio then CFS, and that's with using the 'threaded irq' boot parameter, that had been merged into mainline 2.6.39, from the -rt patches ... I tested this quite a bit at the time.Code:
# Automatically generated make config: don't edit
# Linux/x86_64 2.6.39 Kernel Configuration
# Sat May 21 00:45:30 2011
I currently use RT-kernels, but BFS is definitely a great alternative to CFS for certain workloads. I would likely be using it right now, if RT wasn't an option, or if I thought it was overkill for my usage.
To say, Con is wasting his time - as you've said before, is silly. Lots of people have been using BFS for years, in my own experiences, it was great and in situations where i was getting XRUNS with CFS (on any kernel 2.6.33+) - with BFS, they didn't exist (on several machines). I think both CFS and BFS have value, and it's healthy to have them both around.
my 2 cents