Will more RAM enable me to lower buffer size?

[Stringpark]

Hey there, I'm fixin' to ask a stupid question, I can just feel it, but here goes anyway. I am trying to set our drummer up with a BFD Eco rig for live use. Here is the setup: Laptop: 1.66GHz Core 2 Duo, 1GB RAM, 120GB 5400 RPM HD, WinXP Pro SP3 (probably not the best hardware, but the price was right). Audio Interface: Alesis IO|2 using the ASIO4All driver. Kit: Stock V-Session (TD-10).

So, I've tried to tune up XP as much as possible (though I haven't messed with the page file yet) and the performance monitor shows about 500MB or so of RAM in use with Eco running. I have the RAM buffer in Eco set to 32k since the HD is only 5400RPM. I do not have "Load on demand" selected. With all of above configuration, I am able to run my buffer size down to 192 samples @ 48kHz before audio problems set in. So, I think this works out to 4ms of audio latency on top of whatever midi delay there may be in the chain, which I have not yet investigated (I just simply connected the midi out of the TD-10 to the midi in of the IO|2). I don't guess 4ms is too bad, but since RAM is cheap, I was just wondering if adding RAM might enable me to reduce the buffer size any?

Thanks!

[john emrich]

Yes, more RAM will help. The biggest suggestion that I have for you is to get an external 7200 rpm drive for the eample data. You should also go to 44.1.

Cheers,
John

[doublestrokeroll]

Hey there, I'm fixin' to ask a stupid question, I can just feel it, but here goes anyway. I am trying to set our drummer up with a BFD Eco rig for live use. Here is the setup: Laptop: 1.66GHz Core 2 Duo, 1GB RAM, 120GB 5400 RPM HD, WinXP Pro SP3 (probably not the best hardware, but the price was right). Audio Interface: Alesis IO|2 using the ASIO4All driver. Kit: Stock V-Session (TD-10).

So, I've tried to tune up XP as much as possible (though I haven't messed with the page file yet) and the performance monitor shows about 500MB or so of RAM in use with Eco running. I have the RAM buffer in Eco set to 32k since the HD is only 5400RPM. I do not have "Load on demand" selected. With all of above configuration, I am able to run my buffer size down to 192 samples @ 48kHz before audio problems set in. So, I think this works out to 4ms of audio latency on top of whatever midi delay there may be in the chain, which I have not yet investigated (I just simply connected the midi out of the TD-10 to the midi in of the IO|2). I don't guess 4ms is too bad, but since RAM is cheap, I was just wondering if adding RAM might enable me to reduce the buffer size any?

Thanks!

But don't forget that XP will cap the RAM to any one program. Best I could ever figure out was about 1.7 GIGS available for use on a machine that had 4 gigs. I hated XP for use with BFD. I got it working fairly well but always had some occasional clicks pops and dropping of notes. Said screw it and went MAC pro. Haven't looked back.

[NicoD]

Try using dedicated ASIO drivers instead of ASIO4ALL. I doubt you have 4 ms with that USB interface in reality. External drive firewire or esata is recommended. If you want to play live, you should get buffer size to 64 samples or lower.
My setup: 1.6GHz Core2duo, 2 GB RAM, Vista, 100GB 7200 rpm, firewire 7200rpm drive for data. Cakewalk UM-1G and Echo Indigo IOx at buffer size 32 samples. Roland TD4.
Total latency measured 6 ms. Occasional clicks and pops when playing faster, especially when using expansion packs.

[Stringpark]

Thank you all for the replies, they have all really helped. I did some more playing around after posting and I figured I'd post the results in case someone else with a similar setup finds it useful. First, the driver. The Alesis IO|2 (original version) came with an Alesis ASIO driver on CD (though ASIO4All is what they now have as the IO|2 driver for download on their website). I have both this driver and ASIO4All loaded. I ran a hard loop between the analog out/in of the interface and using Cubase, did some latency testing. Between the two drivers, ASIO4all came in a little faster (by a millisecond or so as I recall), even when both were set to the same sample rate and number of buffers. I did a LOT of testing and its been a few days now, but to the best of my recollection, the overall round trip delay for audio was about 10ms or so with ASIO4all. This was at a buffer of 256 as the 192 from my original post turned out to be a little too optimistic once the drummer really got going. I did a hard loop test through the S/PDIF connections and was surprised to see that it was about a millisecond slower than analog. Also, its worth noting that the buffer settings in the drop down "I/O Settings" in Eco do seem to have an effect on things, though they don't directly change the value in the ASIO driver control panel. For example, if the drop down buffer setting is 256, I get pops when I run the buffer down to 128 in the ASIO control panel. 128 is too low of a number for my setup, but if I change the Eco drop down setting to 128 to match the ASIO control panel setting, it actually pops less than when the drop down was set to 256.

Using Cubase again, I did some Midi latency testing with a hard loop on the interface. Here I measured about 3ms. So, assuming that I can divide that measurement in two to get just my input midi latency and divide my 10ms of audio latency in two to get just my output audio latency, then I'm coming up with about 6 to 7ms of total latency.

Next, I wanted to mention that I turned off my page file. This made a noticeable improvement in the pops and clicks (confirming that my 5400 RPM drive was struggling to meet the data demand). Lastly, I was getting just a slight pop on a fairly consistent basis even with little drumming activity. I selected an option in the ASIO4all control panel saying something about "force WDM to 16 bit". For some reason, this stopped that particular pop.

So, I'm pleased to report that I got to debut the new rig to our drummer tonight and it worked well. There is virtually no distinguishable difference in the timing of the Eco sounds vs the internal Roland sounds. Our drummer was pleased with the "responsiveness" of Eco (referencing the velocity layers I believe) vs the internal sounds of the TD-10 brain and with a little mixing, it sounded absolutely ridiculous! I still detected a very occasional pop, so I may look at the 7200 RPM drive. I noticed that multiple people mentioned an external drive and I assume there may be an advantage to having the sample data on a different drive from the OS. If so, is this still an advantage if the external drive is connected via firewire vs replacing the OS drive with a 7200 drive that would be connected via SATA? I have firewire available on the pc as well as a PCMCIA slot (so I guess I could get esata if needed).

Thanks again!

[NicoD]

...There is virtually no distinguishable difference in the timing of the Eco sounds vs the internal Roland sounds...

Modules also have latency so you still need to add the internal time from your TD10 to your midi and audio latency.
You could connect the eco audio to the mix in from your TD10 to check if there is a delay between Eco and internal Roland sounds. Hit a pad so you hear both at the same time.

[Stringpark]

Modules also have latency so you still need to add the internal time from your TD10 to your midi and audio latency.

That's a good point! I'm not sure how to give it an exact measurement, but it likely adds one or two milliseconds as well.

The MixIn idea is fantastic, I probably would have just done that if I would have thought of it. For my comparison, I ended up running both the roland and eco outputs to our board and back up through our monitoring system. Frankly, when I think of all the stuff in the chain, I am amazed that I don't "feel" a delay from hitting the drum to hearing the sound. There is the time for midi out of the brain and midi in of the audio interface, thru eco and then D/A out of the audio interface to the A/D in the board then out to our Hearback system (<5ms delay is the spec) and finally back out the drummers earphones. Quite a long path when you think of it.

So anyway, anyone have any opinions on the external vs internal drive? Does firewire deliver fast enough throughput to maintain the advantage of separating sample data from the program drive (if that is an advantage)? Or would it be best for me to upgrade the internal sata drive to 7200?

Thanks!

[NicoD]

You can measure the latency from your module by plugging an Y-cable into the pad. One cable into the line-in (1st mono channel) audio interface, other cable into module. Record on the 2nd channel output from module. With an editor you can see the delay between the piezo signal and audio from module. Roland modules seem to have around 4 ms latency.

I think it is better to install the sample data on a seperate drive. If Windows starts doing things in the background or your DAW use tracks on the same drive, streaming will not be optimal.
The faster the drive, the better. Even my 7200 rpm firewire drive gives sometimes clicks/pops with expansion packs when playing faster (more resource hungry). If you have an external drive available to test, you could see if it works better or not. You don't need to reinstall Eco, just copy the data to the external drive, set data path and rebuild database.

[Stringpark]

You can measure the latency from your module by plugging an Y-cable into the pad. One cable into the line-in (1st mono channel) audio interface, other cable into module. Record on the 2nd channel output from module. With an editor you can see the delay between the piezo signal and audio from module. Roland modules seem to have around 4 ms latency.

That's a pretty cool idea! I may try that just so I can know the latency.

I have a USB 2.0/eSATA external drive with 7200 HD that I could use to test with. As it is, the pops are are few and fairly subtle. But if the USB external drive that takes care of the pops altogether, then surely a firewire drive would as well.

Thanks for all the help!