Robert Jonsson wrote: It would be SO nice not to be kicked out so easily by Jack, it is often more of a problem than dropping a few samples, albeit, obviously no-one wants clicks on their recordings, especially if you just performed the perfect, unrepeatable take. Godyes! Mind you, I'm running a 600MHz Celeron on 192M RAM, so I've set up runlevel 5 not to run cron or anything else that is likely to want attention in the middle of a session, like xscreensaver, for instance. I also run openbox-3 and do whatever I can to avoid waking up the KDE leviathan. On a slightly more powerful machine I don't think it would make so much difference, KDE is resource hungry, but not too attention seeking :) The services you want to stop are those that would interupt the nice steady flow of data that you are trying to write to the HD. cheers tim hall -- "You gotta remove part of the shell without breaking the skin, Grandma!"

On Friday 28 May 2004 3:12 pm, Artem Baguinski wrote: Hm. Rosegarden shouldn't be starting artsd, and it doesn't do so when I run it in a non-KDE environment here. (In fact I've always thought of that as an advantage of not running KDE -- things like Rosegarden don't have to contend with unwanted stuff like aRts.) So I'm not sure what's up there. Still, I think the easiest way to guarantee artsd never runs at all is to delete it, or at least rename the binary to something else. I have occasionally done that when annoyed with KDE for starting it with the new KDE session. Chris

On Friday 28 May 2004 5:41 pm, Artem Baguinski wrote: That's possible; or of course it could just be that once jackd is running, artsd can't start anyway. Chris

KDE starts aRTs by default. To shut it off, go to --> Control Center --> Sound & Multimedia --> Sound System --> (un)check "Start aRTs sound server on KDE startup" Rocco

All I've ever done is uncheck the box in the sound section of kcontrol. Artem Baguinski wrote:

RTaylor wrote: Rick, if you actually make any sound out of that system I'd sure like to know how you do it. MuscKit looks quite interesting, but its requirements have seemed fairly daunting in the past. I'm curious to know what's actually possible with MusicKit these days, so let us know if you have any success with it. Best, dp

Aha, a thread convergence! I started the "Ardour..." thread lamenting long xruns under the 2.6 kernels. Based on recommendations on the list, I went back to a 2.4 kernel, still having the occasional long xrun. In the "XRuns..." thread, the following from a post by Jan Depner caught my eye: "What kind of disk drives? Adaptec SCSI controllers can give you problems with xruns." Uh-oh. I'm using an Adaptec controller on my main board (a 7890). With a little digging, I came up with the following from the ST Audio website (http://www.staudio.de/kb/english/conflicts/): "The famous Adaptec 2940 SCSI controller series is causing performance problems when installed in the same system as our DSP24 series and when the audiodata is stored on a SCSI-HDD connected to the controller. To get good results in benchmark tests, the Adaptec controller keeps steady access to the PCI bus. The result is a reduction of data transfer of other PCI cards like the DSP24 hardware. This means that the ASIO/MME buffer size (which is the latency) needs to be set to a relative high value to avoid stuttered audio playback and drop-outs during recording. The performance problems can be reduced if both the DSP24 and the Adaptec controller both have a unique and unshared IRQ. Still the performance will not be as good compared to the regular onboard IDE-controller of a modern mainboard. This means that the best solution is to use a IDE-HDD to save the audiodata from within your recording software. The simple presence of the controller (that is used while the audiodata is stored on a IDE-HDD) is no problem." Uh-oh again. The 7890 is the on-board version of the 2940. I thought I had the xruns pretty much under control with the 2.4 kernel, then I picked up a M-Audio Delta 1010LT (I was jonesing for the 8 channels of input!). Ugh. I can't record more than a few seconds of 8 channel input before a 100msec+ xruns brings everything to a halt. Even recording 2 channels won't make it through a 4:00 min song. So, am I completely hosed with my Adaptec SCSI drive setup? Anybody have any insight into these Adaptec controllers? I've fussed with the setpci latency_timer settings (from Jan Depner's "Installing and configuring ALSA, JACK, & Ardour..." web site), but still see long xruns. Trying an IDE drive is not that simple, as I don't have any drive slots left in the box (I've got 4 SCSI drives setup as a RAID). So, I'd like to exhaust all possibilities before trying new drive configurations. Any thoughts/ideas/suggestions would be _greatly_ appreciated! Thanks, Joel

On Tue, 2004-06-01 at 08:14, Malcolm Baldridge wrote: I had these problems as well. There's a long thread a few months back where it was confirmed that I tried *everything*. Eventually I gave up and bought an IDE drive. Hey presto, problems gone. Now the only xruns happen when there's scsi disk activity, according to vmstat. The only time I didn't have these problems was with a MSI dual-athlon board that had a 64-bit PCI slot where the 29160 was plugged in. I only realised later (after the motherboard was on a ship to Taiwan, for a different reason) that the 64-bit slot was on a separate bus from the 32-bit slot where the audio card (Terratec EWS88MT) was plugged in. That board didn't give me xruns either. I think that's a plausible explanation, but then again it may have been because there were 2 cpus. On the other hand, I can't help wondering if the bus-greediness of the Adaptec controllers isn't a driver issue. I had a brief look at the driver sources, but I don't know enough about kernels and drivers to have made sense of them. bye John

On Tue, Jun 01, 2004 at 01:25:28 -0700, Malcolm Baldridge wrote: *shrug* its a symptom of the same thing - graphics people think video is the most important, storage people think its disk thorughput, but we know its audio latency ;) In general, people who add SCSI controllers to thier systems probably are mostly worried about disk i/o (thats when I use SCSI, certainly). In audio workstations disk i/o is not generally a problem though, in my experience. holding onto the bus for a bit longer probably gives them a few percent advantage over the competetitors, and most server motherboards I've seen in the last few years seem to have one PCI bus per slot, more or less. Another potential problem with SCSI is that the disks tend to be tuned for server applications, where flat throughput is the critical thing - eg. using larger ordering buffers to get the maximum throughput for each traversal of the platters. IDE and SATA drives tend to be tuned more for workstation performance where latency is more significant (the user doesnt want to wait 30secs for the word document to load because chkdisk is running, even though the overall throughput is higher). In practice it may not matter as the audio i/o load is pretty low, but its something to bear in mind. - Steve

Bad bad bad bad bad bad bad bad. RAID1 is good for fault tolerance, and for read performance... but worse than a single drive's performance for randomised writes. Software RAID implementations would give you worse performance on writes under all conditions, I wager. Try a non-RAID volume in your tests. Keep in mind that one write is triggering TWO writes in TWO transactions over the same SCSI card (and bus, probably). This isn't going to be good for latency or bus utilisation. Before you rip out too much hardware (and hair), try it with a "simple" volume first. =MB= -- A focus on Quality.

Joel White wrote: Ok, I busted up my RAID and with high hopes fired up jack and ardour on a new ext3 filesystem running on a single partition. Ardour ran for about 7 sec and stopped with a 300+ms xrun. This was running 8 inputs, and even running two inputs, things ground to a halt after about a minute. Just to be sure, I mounted the old Connor IDE and let thing ardour run. Got bored by about 3 min and shut it off. Buying a new drive is looking attractive again... Thanks for the suggestions. I may still look into reiserfs and the LCK1 patch set, but I don't have high hopes (a 300+ms xrun?). I'm thinking the aforementioned problems with the Adaptec 2940 is the likely root of my troubles. Joel

On Mon, May 31, 2004 at 11:00:47 -0400, Joel White wrote: You could beg/borrow/steal a Firewire, USB2 or SATA external drive and try that. You wouldnt have to destroy anyones data, just record some junk to it while you ran a latency test. - Steve