I tried recording 20 audio inputs during a rehearsal, using a Tascam US-20x20 interface with a Behringer ADA8000 piggiebacked via lightpipe in a GigPerformer setup. HDD was new, and virtually empty.
Initially I had the inputs routed within GP to different outputs as a pseudo monitor mixer - but after we noticed that the internal latency through GP built up and the mic outputs were delayed by 200-300 ms we shut off the outputs and used the Tascam-software mixer instead (as we normally do).
I kept the recording running, and it seemed to be OK. I recorded about 15-30 minute chunks, and then stopped and started again (lest the files would end up too big).
But now, when I’ve imported (no conversion) the 24-bit 44.1KHz WAV-files into a DAW (Pro Tools, which is what I’ve usually used to record these rehearsals with exactly the same setup) the files differ in size, seems that not all of them start at the same time, and some start in sync but drift out of sync as the recording progresses (and not necessarily in a linear fashion it seems).
I’ve still some investigating to do, e.g. whether this is an issue between the optical input tracks versus the analog tracks, but the fact remains that I’ve been able to record exactly these inputs, using the same driver, directly into ProTools in perfect sync.
So, has anyone experienced similar sync issues when directly recording the inputs in GP?
3.6.0
on Win10 Home, version 1809, 64-bit, x64-based processor
i7-4710HQ CPU @2.5 GHz w 16GB RAM
I think I’ve found the sync issue; it’s due to drop-outs in at least some of the tracks (a<bout 10-11 sec, but the track looks seamless (i.e. no silence or spikes at the dropout location)
here’s a screenshot of 5 tracks (first four are recorded via the analog inputs on the interface, the fifth is via optical input from the ADA8000 preamp into the interface).
It seems like it is not related to the tracks the dropouts seem to be spread out - suspiciously many of them seem to be about 11.5 sec long; I’ll have to investigate that further.
What seems to be happening is that audio inputs stop writing to their assigned WAV-file (often for approx 11.5 sec) and then continue writing to the WAV-file where they stopped, causing them to not only dropout but also go out of sync with the other audio tracks.
US-20x20 is master, ADA8000 syncs via lightpipe in.
And note, this works for Pro Tools, no clocking issues, and it’s not like all tracks dropout at the same time - it’s spread out through the tracks (like you can see with the yellow circles on my screenshot).
I’d guess your disk not fast enough and/or processor doing other things like networking, mail, or backup. I set a 512 sample buffer when recording 18 tracks on an ssd with gig performer and it’s been working well. I especially like being able to set the start time!
regarding the 512 sample buffer @thunderfingers ; doesn’t that cause audible latency if using soft-synths, let alone processing audio through the system (if that were the case)?
Or are you simply using GP to record the inputs and not for audio processing?
He may be using a second GP instance just for recording in which case it doesn’t matter what sample size you use so 512 is a good choice there. Even larger wouldn’t be an issue.
We understand that some other DAW may be able to do this, but please understand that GP is a performance tool and is doing things that other tools simply cannot do. You jump from one rackspace to another, you switch things on/off while playing etc… All that a DAW needs to do while recording is record and your computer is most likely not doing much else.
Are you using predictive loading? What is your average CPU usage when performing and recording?
The thing is that you really should not have a difference in the recorded input and what you’ve heard while playing.
Are these “silences” happening throughout your recorded tracks a t the same time? E.g. if you have channels 1 and 2 - does the silence happen in the same place for both channels?
thanks for your input @djogon, and I understand what the primary function of GP is. I just thought this was a very neat function in the software, so I tested it (with the aforementioned errors) and wanted to see what other users’ experience with this was.
As far as the setup goes, it was a static rackspace, no switching, but some routing into different outputs and some audio processing (4-band EQ and some gates) on some channels; overall the processing load never exceeded 10%.
The dropouts that I’ve found and have fixed so far are spread across the tracks, sometimes more than one track is affected at the same time but not always. Generally for each take there were 2-3 different file-lengths, and the sample length difference between the ones I’ve checked so far have been multiples of 262144 samples, which is if you divide the buffer-size (64 samples) into it comes out at a nice and round 4096.
I’m not sure this says anything, but it’s an interesting coincidence at least.
I was not using predictive loading, I think (because I only had one rackspace) and tinitially we were hearing audio directly through GP but then some latency built up on the tracks being sent to the monitor so we shut them off but continued using GP to record the inputs.
Hmmm. That is really, really strange. I routinely record my shows and typically record 12+ channels simultaneously for hours. I do it on the same computer and same GP instance I perform with.
In the early days of GP when we didn’t have input recording I used another DAW to record the inputs, but I had it once glitch for two seconds while recording and once it completely stopped. It has never happened with GP, but I did switch to recording to the internal SSD instead of external drive as well.
Dropouts across all your channels would make more sense and would indicate a performance/disk issue, but dropouts at difference places and just on some tracks at a particular point in time cannot be explained by that, but it could with some kind of timing issue. This would also explain your reported latency when playing through GP. That should not be possible so the only explanation is something within the hardware setup.
All buffers that come into GP - come in at the same time when hardware passes them to GP for processing. We record them then and there. If one is silent - it can only be because the original buffer was silent. Had you be playing through GP you would have heard the silence so GP, most likely, just recorded what came into it.
I would suggest you try several things to determine if there are sync issues in your hardware setup like change the buffer size to something more comfortable for your computer while recording. Try 1024 and see if that makes a difference or not. If it doesn’t - the issue is most likely the hardware setup/synchronization between the two interfaces.
Try recording without the ADA8000 attached and use just the US20x20 see if that makes a difference. You can still record all 20 channels even if there’s nothing coming in on the 10+ channels.
only recording and running Behringer Xair software to control my monitor mix on that computer. I use soft synths on another where I set it to 256 samples. I also use Apple MainStage with 128 samples but it also has an additional “safety buffer” so there are some additional settings that add up to - who knows what? I’m processing vocal live on that one and that’s where you can tell a small amount of latency better than I can playing guitar synth/virtual instruments.
Interesting info on the ADA8000’s but I’m not sure that this applies here, especially since I’m able to record using same hardware and drivers to another piece of software (Pro Tools) without the problem that I had with the GP-recording.
And note, regarding silence on the input etc … ; that was not the case. Nor have I experienced the silence when recording with Pro Tools.
What happened to some of the audio files recorded in each pass was that some of them had a file-length of say
39 690 000 samples (which is 15 minutes at 44.1KHz) and then some of them had a file-length of
39 427 856 samples (262 144 samples shorter than the full length) and then some more had a file-length of
39 165 712 samples.
You can’t see on the actual audio file that there is a drop-out - it plays over it, jumping ahead 5.9 or 11.8 seconds in the recording.
I.e. if there was only one dropout in the recording you could sync up the beginning - split the file somewhere and sync the end to the tail of the full recording. Then when you’ve found the location of the dropout you can trim the end of the first clip, leave a gap of multiples of 262144 samples and have the second clip continue to the end of the recording in sync with the rest.
It looks like the software stopped writing to the audio file for a fixed amount of time and then continued writing, but this leaves the resulting wav-file shorter than the full recording.
And this seems to have been spread around all tracks and not necessarily at the same points in time (although sometimes that happens as well).
Have you tried to disconnect the ADA8000 and record using the 20x20 only? Btw. Are the settings regarding buffer sizes, sample rates etc… identical in GP and Pro Tools?
Any little thing that’s different may be the trigger for the sync issues.
Try creating a separate instance of GP or at least use an EMPTY gig file to record the inputs. You may have some plugins that do something.
In general - strip down to the barest possible minimum - Use US20x20 only, an empty gig and record. Does the problem happen? If yes - then there’s something wrong with the disk/computer interface … if not - start building things up - add the ADA8000 and only that - then record again etc…
buffer sizes and sample rate were the same settings as in Pro Tools.
These are all good trouble-shooting ideas; I’ll see if I can implement them.
The problem is I don’t foresee that happening soon as I would need some sort of a synchronised source into the inputs to be able to spot if (and then where) the recording is paused (i.e. the writing to the wav-file) - like a rehearsal or a live performance and I’m not sure I’d be willing to sacrifice a recording of a live performance in a trouble-shooting session of that kind.
If you have a few patch cables just connect a bunch of outputs to the inputs, then drop in a sine wave generator or some sort (Melda has good ones) and generate a continuous signal that you can record.
Obviously you wouldn’t be connecting those input to anything in GP, just a plugin connected to your outputs.
I just tried multitrack recording again with Gig Performer and the same set of sync issues presented itself.
The resulting audio files (one per input) were not all of the same length - and the dropouts seem to occur randomly (i.e. not all at the same time).
The reason I bring this up is that this is a different computer, completely stripped prior to GP install - but, it’s the same audio interface (TASCAM US-20x20).
This was a last minute resort to use GP to track - other options weren’t available - but it seems that there’s either something wrong with the way GP treats audio streams or the interface (which works great when multitrack recording via Pro Tools).
