N-Track with M-Audio 24/96, hicups in (long) recordings?

  • Thread starter Thread starter gwargantua
  • Start date Start date
G

gwargantua

New member
I've been around and around with this same problem for a long time now. It seems to go away, then it's back. I dub mini disc recordings from an entire disc in one pass using N-track and the 24/96. I continually get hicups or little bits of missing sound in the recordings. Not the "clicks" and "pops" some people report. Just missing a little bits, a second or two, here and there several times throughout a recording. Sometimes it happens early sometimes late in the recording, which lasts about 74minutes. It's occured in 2 different systems I had the setup installed in. I've made it go away sometimes by fiddling with settings (increasing latency and buffer sizes), but then it seems to come back.

Here's my current setup:

PC - P4/Celeron 2.53Ghz, Nvidia Gforce 6600, 512Meg DDR Ram, Audiophile 24/96 (PCI), (also on board sound), 2 ATA-133 Seagate 80G Hard drives in mirrored RAID configuration in two partitions. Windows XP fully updated including SP-2.

N-Track V3.3 - Default settings with following exceptions: Set for Heavy Buffering, 2048 recording samples, 5 buffers, 44.1 sampling, Highest program priority, M-Audio Delta ASIO for recording and playback WAVE devices.

24/96 - Drivers: 5.10.00.0048. Default settings with following exceptions: Sample rate 44.1, DMA buffer size 2048, "Disable use of Audio Mixer and Patchbay Router" box-checked, Patch Bay router set to Monitor/Mixer.

I record via the analog audio inputs on a single stereo track in N-track. No other programs running, no screen saver, virus protection disabled. Everything seems to work fine during recording. Then during play back, things go missing. It doesn't happen a whole lot, generally just a few times, but it varies. I don't believe the problem has anything to do with the hard drive or memory configuration since it occured on an Athlon based system which was completely different. I read posts, I think on another BBS, that the problem was how XP handles IRQ's and does something called IRQ sharing. It allows for more IRQ's than are physically available via software management and apparently it can not be bypassed. Perhaps the sound cards IRQ is being shared and some other device is preempting it causing the loss of data? :confused:

Does anyone know what I'm talking about or has experienced similar problems and know a cure? This is driving me NUTS! I'm dubbing live band recordings and routinely need to re-record everything half a dozen times before I get an error free recording. HELP! :eek:

Any info is sincerely appreciated. Thanks in advance.
 
i wish i could help u - i just downloaded the free version of ntrack as a trial (cuz my sony vegas is on haywire) i hope u git some answers, cuz i wanna know how to fix shit like this before i pay for the program -- im using maudio as well (mine is delta 66, though) -- u know how to make ntrack "see" the maudio soundcard? mine is only seeing the mme . . . ?
 
I was under the impression that RAID, especially mirrored RAID, was not particularly good for audio. That could be an 'old wives' tale', or just outdated information though, but it seems logical to me. Also, I think some video cards give audio programs problems, too, but that could also fall into the previous categories. Hope you get an answer.

Good luck.
 
Eyup ....
I wouldn't be surprised if your RAID configuration is what is causing the dropouts.
If your computer has USB 2.0 or FireWire, you may wish to try an external drive for you audio directory (Preferences > Paths > Working Directory) ..... or get rid of the RAID array in favour of two logical drives.


gullyjewelz said:
-- u know how to make ntrack "see" the maudio soundcard? mine is only seeing the mme . . . ?

Preferences > Audio Devices > Advanced > check "Show ASIO devices" and "Show WDM Devices".
 
Seems to be solved...for now

I don't think it has anything to do with RAID. As I stated in the original post, I had exactly the same problems in another set up and it was non-RAID. Also note, there are 2 flavors of RAID, RAID0 and RAID1. RAID 0 is mirroring, or placing exactly the same data on a partition mirrored on 2 hard drives. This adds security to a system so that if one drive fails, all system data is still available on the other drive. RAID 1 alternates data across/between 2 hard drives. This is supposed to give a performance boost in access time, especially for gaming. I implemented RAID0 because I don't want to loose data in the event of a hard drive failure. I could see potential problems arising from a RAID1 configuration, but not RAID0. I strongly suspect systems with RAID related problems were likely configured RAID1.

I think however I've got the problem fixed. I went to the M-Audio and N-track websites and found some suggestions. The primary issue seems to be XP and it's IRQ sharing protocol. Normally a system has only 16 IRQ's (0-15) but XP adds 16 more "virtual" sort of IRQ's which are implemented in software. Problems can occur if the Audiophile is assigned an IRQ greater than 15. Another device can be sharing the same IRQ and interupt it's processing incoming audio data. Thus, data can be lost for a short time while it's "on hold". I checked my IRQ's and the Audiophile was assigned IRQ21 on my system. I shut down the system, removed the Audiophile, restarted the system without it. Then I reinstalled the Audiophile in another PCI slot and restarted. It got reassigned to IRQ 17, but that's the best I could do. Basic problem is the system insists on sorting this stuff out for itself and the user has no control. I also implemented just about all the fixes reccomended at www.musicxp.net including disabling unused COM ports in the BIOS and setting program priority to backround. I've now recorded 2 complete discs at 44.1K / 24-bit and have detected no flaws in playback. However I accomplished all the above before testing, so not really sure if one, or all the things helped. I have also latency and buffering set pretty high. This works for me since I am not doing any multitracking right now, but it may cause problems in the future if I need low latency. For now, it's doing what I need, so I guess I'll cross that bridge when I come to it.

Good luck to anyone having similar problems. I hope this info helps.
 
gwargantua said:
I don't think it has anything to do with RAID. As I stated in the original post, I had exactly the same problems in another set up and it was non-RAID. Also note, there are 2 flavors of RAID, RAID0 and RAID1. RAID 0 is mirroring, or placing exactly the same data on a partition mirrored on 2 hard drives. This adds security to a system so that if one drive fails, all system data is still available on the other drive. RAID 1 alternates data across/between 2 hard drives. This is supposed to give a performance boost in access time, especially for gaming. I implemented RAID0 because I don't want to loose data in the event of a hard drive failure. I could see potential problems arising from a RAID1 configuration, but not RAID0. I strongly suspect systems with RAID related problems were likely configured RAID1.

Well, like I said, I could be misinformed, but I thought that the issue with mirrored RAID was that, unlike striped RAID that increases writing speed, mirrored RAID is taking the extra time to essentially write that data out twice, in two different places, as well as periodically check itself for accuracy, hence the hiccups in the write stream. But if it works for you, more power to ya. Hope you've really got the issue resolved.
 
Thanks, I hope so too. I guess anything is possible, I did mix up RAID 0 and RAID 1. RAID 0 is "striping" and RAID 1 is "mirroring". I don't believe mirrored RAID is writes data twice persay. Each hard drive is on its own bus/channel under the RAID controller, which appears as a single hard drive to the operating system. Heres a good explaination:RAID 1 Write access is the same and read access is actually enhanced because the system can retrieve different portions of the same data simultainiously from the two drives. Older RAID setups incorporated error checking as you mentioned. But newer hard drive error checking eliminates the neccessity. I did a bunch of homework on it before I built the system. I think it's definitely a worthwhile addition to the setup. You'll never loose all those precious projects again due to a hard drive failure. Still, it remains to be seen what will happen when I lower the latency settings. We'll see, but for now I'm not messing with it until I finish dubbing all the discs I have. Good luck!
 
Last edited:
Use "WDM: M-Audio Delta AP Multi".

This fixed my stuttering after 20- 24/96 tracks. ASIO is crap in n-TRACK.
 
yeah, ive had some stability problems using asio in ntrack.

Mirrored raid does perform slighltly worse on writes than a single drive. At 44.1 with few tracks you should be OK though. I record to a mirror raid myself, but plan to get a single highspeed sata drive for recording and use the raid just for storage.
 
Back
Top