• SONAR
  • [Solved] My old hardware wouldn't support SONAR X2 - RME soundcard to the rescue (p.11)
2013/07/21 21:24:59
robert_e_bone
That's cool.  I was just thinking back to the start of the thread, and hoping that this will take care of things for you.
 
Bob Bone
 
2013/07/21 22:07:24
Goddard
Mod Bod
Goddard
Mod Bod, just wondering whether you'd tried the v3.16 2010-12-10 beta Dakota drivers here?:
 
http://frontierdesign.com/Support/Downloads/Dakota
 



Yes, I have those drivers but they show up as 3.15.  I figured that was because it was a beta.  Do you see that in the Dakota Control panel?   I tried updating the drivers just the same and the installer said that I had the most current drivers.  Just the same, I uninstalled the drivers and then installed them again.

Currently, I am able to play the problem project again.  But I've seen the same thing happen after opening the project in SONAR X1 - it will play for a time in X2a but at some point in time, it starts crashing again.

This problem may be moot tomorrow, when my RME card gets installed.  At least I will have drivers created in the same year I'm in.

 
Dave, sorry but not using a Dakota (only a Tranzport) these days, was just curious.
 
You, Eric P and Bill (wst3) may be the only Dakota users left around here.
 
To be fair though, considering the Dakota's vintage (the Montana expander card had one edge made to fit in ISA slots!) the Dakota has had a pretty long life, especially compared with other PCI multi-ADAT I/O interfaces like the Sonorus Studio, Yamaha DSPF, MOTU 324, Marian MARC and RME's original 32-bit-only 9652. And FDG did at least update the drivers long after the card stopped being sold and they had exited the interface market and moved on to doing development for Tascam and Presonus.
 
What really make me curious is why your Dakota works ok with X1 but not with X2.
 
 
2013/07/21 23:55:39
eric_peterson
That is strange that it seems to work with X1 but not X2; my fate may be sealed too. :-(  But, it has been a VERY long run. 
 
If it doesn't pan out for me this fall I may consider the StudioLive 32.4.2AI  board as it would replace _three_ analog mixers, my Dakota/Montana, and the four problematic M-Audio Octane's. The Octanes sound great but have to be warmed up for about 20 minutes if connected to low impedance mics or they hum like crazy. That kind of messes with my dream of being able to walk out to the studio, throw a few switches and starting to record if I have an idea.
 
Anyway, the StudioLive 16.4.2 in our PA works like a dream, the "Capture" program can stream all channels to the disk on my Sony i5 based VIAO and not even break a sweat at 5% CPU. If I make that leap it'll be after they get the optional Dante (Ethernet) card released. Well, that and after my reality determines if it's possible from a $ perspective.  I also need to do some A/B comparisons between the SL captures and what I can do in the studio. I've tracked a few things solo and they sounded pretty clean. But, I was just in my live room with a headset mic and plugged in direct with my Mama Bear. 
2013/07/22 08:12:49
Dave Modisette
Goddard
Mod Bod
Goddard
Mod Bod, just wondering whether you'd tried the v3.16 2010-12-10 beta Dakota drivers here?:
 
http://frontierdesign.com/Support/Downloads/Dakota
 



Yes, I have those drivers but they show up as 3.15.  I figured that was because it was a beta.  Do you see that in the Dakota Control panel?   I tried updating the drivers just the same and the installer said that I had the most current drivers.  Just the same, I uninstalled the drivers and then installed them again.

Currently, I am able to play the problem project again.  But I've seen the same thing happen after opening the project in SONAR X1 - it will play for a time in X2a but at some point in time, it starts crashing again.

This problem may be moot tomorrow, when my RME card gets installed.  At least I will have drivers created in the same year I'm in.

 
Dave, sorry but not using a Dakota (only a Tranzport) these days, was just curious.
 
You, Eric P and Bill (wst3) may be the only Dakota users left around here.
 
To be fair though, considering the Dakota's vintage (the Montana expander card had one edge made to fit in ISA slots!) the Dakota has had a pretty long life, especially compared with other PCI multi-ADAT I/O interfaces like the Sonorus Studio, Yamaha DSPF, MOTU 324, Marian MARC and RME's original 32-bit-only 9652. And FDG did at least update the drivers long after the card stopped being sold and they had exited the interface market and moved on to doing development for Tascam and Presonus.
 
What really make me curious is why your Dakota works ok with X1 but not with X2.
 
 


There's no way to find out unless the Frontier developers help and I don't expect that out of them.  The unit is out of production and out of support.  I got a good long run out of it and I don't have any bad feelings about it.  The card just refuses to die even to this day.  It runs fine in Reaper 4.0 x64 and Studio One 2.5 with the occasional niggle when I really load it down with plugins running in ASIO mode at low latencies. But that is to be expected.  It really acts up in SONAR X2a on a regular basis when I start loading it up with 3rd party plugs and Samplitude Pro X complains as well in the same situation.

Noel from Cakewalk tried to help but if I can't get Frontier to look at a crash dump and contact him to let him know what the conflict is there isn't any solution to the problem.  So be it.
2013/07/22 15:58:43
Jay Tee 4303
Back in the late Triassic Period when I was current on hardware and OS, a blue screen was aka a General Protection Fault.
 
No idea how true that still is.
 
So what's a GP fault?
 
Well, you got your storage...hard drives and the like, slow but doesn't forget when you shut down.
 
And then you got your RAM, fast, but it forgets when you shut down.
 
So your CPU works mostly out of RAM, but when the RAM is full, a whole "page" of data in RAM, the most ancient usually, meaning the opposite of what your CPU is working on right now, the oldest stuff in RAM, gets written to a temporary file in storage, so new data that is needed right now, can be loaded into the freed up RAM, and the old stuff is available, if needed, in a handy spot where the CPU can call for it's return en block.
 
This is called paging.
 
Unix has a couple advantages over it's mostly stolen younger sibling, Windows. One, it pages smooth and well, very few errors. Two, it maintains a certain distance from current activity, imagine a supervisor in a glass window tower overlooking a factory floor. If an engine block drops unexpectedly on a workers hand, Unix can dispassionately raise the block by remote control and call 911 fast and smooth, instead of flipping out over all the gore and screaming.
 
Windows used to flip out and panic the kernal when there was the slightest hint of trouble. It got a LOT better with Win2K, and recovers from errors a thousand times better than pre W2K code. What kinda errors?
 
Well, all of them, but significant to this tread, General Protection Faults. A GP fault is when the CPU and OS code try to page swap older RAM data to an address that the...Table of Contents...say is already loaded with data that shouldn't be over written. The new and currently necessary data has no place to be loaded, cuz the ancient data hasn't been page swapped to the hard drive yet, and a whole bunch of processor threads, who are expecting the new data yesterday, find themselves idle and start screaming at the supervisor (CPU), who, unlike in the mature and stable Unix factory, is right there on the assembly line floor, and he panics...his eyes glaze over, his jaw drops, and his lips move, trying to solve 857453242648465342 problems at once, but in reality solving nothing, what comes out of his mouth is gibberish, the screen turns to hash, and then, the reptilian core of deep level programming takes over and displays the "Technical Difficulties, Please Stand By" logo, which you know as the Blue Screen of Death.
 
Of course, this is all greatly simplified, and technically just plain wrong, in a thousand different ways, but it gets the point across.
 
So, what's your move?
 
One...make a note of what you've been doing that day...say 30 to 60 minutes before the BSOD. Not every mouse click...but in general...like...mixing 85846353254356 tracks with another 588463242 effects while running 68458735354 softsynths....or watching videos on Youtube, thru your HDMI connected second monitor. Over the course of several BSODs you will probably notice certain trends.
 
Two, if you are lucky enough to be able to read the Blue crash dump screen...while it's running a core dump, (writing the contents of every memory register to a core dump file, so a code weenie can detective his way into the core of the problem by reading the crash file, (files) get a pen and paper ready cuz at the end of the core dump, you are going to get a HANDY CLUE.
 
Somewhere near the end of all the computerese gibberish will be something that looks like a filename...perhaps "atikmpag.sys" for example...can anyone tell I'm working thru some BSOD issues of my own?
 
Use that file name to search the interwebs....oh I dunno...maybe "BSOD, Windows 7, atikmpag.sys" in yer fav search engine. Figure on half the responses to be way too complicated for you to understand. Figure on half the rest to be written in Burmese Sanskrit slang, you know, those bells and smileys that look like a foreign language. Don't waste a bunch of time on the junk, scan the search results for Little Red Riding Hood...answers that look JUUUUUSSSSSTTT RIGHT.
 
Make a note or two on what you find there. You MAY actually accumulate enough information to fix your own problem, or you may just get a better idea what's up to where you can contact support at say...your graphic card vendor....ATI km PAG(E) dot SYS(driver), get it?
 
Good luck.
 
PCs and achievement with same are not an objective, they are a process.
 
Good luck.
 
 
2013/07/22 18:44:52
lawp
yeah but
2013/07/23 00:57:11
eric_peterson
How did the RME card pan out Dave?  Did you get a chance to pull it into the fray? Or, did reality intervene? 
2013/07/23 12:49:20
Dave Modisette
eric_peterson
How did the RME card pan out Dave?  Did you get a chance to pull it into the fray? Or, did reality intervene? 


Well.... we... I mean "I"... had a set back.  I bought the card used over Ebay and it didn't include any of the installation drivers.  No problem, the drivers exist on the RME website.  To make a long story short, I installed the drivers improperly and immediately BSOD'd the system.  Win 7 wouldn't boot without an immediate BSOD, wouldn't Restore back to a previous date, wouldn't start in safe mode, wouldn't allow a repair and so on for several hours.  I had to reinstall Win 7 x64.
 
Anyway, I have the RME drivers installed, and I am in process of installing a multitude of software and plugins.  Since I have to reinstall everything, I'm seriously considering upgrading the computer from a 4 core processor running at 2.3 or 2.6 to an 8 core with 8 gigs of RAM.  I'll post the results when I get it all sorted out.
2013/07/23 12:53:40
eric_peterson
Sorry to hear that, what a mess! Like you really needed that?  <sigh> 
 
It's such a pain installing and authorizing everything, I think you have the right idea - upgrade now if you can swing it. 
 
Good luck! 
2013/07/23 14:22:20
John
thebiglongy
Mod Bod
John
Dave you should have a minimum 8 GB for a 64 bit system.  4 GB isn't enough.
 
You will need to get matched modules too. Unless you can be 100 % sure that any add on RAM will be identical to what you already have. This means not just the same brand but the same date of manufacture as well as the same type. Its best to simply replace it all to up the amount.   


No disrespect to you, John because I know you are only trying to help.  I ported the problem project to another DAW platform, inserted the same exact plugins and continued to add additional plugins until mixing was complete.  I can agree that more RAM is always better than less RAM but (and I may be totally wrong) I would think that a programmer could maximize efficiency and be a good steward of a systems resources when they write their code.  In fairness to SONAR developers, the program I finished the project doesn't have nearly the bells and whistles that SONAR has with it's Skylight interface and touch screen capabilities but I don't use those features anyhow.

If I install my new soundcard and it's drivers exposes a weakness in my system as well, then I will know that I have to make a decision to beef up my DAW from ground up or move on down the road until such time that I can do an upgrade.



DAW bakers should be aiming to make their products as light on resources as possible, yea, computers move on, but not everyone has the money to out on new ram/processor and such with every revision of the product.
The problem comes when bakers are too busy trying to make something look pretty, whilst forgetting about the core of the program, stability, functionality and as light on resources as possible to reduce the likely hood of latency induced by hogging the systems RAM/processor cycles. Daw bakers should build these programs to run on older hardware instead of building them to suck up the resources of newer systems with higher spec components.


I am answering only because more then one has made a comment. 
 
It is not a Sonar issue really. Sonar will run in a tiny amount of RAM but when you add Kontakt or BFD2 with a moderate size kit RAM becomes a big issue. Outside of a few other considerations the main reason to go 64 bits with an OS is to have more RAM at one's disposal.
 
Also with a Windows 7 and 8 64 bits the OS itself needs more RAM to run well. Heck MS even lists that its 64 bit OS needs twice as much RAM as its 32 bit version. 1 GB for 32 bits and 2 GB for 64 bits. If you have only 4 GB you may have less then 2 GB to play with considering you need RAM for drivers too. 
 
Many now are running 32 to 64 GB of RAM. Counting on 4 GB as your total RAM to work well with todays sample libraries using multiple GB of samples requires large amounts of RAM. 
 
I have hit the wall with my meager 8 GB. Besides RAM is very cheap these days.  
 
 
© 2026 APG vNext Commercial Version 5.1

Use My Existing Forum Account

Use My Social Media Account