Does anyone have insight or experience recording greater than 64 mono tracks at once?


I need to record 72 mono tracks in 24-bit/96KHz via three Lynx AES50 cards. When I hit record, the audio engine drops in less than a second. It's the same with 71, 70, 69 and down to 65 tracks. When I remove the 65th track and record with 64 tracks, it works like a charm.

This problem does not occur using Reaper but I'd rather use Sonar from start to finish.

I have an ADK Hex Xtreme DAW:
- Intel Core i7 4930K 3.4GHz
- 16GB DDR3 RAM
- System disk: Samsung 256GB 840 Pro SSD
- Audio disk: two Crucial M550 SSD's in RAID 0
- Windows 7 Pro SP1
- Sonar X3e Producer

This is a really rough guess but I don't think a 24/96 file can be more than a quarter of an MB per second, meaning 64 tracks is 16MB per second and 72 is about 18MB. WELL within the spec of even a regular hard disk under ideal circumstances, let alone two SSDs in raid. Do you see any CPU spikes? Have you tried different latency settjngs? Are you using software monitoring? Any plugins?

I would call tech support with this one. Take note of the questions they ask and the replies supplied. If they cannot help, please provide the detail information they ask for here to avoid having the same questions posed again.

I don't see any CPU spikes.  The buffer size is currently set to 256 for 2.66ms @ 96 kHz.  We tried it at 512 and 1024 but it had no affect.  We're not running any software monitoring or plugins.

When I called tech support, he had us try the 512 and 1024 buffer sizes.  He also tried changing the driver mode from ASIO to WDM/KS and then MME but neither of those work with the Lynx AES50 cards.  Lastly, he had us delete the AUD.INI file found in C:\Users\...\AppData\Roaming\Cakewalk\SONAR X3 Producer so that it would be recreated on a restart of Sonar.  None of these got us past 64 tracks.  In the end he said we need to update the drivers from version 13.0 (April 16, 2014) to 13.1 (May 2, 2014).  The thing is, why didn't Reaper have trouble if the driver is the problem?

Was the driver update applied? How is Reaper relevant if you want to use SONAR?

Haven't yet applied the driver update.  Reaper came into the picture because ADK tech support suspected a software issue with Sonar rather than hardware.  He just chose Reaper as a quick and easy way to test with something outside Sonar.

Our original problem was not only the inability to record more than 64 tracks but we weren't able to record those tracks for any longer than about 30 minutes.  ADK felt that we were hitting the limits of the 750GB Samsung SSD 840 EVO drive.  The hope was that switching to the raided Crucial M550's would solve all the problems.  It did solve the time issue.  We recorded 64 tracks for almost three hours without a problem.

What we can do as a work-around would be to record these large shows in Reaper and then port it over to Sonar for post production editing.  There is no problem in Sonar with playback of 72 tracks, only recording is a problem.  I could just go with that but it bugs me just enough that I can't let it go yet.

I wouldn't have thought (theoretically at least) RAID 0 would see much of an improvement with SSDs over a single disc. Either of my two Intel SSDs alone gets pretty close to what the SATA interface can handle for sustained read/write.

Were any plugins at all loaded in the Sonar project?

Have you considered reporting this as a bug?

DannyPrice
None of these got us past 64 tracks.  In the end he said we need to update the drivers from version 13.0 (April 16, 2014) to 13.1 (May 2, 2014). The thing is, why didn't Reaper have trouble if the driver is the problem?

 
Why not just update the drivers? Reaper might have a more forgiving input structure or whatever. It might be the only DAW that works without the driver update, or Sonar might be the only DAW that doesn't work without the update. But drivers are updated for a reason.
 

Anderton, for your 72-track recording, were your settings for a 24/96 recording?

Yes, but as pointed out earlier, it was a bogus test because Sonar is smart enough to know when I'm trying to trick it into thinking it's recording 72 individual wave files.
 
64 is a digitally significant number, if you know what I mean. Doesn't seem like it's just coincidence that things stop at that number.
 

TLW: I guess I was thinking that if writing all 72 tracks over SATA to a single drive was beyond the ability of the drive, then perhaps I would benefit by splitting those writes between two SATA interfaces and two drives.  Sonar allows me to choose a drive on the project level but not by the track so the only way I could see to split writes out of one project to two drives was by using a RAID 0 solution outside of Sonar.

I'm new to much of this and was told that writing 72 tracks of 24/96 could easily be exceeding a single drive's ability. I don't know this myself, it's just what I was told.  TomsHardware.com has an interesting article on the subject of a single SSD versus two in a RAID 0 configuration (). 

No plugins were loaded for this project.  We were just doing a raw recording of a symphony.

I guess it could be reported as a bug but I want to try what I can on my own in case it's just a false alarm.

Anderton:  I've updated the drivers this evening and will need to setup another test to check it.  The Lynx release notes say that this update is a minimal change but I've seen such "minimal changes" save the day before.  And I agree about the 64 number.  Seems suspicious that I get the same response whether with 65 or 72 tracks but with 64, everything is fine.

Sorry.  Meant to supply the tomshardware link "http://www.tomshardware.com/reviews/ssd-raid-benchmark,3485-3.html"