I have some (every 2 seconds more or less) Xrun. But it does not occur if I have ardour switched off (system -> system) or if I record using qtractor.
I have tried wit an usb generic sound interface and using the one integrated on board.
As the jack configuration is the same, and as well the audio interface, and the only difference is qtractor / ardour, I suppose there is a problem in some part of ardour configuration. Am I right?
May be the solution is recording on qtractor, and copy everything to ardour?
Sorry if this topic is in another post, but I could not find it.
versions:
ardour: 4.0.111+r12836.21
in ubuntu 14.10
I think the configuration of jack is not necessary, as it works fine on qtractor.
What is the DSP load? Ardour always runs meters and faders (amp). So if you have a slow system, many tracks and use really low latency that will be some DSP load and hence cause x-runs.
4.0.111+r12836.21 is a weird version. the r+NUM does not correspond to any upstream git tag. If you use git, please use the latest (currently 4.1-418-g775a400) otherwise please stick to official releases.
I will try to answer everything as detailed as I can:
From qjackctl:
frames/period: 256
sps: 441400
periods/buffer 2
Realtime on
no dither
priority default
all the rest of parameters: off
Latency: 11.6 msec
system->system: no xruns after 1 minute
dsp load: allmost allways around 2.5~ 2.8%. peaks of 3.5%
using guitarix (only realtime, no recording):
system->system:
dsp load: 5.5~ 6.8%. Peaks of 7.1%
1 xrun every 8~ 12 secs.
using qtractor:
Recording, no monitoring, no effects:
dsp load: 2.1%
1 xrun in 1 minute (that is nothing)
qtractor:
recording, no efects, monitoring:
dsp load: 2.7%
1 xrun in 1 minute (that is nothing)
Ardour:
Recording, monitoring, no effects:
dsp load: 3.7%
13 xrun in 1 minute (that is nothing)
Ardour:
Recording, no monitoring, no effects:
dsp load: 3.7%
20 xrun in 1 minute (that is nothing).
Maybe this has something to do with what I’ve seen on my computer. On my system (UbuntuStudio 14.04) QjackCTL and Ardour 4.1 sometimes report different amounts for xruns. QjackCTL usually says there are zero and Ardour still sees some.
I have never noticed anything wrong with the audio (no clicks or pops) even though Ardour says there are lots of Xruns. I suspect that Ardour might see Xruns even when there are none.
I always start Jack with QjackCTL before starting Ardour, and have told Ardour to always use Jack.
1 xrun in 1 minute (that is nothing) ?! Something is wrong there.
Any xrun is bad. A system should run flawless without xruns for days.
mhartzel: JACK xruns != Ardour xruns. When adding effects, loading a session or performing similar other non-realtime operations in Ardour, Ardour will not process audio and simply return in the jack callback. Jack does not see an xrun, but from Ardour’s point-of-view there’s a dropout.
[Solved] @mhartzel: Sorry I did not tell. I saw more xruns on ardour or qtractor than in jack, but I told those from jack for avoiding if verbosity on ardour/qtractor are different. The xruns in jack are audible, but not thouse xruns showed in the DAWs, because of that I reported the xruns on jack.
Anyway, the solution was easier:
Originally:
input device: Usb generic
output device: Integrated on board
Now, I know it is nos a solution for x42, but for me (now), it is enough.
input device: Usb generic
output device: Usb gneric.
Just by changing the output device I have audible xruns on my recordings, and this occurs only with ardour, but not with qtractor.
I do not really understand it, but, so far, I considered it solved.
Thank you very much, mhartzel:, x42 for your support.
Yep, I agree. Using a different chip (=mobo) for output instead using your usb-interface in duplex mode alone is probably causing the xruns. Many mobo chips are prone to glitches by design. I call it “sitä saa mitä tilaa”. Ardour is just a ve-e-ry powerful multitrack DAW, whereas Qtractor by design limits its audio inputs to two channels.
You could try running two instances of jackd: uncheck the button “single application instance” in Qjackctl “misc” tab and don’t use duplex mode in either instance.
I knew that document, but I had read it only in the part of using several devices for recording, as it is proposed on qjackctl, I suppose it was solved. Thank you for remind me that.
I found more ways of reducing xruns without increeasing latency:
increasing buffers/period and reducing periods/buffer.
Another improvement was whe I changed the usb of conexion, from a frontal usb (it is shared with a SD card readr=, and using an specific usb port.
I wrote that just in case of somebody will have similar porblem in the future.
