[ardour-dev] Ancient history? - Problem _really_ identified

Joel White cv223 at comcast.net
Thu Nov 11 13:48:58 PST 2004


Bing!  The thick mist of confusion is beginning to lift...

Thanks to all (Ron, Mark, David, Jan) who focused on the video driver.  
Of course, it makes perfect sense - now in hindsight.  And it explains a 
seemingly disparate observation (see below).

First of all, I did not consider the video because: 1) the xruns 
happened during writes to the SCSI drives (so it's gotta be the SCSI, 
right?); and 2) early on, I ran Benno Senoner's latencytest, which 
showed no problem with the X stress tests (I now see the problem there: 
latencytest only looks at playback, not capture).

Armed with my new-found video suspicions, I ran some more tests.  Now, I 
don't even have to start Ardour (or even record!) to generate the 
problem.  I start up qjackctl and run x11perf -shmput500 (suggested from 
latencytest) and voila!,  xrun city.  Quite spectacular, actually.  
Other x11perf tests (e.g., -srect500, but not -rect500) also generate 
the problem, so it may not necessarily be the shm.

My graphics card is an old S3 86c764.  I'm running an old ALR 7200 mobo, 
which doesn't have AGP (or at least, there's no identified AGP slot).  
This mobo does have an on-board Cirrus Logic graphics chip, which I 
think I will try (although the resolution is crummier than the S3).  [As 
you may guess, I kinda like forcing older hardware to do my bidding.  My 
system isn't too bad for audio - I can play back > 12 tracks in Ardour 
with a few plugins and not have any problem (with jackd -p 256, so 
relatively low latency).]

This graphics card doesn't seem to use latency_timer.  setpci -v -s *:* 
latency_timer shows it to be zero, and trying to set it to a value 
doesn't seem to have any effect.  I don't know, yet, if any of the 
device Options in XF86Config have any beneficial effect (so far, NoAccel 
and slow_dram don't have any effect on the xruns).

Disparate Observation: Tests that I ran with ecasound gave the first 
indication that the problem was not necessarily in the SCSI system 
(xrun-free recording).  However, I found that I could not run 
envy24control during recording or I would get lots of xruns.  I 
(mistakenly) thought this was an envy24control or audio driver problem, 
but I am enlightened now: envy24control only causes the xruns when the 
"Monitor Mixer" screen is visible.  I now see that the xruns were due to 
the graphics updates to the signal bars.  Switch to another 
envy24control screen, or minimize the program, and the xruns stop.

My only comment relative to Ardour: the xrun problem occurs even when I 
don't follow the playhead during recording.  That means that the little 
pink boxes are being redrawn quite frequently, even though the display 
is not changing.

Thanks again to all who nudged me in the right direction!  I have hopes 
that a different graphics card may eliminate my problems entierely(hey, 
there's an ATI at work I could "borrow" :-) and I can focus on making 
some music.

Joel
"glad to be getting this particular monkey off my back"




More information about the Ardour-Dev mailing list