17 Nov
2005
17 Nov
'05
1:06 p.m.
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~