[Ardour-Users] gak

[Martin Lynch]

> Well, last year i had trouble getting jack stable with no xruns, and 
> eventually figured out a group of settings that worked.
> 
> This year I thought I'd upgrade a bit to facilitate recording, and added 
> RAM (RAM now running dual channel mode DDR2) and a second harddrive (WD 
> 160gb SATA).
> so what happens?   Sunday morning I do a quick 'record 8 channels' test 
> and jack goes nuts with xruns.  check, no settings have changed.  fiddle 
> around for a looong time before discovering that setting 'priority' to 50 
> instead of 0 gets it working.  right on!  ....  do a trial with software 
> RAID between the 2 disks, works ok, so lets go... lets go record the band
> 
> 43 minutes into the recording and ardour stops due to a 'your disk cannot 
> keep up' message (sadly is doesn't say which disk).  middle of a song of 
> course.  did I mention that we really needed the recording to be one long 
> piece so that it can be time aligned with the video tape easily?
> 
> ok, after that nothing worked right on that session so I started a new one 
> (thanks for templates). even so I ended up stopping and restarting between 
> songs, even having disk slow failures again as well.
> 
> but now.....
> that software raid thing is BROKEN eh?   only works sometimes, in that 
> after a restart of the session it may or may not actually use the raid 
> setup.  also, for some tracks it did not write out a proper peak file, so 
> I had no wave form display until 'something' triggers a peak rebuild.
> I did try renaming one of the peak files and it rebuilt it.  is it safe to 
> do this?
> 
> the big issue is that it 'decided' to keep adding regions to tracks 1 3 5 
> 7, using the same files (now 500+ megs each), while for tracks 2 4 6 8 it 
> created a new file for each region.  what?  I wouldn't mind if it worked 
> in the end, but while it did in fact record the audio, the regions are in 
> the wrong place, so the only one that works is the first one, the rest 
> repeat the first region from the big files, so while tracks 2 4 6 8 play 
> song 2, 1 3 5 7 play song 1.  so now I have to time align all these 
> things, and each song is different.  and I'm still getting 'your disk is 
> too slow' during playback, now and then.  I think it is the big files.   
> later today I'll try moving 2 of the big ones to the other drive so the 
> big file load is shared.  what else can I do?
> 
> hardware
> P4 3GHz with 1024MB RAM, SATA 80GB + SATA 160GB.
> Delta 1010LT for audio, motherboard audio disabled.
> FC5 + PlanetCCMA 
> ardour 0.99.3
> 
> (yes planning to upgrade but since it was working for the last project I 
> figured Id leave it and upgrade to FC6 after this project,  
> not wanting to chance a new install giving trouble.  sigh)
> 
> RT load shows around 10 to 14%.  latency is 87ms iirc.
> 
> PS: side issue.  last year I used 48000 sample rate.  this time I wanted 
> to use 44100 since we're making a CD anyway and we don't use a lot of 
> effects, being a live recording we get enough reverb from the room.  
> however,  nothing i did convinced it to use 44100.  I used envy24control 
> to set the hardware to 44100, then tell jack to use that rate (via 
> qjackctl), start jack and the envy24 window immediately shows that it has 
> gone back to 48000.  now, jack won't start because jack still wants 44100 
> but the hardware is doing 48000.   I tried deleteing ~/.jackdrc but the 
> hardware still went to 48000.   how does one actually change it?
> 
> we need to mix down tonight since some of the band members are going back 
> to their home country soon, and writing exams now, so time is shrt.  and 
> I'll be out of town Tuesday through Friday.....
> 
> any (quick) help would be appreciated....
> 
> 
> --
> David                       http://iwr.ru.ac.za/~iwdf/


Hi David,

I'm having the same problem re: Disk Can't Keep Up and posted this issue 
to Ardour forum but no response. I ended up having to delete all the 
other regions it created in order to play the simple 4 track drum tracks 
I'd recorded from Hydrogen. Like you, I have a RAID 0 setup and there's 
no logical way my drives could be bogged down playing four simple tracks 
(which, oddly, work on a single drive no problem, at half the disk 
transfer rate!). It's driving me mad and I wish the error message was 
more precise, ie "There's a flaw in Ardour that prevents it from using 
your disks efficiently, or even adequately" rather than implying it's my 
disks' fault (which have no problems simultaneously capturing and 
playing HD TV signals, for example, in full 1080 glory...). And before 
the obvious question arises, it's NOT a case of the drives not being DMA 
enabled - they're 2 X 320 GB Seagate SATA 2 @ 7200RPM: cached reads = 
761.46 MB/sec; buffered disk reads = 148.93 MB/sec with Ardour running 
on a separate 320 GB drive (hmmm, could that be the problem ie Ardour's 
on a drive with buffered disk reads of only 76.25 MB/sec and trying to 
keep up with the material recorded on the 148.93 MB/sec drives?).

I did notice that there were an inordinately high number of regions - ie 
perhaps 50+, which was odd given I'd only tried to record the damn thing 
maybe 4 times. I'm blissfully ignorant about programming etc but I won't 
let that stop me from suggesting it's a RAID implementation error in 
Ardour...

As for the sample rate, I'm unfamiliar with the M-Audio 1010 (I use 
M-Audio FireWire Solo) but are you sure the device is capable of 44K? 
Some devices are fixed at what amounts to a "native resolution" which 
jack can't alter...

Can you get it working at 88.2K, then halve the sample rate afterwards?

Good luck and sorry I can't be of more help, and here's hoping there's a 
solution for the very frustrating "Disk Can't Keep Up" message - I 
certainly can't trust Ardour to record live music until there is!!!

Cheers!

Martin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: martin.lynch.vcf
Type: text/x-vcard
Size: 66 bytes
Desc: not available
URL: <http://lists.ardour.org/pipermail/ardour-users-ardour.org/attachments/20071112/3d54f781/attachment-0002.vcf>