quoted
there are a variety of things that can block for between 16 & 300 ms (not
necessarily IRQs).
what size fragments are you using?
2K. I have to rise it to 8KB to work fine. My friend with the G4 still have
very few interruptions even with 8KB.
OK.... if you can't do with such large fragments ....
You might want to try Andrew Morton's Low-Latency patch (URL:
http://www.uow.edu.au/~andrewm/linux/schedlat.html#downloads )
it makes things quite a lot better - but we still have a way to go on PPC
before we can achieve sub-ms block-free operation. Another thing on the
audio TODO list ;-)
let me/us know how you do if you try it (last time I did, the patches
applied cleanly to the PPC BK tree) - you (could at the time) ignore the
x86-specific mods to head.S.
HTH,
Iain.
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
quoted
quoted
there are a variety of things that can block for between 16 & 300 ms (not
necessarily IRQs).
what size fragments are you using?
2K. I have to rise it to 8KB to work fine. My friend with the G4 still have
very few interruptions even with 8KB.
OK.... if you can't do with such large fragments....
You might want to try Andrew Morton's Low-Latency patch (URL:
http://www.uow.edu.au/~andrewm/linux/schedlat.html#downloads )
Ok, I'll try, but this problem regards interrupt latency, not user-space latency.
In the meantime I applied your patch (ints << 10 can't compile
in _core.c and I had to comment them out). It makes no difference.
I was fiddling compiling things and I noticed that one of the
worst offenders is libtool, a script in the root the the xmms source tree. Just
run it to get a 100ms pause. This night I'll check if rt_sigprocmask() keeps
irq disabled. Another thing is console scrolling.
Bye.
Giuliano Pochini ->)|(<- Shiny Network {AS6665} ->)|(<-
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/