Engaging SAW record glitches live audio stream

[Trackzilla]

Using SAW linked to test record through SAC, aprx. 50% of the time when I engage record I get a small burst of loud static & an associated mound of dropped output buffers. It can vary from unnoticeable to as much as 300ms in duration and I haven't figured out just what the variables are.
After this 'audible cue to talent & audience' that recording has begun, the rig appears to return to completely stable.
I note also that shift+click to cycle the engine & clear the dropped buffer log instantly stops recording, but I assume that has to/is supposed to happen (Dr it hurts when I do this...)

I have SAW hooked to the pre's in SAC, and I have the 'skip first buffer preload' ticked in SAW's options.

thoughts?

[Bob L]

No such issue in my tests here... or on any of the live gigs I have done this with so far.

Try setting SAC to Realtime priority... also... make sure SAW has its Audio Monitor setting to NONE in the Options menu... in other words... no live monitor in SAW...

Not sure if the ASIO Skip buffer is casuing it... I would leave that off for now... in fact... I would set the SAW devices to not assigned for all of them... in other words... use a preference that has no audio devices assigned in SAW.... just in case the audio driver has hooked the ASIO driver in some way between the two apps.

Bob L

[Larry Burger]

Abstract idea.

Is there any way when you start record from a cold start the video card refresh is creating the noise?

Could you go into video settings and reduce the Hardware Acceleration?

This is a long shot, just thinking out-loud.

Along the same lines, does anything change if you start from SRP, or Rec Rdy?

[Trackzilla]

SAC is already realtime, both are force single CPU & assigned to different cores. I'll try the rest of these suggestions in testing tomorrow, thanks for Round One of suggestions :)

[Pedro Itriago]

... both are force single CPU & assigned to different cores. ...

Uh oh

[Bob L]

Try not forcing anything... leave both cpus available.

It has been experienced many times that forcing apps to different cpu's can have the opposite effect than you would expect and overall performance of everything my go down.

Bob L

[Trackzilla]

ok, playing with what's forced to realtime, what's assigned to which core, and the various combinations of 16-24 bit & 44.1 & 48K (all possible combinations tested)--the problem is consistent on this box, although it does reveal these symptoms:
regardless of setting SAW to force single core, it comes up on both cores when you open the program, although it does politely remain on one core if Task Mangler tells it to do so.
I do get better buffer stability with SAC forced to realtime and set to single core in all other variation scenarios.

The test creature I'm using has 17 mono & 1 stereo input, 4 monitor mixes (5 monitor consoles-1 as master), and a few plugs. It's the mix session from a show I did recently...and no, removing all the plugins doesn't change the behavior at all. The more channels I'm engaging, the more buffers I can wave goodbye to initially. The problems don't surface until more than 4 channels are engaged.
No matter what I try so far, when record is first engaged in an 18 Channel instance of SAW, SAC loses between 250 & 450 output buffers for several seconds & then stabilizes. Subsequent start/stops do not cause ANY glitches.
[Related? Also, no matter what I do, SAC drops between 1 & 3 on engaging initially as well, unless I graduate to truly foolish buffer settings.]

On the whole, once I'm past that first burst of madness, the rig is stable as low as 1x64, although at that setting, the evil averages around 375 buffers lost over around 3 seconds.

I've yet to see any input buffer loss under any circumstances...ever. These are all output buffer problems.

Again, the workaround is to engage SAW once before bringing the amps online, and leave it idling until it's needed, but that does make it tricky to respond to a late recording request from an act.

[Bob L]

What was the soundcard? If it is firewire based... I have seen this in most of the ones I've tested... where the first open and engage of the drivers has a signaificant impact and delay while I guess it initializes some firewire port code... just one more reason why firewire soundcards have not been my first choice for serious audio use. :(

But... it still puzzles me that SAC is the one dealing with the soundcard and starting record in SAWStudio with the SAC-Link should not engage the soundcard drivers on its own at all... so there may be something else involved in the setup that is not so visible in the explanations here in this thread.

Bob L

[Trackzilla]

soundcard is MOTU 424 PCIx & 2408 mkll, so it's in the 'when is firewire not firewire' catagory...although perhaps it shares some characteristics with it's burntcable brethren?
otherwise, it's mostly that same that same rig although I added a discrete flash drive for the OS and am now using the onboard vid to run 2x 15" lcd monitors (one vga, one dvi-d dual link)
XP-64 bit
cpu: e8500
mb: asus p5n-em hdmi
4gb ddr2 pc2-6400
c: 32 gb supertalent flash drive
d: aopen slim DVD multiformat
e: 250 gb WD SATA
ps2 moose & kbrd
(I have tried saving a default preference for SAW with multimedia driver & no inputs or outputs selected to start it with...didn't help here)
(also just tried loading the fx32linker...loads, works, runs rcdelay...but hangs SAC on exit & BSOD...that might be a 64 bit issue I'm guessin?)

[Bob L]

XP-64... I missed that... could be connected... driver issues perhaps... I just bought an XP-64 disk and was going to install it on a test machine just to see what we are up against there.

Perhaps I'll have some insight to this and other possible issues in a few weeks.

Bob L

[Trackzilla]

i have xp sp3 and another instance of xp-64 on two small partitions on the data drive as emergency alternate boots, I know the same glitch occours with the other 64 bit instance, just didn't think to try the 32bit, duh.

I have a show tomorrow with the rig (the customer hasn't requested recording) so I'll run what works for this'n, but maybe Sun or Mon I can try it in sp3 back in the shop just to maybe shed more light...

[Trackzilla]

back from last night's show...I'll start testing to see if I have the same behavior with the 32 bit XP when I wake up (it's been a 23 hr day so far)

But thought I should mention that I improved my workaround so effectively that I no longer have a problem even if I don't track down the reason it is happening.

since it only happens on the first time I hit any record enable for a large group of channels in an instance of SAW...I simply changed my order of initiation slightly: turn the SAC engine off, then hit rec/ready (& acknowledge the polite warning that SAC isn't live) & restart the SAC engine...presto, no buffer glitches of any kind...

as a safety margin for this show since it was the first live run with SAW added in to the equation (it seemed wise to test the addition of recording when a customer wasn't expecting recorded results eh?) I increased to 1x128 buffer. With 19 channels at 24/48k, 5 mixes, a generous complement of processing for 5 hours (including playback during breaks with associated start/stops of recording) and the whole mess dumping to multitrack, only 2 dropped output buffers.

A band I hadn't worked with before & I actually got a standing ovation from the band when I popped into the green room on break...apparently their regular sound guy isn't..well...one of us :cool:

[Bob L]

Good job.

Perhaps what is going on is that Windows is taking some time to initially create the record files when you first push rec... this may be the cause of the glitch in SAC... I have seen SAWStudio by itself snap out of record on a large multitrack live session on the first press of rec when Windows tries to init 20-30 files at the same time and takes longer than the looptime for small buffer settings.

I'll look into a possible way to get Windows to init those files without stopping other threads in the process.

Bob L

[Trackzilla]

For the record, the same thing evidences itself on the 32bit OS, so it's not a 64 bit issue. Leaving my having discovered a grand total of 0 issues with 64 bit XP so far (I also determined that the fx 32 linker issue I was having also occurs in 32 bit, NM, don't need those plugs anyway)

It does seem to most likely be windows interrupting everything, including the New York Stock Market when it initializes that many files for recording. It doesn't happen with just a couple of tracks, and gets longer & more pronounced as the track count increases.

Now that I have discovered that I can initialize the recording with SAC offline, it's not an issue as I'll no longer be throwing that major glitch at my audience at a high volume ;)

so if it gets addressed in some engine improvement in the future, great, if not, no biggie

Thanks all for the help in addressing my latest oddity.

SAC/SAW visits my oldest standing, and frequently most demanding, customer next week for two shows with live tracking & his full band. Can you smell my excitement?

[DominicPerry]

Have you tried the same thing with the internal soundcard? I'm puzzled by this - I don't get this behaviour even if I push my machine past it's limit into many dropped buffers per second.

Dominic