Thanks florian, this gave a lot of insight.
Am Mittwoch 02 November 2005 18:35 schrieb Florian Schmidt: > > Well, yeah. First of all your question is very unprecise. I will try to > guess the blanks. Sorry for that. your guessing was quiet right. > > 1) you are probably talking about jackd as most other alsa apps don't > even report their xruns ever thought xrun is a jack thing > > 2) you are probably not running a realtime preemption or other low > latency kernel > > 3) you are not running jack with the realtime flag (-R) > ok i have done that. > The reason for an xrun is basically: > > The process consuming/producing audio did not do this fast enough (Audio > is processed in chunks and you have the time equivalent to one chunk of > audio to produce/consume it). > > This can have many reasons: > > - you ask too much of your computer (like the computations involved are > simply too complex). This would produce a constant stream of xruns > though. I suppose you probably see much less then 1 per > periodsize/samplerate sec. > > - this is the more probable reason: Some other process on your system > kept your audio producing/consuming process from doing its thang. > fixed > This second one can be remedied by changing step 2 and 3 above. > > There's two more potential reasons which i can think of right now: > > 4) your jack tmpfs is not mounted on a tmpfs or shmfs filesystem > fixed > 5) NPTL hell (google for this one) > > Have fun, > Flo my app runs quite right, in the normal play mode. then i started adding some effects. after adding 6 x 31 band eqs i have tons of xruns. but the cpu is only at 60% . A friend of mine told me, this can be because of the usage of only one jack buffer. this means - get jack callback - get the buffer from jack - fill the buffer with data - copy it back to jack is there a way to specify more than one buffer with jack ( like direct sound ) or do i need the ringbuffer. maybe someone can give my a link to an example. thanks c~
