<html><body>
<DIV>A few days ago I posted the following message about tracking down xruns using Ardour to record to a SCSI Raid0.  At the end of the message, I asked whether anyone had any ideas about why commenting out a single line in streamview.cc (which at the very least eliminates updating the "progress" rectangles during recording) completely eliminates my xrun problem, in a rather dramatic fashion (dozens of xruns per min to none).  Since I got a goose egg in response, I thought I would try again because I've run out of things to test and don't know where to look next.  </DIV>
<DIV> </DIV>
<DIV>Basically, how can display updates in Ardour during recording cause xruns with writes to the hard drives?</DIV>
<DIV> </DIV>
<DIV>Since this problem doesn't seem to be common, it seems that it has more to do with my system/hardware configuration than with Ardour/jack.  But what, I don't know.</DIV>
<DIV> </DIV>
<DIV>Any suggestions would be greatly appreciated.  Thanks for your time.</DIV>
<DIV> </DIV>
<DIV>Joel</DIV>
<BLOCKQUOTE style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #1010ff 2px solid">-------------- Original message -------------- <BR><BR>> (Note that I didn't write "Problem solved" - I don't know how to solve <BR>> it, besides a hack described below) <BR>> <BR>> About a week ago, I posted a message asking about possible reasons why <BR>> xruns seen using 0.9beta11.2 when recording to a SCSI Raid0 went away <BR>> with 0.9beta12 (on a 2.4.23 kernel). Paul took pity on my poor, <BR>> tormented soul and let me have cvs access (thanks again, Paul!) so I <BR>> could try and track down the problem. I went through a number of old <BR>> cvs versions by the dates of "CVS commit" messages to the ardour-dev <BR>> list (not sequentially - I don't have _that_ much time!) and found the <BR>> smoking gun to be on May 7, 2004, when Jesse Chappell committed code to <BR>> put waveforms into regions while recording. That code pointed out where <BR>> the problem was. <BR>> <BR>> To make a long story somewhat shorter, it turns out that on my system, <BR>> updating the regions during recording (even with "Follow playhead" <BR>> turned off) generates xruns when the SCSI Raid is written to (i.e., <BR>> xruns occur when the drives chirp). Specifically, if I comment out line <BR>> 700 in streamview.cc (this is in routine StreamView::update_rec_box() <BR>> in 0.9beta19): <BR>> <BR>> // gtk_canvas_item_set (rect, "x2", xend, NULL); <BR>> <BR>> and run Ardour with the Display Option "Show waveforms while recording" <BR>> turned off, I get no (zero!) xruns while recording to the SCSI Raid, <BR>> where before I got > 25 per 1 minute of recording. Of course, I don't <BR>> get the pinkish boxes growing across the screen, but I can live with that. <BR>> <BR>> If I don't comment out that line, I get just as many xruns on the newer <BR>> versions of Ardour as before - I hadn't tried turning "Show <BR>> waveforms..." off before I started on my cvs quest. I guess I thought <BR>> the waveforms during recording were too cool. <BR>> <BR>> Turning on the "Show waveforms..." still generates about 3 xruns per <BR>> minute of recording, so I still don't know what's going on there (other <BR>> gtk canvas access, perhaps?). Also, running under the <BR>> 2.6.9-rc2-mm4-VP-S7 kernel still generates a handful of xruns per minute <BR>> on either Raid or IDE drives even with the above hack, so something <BR>> different still seems to be happening with that kernel. I'll stick with <BR>> 2.4.23 for now. <BR>> <BR>> If anybody has any ideas about what may be going on (how gtk canvas <BR>> access + SCSI Raid writes = xruns), I'm still curious. Also, I'm <BR>> willing to try additional tests, if it would be helpful. <BR>> <BR>> BTW, this is with gtk+ version 1.2.10. <BR>> <BR>> Thanks for your time, <BR>> <BR>> Joel <BR>> <BR>> <BR>> <BR>> _______________________________________________ <BR>> ardour-dev mailing list <BR>> ardour-dev@lists.ardour.org <BR>> http://lists.ardour.org/listinfo.cgi/ardour-dev-ardour.org </BLOCKQUOTE></body></html>