[PlanetCCRMA] (Fwd) gak

[Fernando Lopez-Lezcano]

On Mon, 2007-11-12 at 12:12 +0200, DA. Forsyth wrote:
> 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 (why the change since last year). 

Did you do any package upgrades in between? Installed manually any
"critical" software? (jack/ardour/etc). Just the hardware upgrades?
There have not been upgrades for fc5 in Planet CCRMA for a long time, so
nothing should change. 

The priority setting in qjackctl overrides the default in jackd, "0"
means do not override. Unless jackd has been manually updated its
priority should not have changed - and it is set in the build process to
a value that is right for the Planet CCRMA kernel. Weird. 

[BTW, which kernel are you running? 'uname -r' to know].

>  right on!  
> ....  do a trial with software RAID between the 2 disks, (appears to) 
> works ok, so lets go... lets go record the band

Is this true linux software raid? Or are you using ardour's "raid"
facility? 

> 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?

I think so. Or just erasing it would do. 

> 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. 

Do you have a lot of overlapping regions? If so, they _all_ "play" (if I
understand things correctly). You should disable the regions that you
are not using if you have a lot of tracks. Otherwise the disk will not
be able to keep up. 

I don't know why ardour is doing what it is doing in your case. It may
be worth asking in the ardour-users list (with a preface saying you are
still using 0.99.3). 

> 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?  split the big files in 
> Audacity and reimport them?
> 
> hardware
> P4 3GHz with 1024MB RAM, SATA 80GB + SATA 160GB.
> Delta 1010LT for audio, motherboard audio disabled.
> FC5 + PlanetCCMA RT SMP kernel (SMP and nonSMP don't seem to make a 
> diffence, since this a fake SMP processor.  yes, I should have got a Core 
> 2 Duo)
> ardour 0.99.3
> 
> (yes planning to upgrade FC but since it was working for the last project 
> I figured I'd 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?

Normally in envy24 based cards just changing the sampling rate in
qjackctl is enough. Is your card running as a master? Or is it slaving
to something external? (which could force it to run at 44.1K). 

What happens if you exit all the audio programs and then do, from the
command line:

  jackd -R -d alsa -d hw -r 44100


-- Fernando


> 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....