Sonar, latency, and dropouts

  • Thread starter Thread starter ljc
  • Start date Start date
No MIDI used by soundcard

I probably should have stated that I do not share midi with my soundcard. I use a serial port with my motu and the motu drivers are very good ( this is standard for midi ). Sonar is set to recieve SMPTE/MTC as slave and generate MMC as master. The motu really takes control over all of this. I only use my card for audio although it is capable. I just went out and picked up another 512 MB RAM and am going to use my SCSI drive for audio from now on. So currently I have removed MS updates from background tasks, adding more RAM, offloading disk access to SCSI and finally I'm going to research my IRQ layout a bit more.


AW4416 [ MMC slave ] [ MTC slave ]


Motu [ MMC thru ] [ MTC midi master clock ]


Sonar [ MMC master ] [ MTC slave ] : ( no soundcard )


**************************************************

SONAR [ record incoming audio ]

DMX 6fire audio card
[ slave external clock 44.1 ]

AW4416 [ generate 44.1 master clock]


**************************************************
 
Yeah, I'd rather hear a few pops and clicks in the audio, rather than just dropout myself, and I'm not looking for new features, since I haven't use alot of the current features. I'm game for making it more user friendly, and more stable....then I'd be happy.

What it comes down to for me is this: It's not Cakewalks issue that causes dropouts, but it is their problem to figure out how to avoid them. The should be able to learn about what causes dropouts in the first place, then somehow make the software aware of these, and do what it has to to continue working. It may be a tall order...but I think it would make alot of people happy. Heck, if you got a great performance with a couple of Pop's and Clicks...you could always filter for the Pops and Clicks!
 
Thanks again for the information and extra details Tmtkemp. :D
Wayne
 
Display more than CPU and Disk use

Just think if they came out with a monitor that let you know :

background tasks
IRQ conflicts
DISK status
interrupts that occur


Then when a dropout occurs, give a suggestion as to what the cause was and a solution. That would be cool.
 
sonar tweak

A strange tweak I found somewhere on cakewalks site is to change the li"StopIfStarved=1" to "StopIfStarved=0" in the Aud.ini file in the Sonar folder.
This tells Sonar to keep on going even if it gets disturbed (starved). It solved my dropout problems.

You open up Aud.ini in Notepad and change the 1 to 0 and save your changes.
 
But won't that cause a glitch in the waves if you're recording?
 
Maybe, if it is a big disturbence somewhere. But I haven´t noticed any clicks or glitches yet.
And sometimes when I record it´s more important that sonar isn´t dropping out which could ruin a good take.
 
Is it just a coincidence that this subject has gone this way today?! Earlier I read on the Sonar Newsgroup where Bruce Ennis was discussing creating a utility that does some of these things...asking if anybody had any special requests or suggestions. I hinted that it would be nice if there was a utility that would check your computer for the common causes of dropout, pops and clicks.....basically configuration issues and optimization. If he's successful with this development, Cakewalk should buy it off of him and throw it in with Sonar. That would save alot of TS calls!
 
Sorftware monitor

I would guess that audio problems are being talked about the world over, so it's natural that similar solutions pop up on different threads. where is Bruce Ennis, ask him to post a comment here on his work here. I'd like to know what he's learned or is focusing his app on. 28 posts later and the ideas keep coming. I would agree that if you can flip that drop out bit while recording, sounds good. After all if it drops out completely - you get zip. The chance of getting past the drop out is worth something. Does anyone know the implications of having my IRQ settings the way they are I'd like to know if anybody knows tricks to forcing IRQs for a device. I tried changing slots and the best compromise I get is the current one.
 
i don't think you specifically mentioned, but are you using windows XP?

i have been dealing with tweaking my system for audio stuff and have this to say about some of yr issues:

re: ACPI, i can't tell that it has made much difference in how my computer handles the audio, having switched over to standard PC mode. it's simple enough to make the switch, just update the driver in device manager under 'computer' at the top of the tree. one thing i have discovered since is that you can't go back to ACPI without reinstalling windows. i liked things slightly better with the ACPI, in terms of power management & whatnot (mainly it bugs me now that i have to push the power button to turn the box off). expect to reinstall at least some of your device drivers if you switch to standard PC.

re: IRQ sharing. manually changing the irq's seems to be a huge hassle in XP. what finally worked for me was just moving my sound card to another pci slot. if you have the manuals for your motherboard, check them to see what irq's are shared between what resources. might help you to target a likely slot to move your card(s) to?

one thing i did that i have never seen recommended, but makes sense to me, is to disable everything i don't use hardware-wise in the motherboard BIOS. this may not actually be doing any good, it just seemed like it couldn't hurt and might actually be of some help. i would appreciate feedback on this, actually :) i disabled the parallel, serial ports, game port, etc.

oh yeah, if you are in fact under winXP, you definitely should have more RAM. i think windows will be taking up most of that 128!!

have you run 'msinfo32', it provides a lot of information about your system, including irq sharing, conflicts, memory resources, etc.
 
i should mention, as a caution...

while fiddling in my bios settings, i really fucked up things fairly badly, although i still don't know exactly what happened. i tried to disable one of the usb ports, and this caused the computer to be completely unbootable, not even able to re-enter the bios setup. found a way to short out the bios modifications on the motherboard, then was able to reconfigure.

so anyways, everyone be careful when you're dinking around, or at least be willing to accept the hurdles as they come ;-) it ended up being a fun experience, because i felt i had learned something. although didn't learn exactly why the board wasn't liking that particular setting changed (i repeated it just to make sure that was actually the problem)

i also saw yr later post which says you've already tried changing slots.
 
Now, it's this kind of computer-tweaking that makes dealing with computers fun! :D
 
The reason for Standard PC over ACPI mode is simply because ACPI mode uses IRQ Steering and shares interrupts, whether you want to or not.

Yes, it is important to know how your motherboard handles IRQ (Interrupts). Most, if not all motherboards, Share Interrupts used by particular PCI and AGP slots with other onboard components, such as built-in Audio, Modem, NIC or Video. If you know what slots share, you can either disable the onboard item, or move your card to another slot. If you can't find a combination that elimantes shared IRQ's, then just make sure that the Video and your Recording card aren't sharing IRQ's. They are the most critical.

Still the only way I know that you can effectively change interrups of given PCI cards, etc., is through your system's bios, and by moving the card from a shared slot to one that isn't. ACPI mode should not be used if you ever want control over this at all!

Obviously, when you are disabling devices such as Serial and Parallel ports, you are actually releasing Interrupts that other devices can use. Serial, for example, typically uses IRQ's 3 and 4, whereas Parallel typically uses IRQ's 7 or 5. Once made available, your other devices can use these.

The problem with shared Interrupts is that they cause those random crashes and dropouts when any of the devices sharing the Interrupt are under heavy usage. Think about it...it's called 'Interrupt' for a very good reason! That's why it's important that you don't share interrupts on your Video and Sound cards that you use for Sonar.

As far as your system not shutting down once you switched out of ACPI mode...well, it can still shut itself off. It's escaping me at the moment as to how to re-enable this. Typically, if you install in Standard PC mode rather than ACPI mode, it will be taken care of through the install. Maybe somebody else can remind us of how this is done....
 
IRQ sharing and RAM

My final conclusion is that configuring a pc for audio is a circular never ending balancing act. I upgraded my DDR Ram to 640 ( 512 + 128 ) and removed any background tasks. I will also offload my audio to my SCSI and then let things settle for a while. One problem I think folks get into is assaulting their system with too many changes instead of making a simple change and watching for anamolies for a week or 2 before going to the next change. I get much better results this way. Oh and if I want to play with my bios, I plan it on a weekend. So far I think for my system having a single IRQ dedicated will be impossible. Even after disabling ports and things like USB keyboard which I don't use. I still have a ton of things soaking up IRQ. As my spec shows, I'm using IRQ 5 and there are some other low level things using it. even after playiong with slots thats the best I can do. Partly because I do use SCSI, USB printer, network card, serial access, etc.. Anyway, with all this going on I think the small changes are going well since I've only seen a dropout when I slam on media player in the middle of it. In fact I can now run and record both Sonar and media player at the same time if I start media player first. This has alot to do with my cards capabilities but the fact that the processor is up to it is awsome. Wait till I offload my audio files to my SCSI disk and access them there. Anyway, thanks for the tips everyone, its been a lively discussion. On to a new thread.
 
Incredible!

A strange tweak I found somewhere on cakewalks site is to change the li"StopIfStarved=1" to "StopIfStarved=0" in the Aud.ini file in the Sonar folder.
This tells Sonar to keep on going even if it gets disturbed (starved). It solved my dropout problems.

You open up Aud.ini in Notepad and change the 1 to 0 and save your changes
Click to expand...

Man, that's SO helpful! I just did it and ALL my dropouts disappeared. I was then able to halve my latency with still no sign of a dropout. What a result!

Mixed with my elation, however, is a certain amount of anger and bewilderment. Why on Earth would Cakewalk want to set this to 1 by default? Just to make sure that the software doesn't work properly, until users hunt around for esoteric fixes? I don't know what the setting is there for, but surely the logical thing would be to set it to 0 by default, so that we don't suffer the dropouts.

And NOWHERE in the manual or help files does it mention this tweak. I had chased around through every other tweak they described in the sections on dropouts, and none of them worked - I've had Sonar for a year now and never really got it as stable as I knew it ought to be.

Don't get me wrong, I love Sonar and I'll love it even more now. But I just don't understand the way software companies think, sometimes.
 
I now found the info in Sonar 2´s ReadMe file:


"New AUD.INI Variables for Engine Tweaking

SONAR 2 includes several new AUD.INI variables for tweaking the audio engine. The default values yield the same engine behavior as SONAR 1.3.1. The variables are all in the [Wave] section, and are as follows:

StopIfStarved=<0 or 1> (default=1)

Determines whether the audio engine should completely shut-down and put up a "dropout" indicator if the audio output queue becomes empty. Note that a dropout will still occur if the input queue becomes empty, or if other exceptional MIDI or disk I/O starvation scenarios occur. Setting this value to 0 yields engine behavior where the audio never will never stop during input monitor, but may click or pop instead."

Not really clear on what it means but I think maybe that if you hear clicks and pops with the setting to 0 those are not recorded but only playbacked (?).

There are some other tweaks that I haven´t tried yet. (Don´t need it really ´cause I now have 5ms rock solid latency with my SBLive 5.1 and kx drivers using ASIO in Sonar, what a bliss!).
 
Chezz deWitt said:
Note that a dropout will still occur if the input queue becomes empty, or if other exceptional MIDI or disk I/O starvation scenarios occur. Setting this value to 0 yields engine behavior where the audio never will never stop during input monitor, but may click or pop instead.
Click to expand...
I would say that this meant that if you were recording audio, and you should have a dropout (but didn't because of the "StopIfStarved" setting) you'd get a click or pop in your recorded audio... :(
 
You must log in or register to reply here.
Back
Top