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. _______________________________________________ Linux-audio-user mailing list Linux-audio-user@xxxxxxxxxxxxxxxxxxxx http://lists.linuxaudio.org/mailman/listinfo/linux-audio-user
