Long live sessions: problem SOLVED!! Again!!

[JPS]

How long should a laptop be able to record a live session before producing errors and interrupting the recording? Ideally, it shouldn’t produce any errors at all. Unfortunately, this is not my experience. I recently recorded audio for a wedding and a Christmas service, and I received multiple 6085 errors during the 75-90 minute recordings. So, I decided to look a little further to tweak my laptop for recording long live sessions.

I did some testing by making a template, which used 8 aux tracks for audio input with a compressor on each. The audio was then bussed to individual tracks for recording. This is a recording technique I used for the services. I used my IBM T41 laptop, which has a 1.6 ghz Centrino processor, ADS PCMCIA firewire card and 002r, a 2nd internal 7200 rpm 60G HD, and gets 32 +16 on the Davec test. The results from my tests surprised me. In 12 attempts I got the following results:

40 min -6089 error (1024/firewire)
47 min -6085 error (1024/firewire)
37 min -9093 error (512/firewire)
21 min -6085 error (1024/firewire)
61 min -6085 error (1024/DAE 1/Internal 2nd HD)
53 min -6085 error (1024/DAE 2/Internal 2nd HD)
35 min -6085 error (256/DAE 2/Internal 2nd HD)
At this point I disabled the onboard sound and reduced the services from 32 to 18, then:
96 min -6085 error (512/Internal 2nd HD)
103 min -6085 error (256/Internal 2nd HD)
85 min -6085 error (128/Internal 2nd HD)
69 min -6085 error (64/Internal 2nd HD)

Clearly, reducing the services helped. So, I have this second OLD IBM laptop, A21p, with a 850 PIII processor, 5400 rpm OS drive, a 45G 2nd HD at 5400 rpm, and a Davec result of 16 tracks. I put the same ADS firewire card with the 002r and run the same test. Results:

6 hrs, 42 minutes and 37 seconds!!! No errors!!! (1024 buffer/DAE 2)

Total success the first time! I get the message “Recording has been terminated because either a disk is full, a file exceeded the maximum size or the record allocation space preference has been exceeded.” The disk was not full, still had 5 Gig of unused space. I set no maximum record allocation. So the maximum file size was reached. The recording was 16 gigs, which is 2 gig for each file. I am running a second test on the A21p laptop overnight. I’ll find out in the morning how things went… it is currently over 105 minutes…

I am still looking for the reason my new and much more powerful Centrino laptop is having difficulties with long recordings. To fix the –6085 error Digi recommends setting the recording file allocation size to 10 minutes. Yes, that would stop the –6085 error… but doesn’t solve the problem. The IBM T41 is still a great laptop, gives no problems with shorter times, does a good job on BTD and basically operates error free… except for long sessions.

I would be interested in hearing if other laptop owners have trouble with recording long sessions using the Aux/compressor/audio track setup with 8 tracks.

[Rock_Artist]

Weird
We recorded live show with my Centrino 1.4Ghz to External USB2 80GB HD with 002R.
I've record into 3 paratitions of FAT32 @ 24/44.1khz. 16tracks
the show was 4hr1min and all went fine .

H/W Buffer: 1024samples cpu: 80%. DAE2.

[JPS]

Thanks, Rock Artist for the info. 4 hrs, that a pretty long session! I'd started to wonder if the Centrino might have a few issues of their own.

The second recording attempt on the IBM A21p also went fine and recorded the 6 hr and 42 min and 37 seconds. The exact time as the first attempt. That makes a 2 gig audio file for each track, which looks to be the maximum for PT. I looked through the Digi reference .pdf files and couldn't find that bit of data in the PT Reference guide.

I have a question about your session, did you use the auxs with software compressors, or did you record straight into the audio tracks?

The IBM come preloaded with a lot of "stuff", so I'll be looking at doing a clean XP Pro install, but first I think I'll try a 8 track recording with no software compressors to see if that makes a difference.

[da BaSsTaRd!]

i don't know if this is meaningful, but one obvious difference between your setups is rock artist is using a usb2 drive while you're using a 1394 drive. food for thought...

[Rock_Artist]

Yep that's a major difference. I like the USB2 better than my FW drive... works better don't know why , also it has its OWN path not sharing any 002R .

This was pretty important show of a major band that played their entire 3 albums in a row. for archive purposes they wanted to recorded the show. we just hooked the 002R+RME ADI8 Pro to the Console Direct Outs opened 16 tracks in PT and put the Buffer 1024 / 80% cpu usage for safety.
No Aux or any FX...

2GB is the FAT32 limit I'm not sure if it's a PT limit...

We recorded into 2 machines: 1. My centrino 2. Powerbook G4 1ghz.
Both got the 4hr show fine.

[JPS]

Yeah, I thought about that and it does make we wonder. But I have also recorded to an internal 2nd HD on the T41 and have similar error problems. I also think something may be going a little wierd with PT on the T41 because now I am starting to get -6087 errors, which don't occur on the desktop or other A21p laptop with the 002r. So I need to just reinstall PT before I go any further.

[Rail Jon Rogut]

2 gig is a PT limit to maintain OS 9 compatibility... It's in the Hard Drive recomendations PDF in the Compatibility pages of this site.

Rail

[3JDamon]

I like the USB2 better than my FW drive... works better don't know why , also it has its OWN path not sharing any 002R

The 002R should really have its own Firewire interface anyway. Just don't want people to think that USB2 interface is on par with Firewire, because it isn't.

[Rock_Artist]

Maybe it isn't but so far I got better track-counts from USB2 Hard-Drives. OK FW use own controller for I/O while USB use the CPU but still so far I have had much more issues with FW than with USB2 powered (not self-powered) hardware.

[Stone Knife]

JPS perhaps it's not Firewire in general but a problem with your particular Firewire card. Some chipsets work more smoothly with the 02 than others.