On Tue, 2007-12-11 at 12:06 +0100, Jozef Henzl wrote:
operation it's ok, latency is practically
realtime.
If you are running a RT patched kernel with threaded IRQ handlers you
can set the priorities for the different IRQs just as for any other RT
scheduled thread. One second of latency sounds a bit extreme though -
are you sure the problem isn't somewhere else?
No, it happens only when the cpu is at 100%.
You can't expect things to work if the cpu is at 100% usage[*].
The same problem occurs when i am
using internal soundcard of my notebook with pure data - oss, alsa, jack
driver - everytime same problem (sc is intel-hda, nothing special).
Maybe i should check out if the pure data aren't blocking the input..
You should check whether you are trying to do more dsp processing than
what the cpu you have can do. If that happens then all bets are off. No
more cpu available means processes are going to wait and that directly
translates into audio dropouts.
-- Fernando
[*] or more precisely: it depends on what fraction of that cpu is being
used for audio work and what fraction is used for everything else, and
also on whether the audio processes are running with realtime priority.
If the audio processes are running with realtime priority then they will
not (in theory) slow down at all - the _rest_ of the computer will slow
down but you should not have xruns happening. That of course holds true
if the audio processes don't max out the cpu (till say, 70 or 80% of the
cpu). If the audio processes approach 100% usage that's it, an xrun is
going to happen.