SirNickity wrote:I want to know more. Are you saying that you are likely to run into access violations because of parallel threads reading/writing the same area of memory? Aren't locking mechanisms supposed to avoid that? (BTW: Interest, not challenge.)
As I understand it, that's it in a nutshell. Remember that in order to gain the low latency realtime operation, SAC's engine is coded in assembly, so presumably it operates under the radar of the locking mechanisms... or maybe it's the locking mechanisms themselves that cause the glitch. That's a question for the developer (just ask it nicely).
Generally, this is true. Reliability is almost always a matter of driver stability and other things you have going on. That said, Microsoft has an infuriating habit of dumping way too much code into a single binary, resulting in tons of complexity. Code that tangled can never be bug-free. This is why (server perspective) I avoid having Windows exposed to the Internet at all costs. Also, each release of Windows has more of the aforementioned gom and crum built-in. I started running a Hackintosh because I was having a hard time getting XP stable on my last build, and the extra fluff in Win 7 is filled with crap I don't want on a real-time performance PC. (Sidebar: Has anyone else used the dev preview of Windows 8 yet? What a nightmare. Totally unsuited for this type of work.)
Well... MS has kind of been like Star Trek Movies since win 98.. every other one is a good one. 98, good. Me, bad. XP, Good. Vista, Bad. 7, Good... I expect 8 will be to 7 as Vista was to XP.
I would love to see a purpose-built, pro audio-targeted Linux distribution. Linux, as it stands now, is tough because it's an unknown quantity. Anyone can DIY their own flavor and there's zero consistency. But if a vendor released an easy-to-use, black-box release that had just the necessary bits and pieces, with a very sparse window manager, that would be absolutely unbeatable.
The biggest problem with Linux for audio is poor driver support from pro level audio cards. Some have drivers, but they're not as good as the Windows and Mac drivers, because there really isn't much pro-level AV software on Linux. Sadly, Nix in general lends itself toward engineers and enthusiasts more than to the market... because there is no "standard" per se.
I always hear this, but I've had a hard time matching it. For example, I set up a Waves Multirack box running about 18 channels with compression, EQ, and a couple reverbs for sends. At ASIO buffer settings that didn't cause audible delay, I started getting dropouts and static in the audio. My CPU usage was at about 10-12%, but I think I ran out of memory bandwidth trying to shuttle 32 samples in, through the DSP, and back out in few enough ms. (This was on a Mobile Core 2 Quad 2.4GHz Mini-ITX build with a MOTU PCI-424 and 24i/o.) Also, the vocalist hated the phasing caused by the remaining delay in the monitor feed combined with his voice. I don't think any digital system can overcome that, at least until the delay is within a half-dozen samples.
Waves is a poor example of using plugs in live audio. Most of their plugs have latency, and are very processor and ram hungry. SAC doesn't support any plug which reports more than 0 samples of latency. Sometimes a plug will have latency in its processing and still report 0 samples... they typically do this by sending no data for the first few cycles. Those work and sometimes the latency is audible, but most plugs don't work that way. For instance, out of my Waves pack, there are only about 4 or 5 plugs that SAC will use, aside from the analyzers. The reverbs work OK, and I think there is one compressor that works (forget which one). They all hog CPU time too much so I use none of them, and there are others that sound as good or better (and are far less expensive, or free).
Also, multitrack mixes of any size in Adobe Audition 3 would start bogging down, but I'm not convinced that Audition is terribly well written.
That's Audition, not the mixes. Audition is an audio editor with a DAW shoehorned in, it's not well tuned, and it's Adobe - not exactly a DAW company.
So, how does SAC fair with latency? I'm curious.
Technically, SAC itself (as in the software) has very minimal or no latency. The system latency is entirely dependent upon your PC and audio hardware. Ultimately, SAC will operate at the minimum latency your hardware can tolerate. An average SAC system is 5-7ms, but could conceivably be as low as 2-3ms with enough horsepower and the right interface. This may sound like a lot, but it is well in line with the average digital mixer plus digital snake plus digital FOH processing that is used on live concerts. It only comes into play when mixing IEMs, and some of the more picky will hear phasing in their IEM mix... the solution is to either add a touch of vocal reverb to the iem mix, or increase the latency slightly with a delay plug to more closely emulate what they'd hear out of a wedge. Which one works better depends on the person.
IOW, SAC's latency is a non-issue for most users.
99% of the time, things that aren't already being done aren't being done because they don't work. The other 1% is split evenly between fools and geniuses.
Thanks for the discussion.