[ardour-dev] Ancient history? - Problem _really_ identified
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
"glad to be getting this particular monkey off my back"
More information about the Ardour-Dev