system benchmarks or requirements?

No replies
audioguy_on_ca
User offline. Last seen 4 years 26 weeks ago. Offline
Joined: 2009-08-31
Posts:

First time post by a ProTools user who's just been turned on to ardour.

I have an old 1.67G4 powerbook with 2GB of RAM running OSX.5.4 that I'd like to take on location for multitrack capture.

Can anyone give me an idea as to how many 24/48 inputs this machine should be able to handle if I set Jack up for capture only? I would be monitoring off the console going into my converters, so I don't need full duplex. If I can achieve a stable 24-32 tracks (which as I understand it is within the FW400 bandwidth), I'll donate 5% of my fee every time it goes without a hitch...which would put me at or above an institutional subscription

Thanks in advance!!

seablade
User offline. Last seen 11 hours 56 min ago. Offline
Joined: 2007-01-22
Posts:

It is entirely dependent on your HD access speed.

The rest of what you mentioned probably isn't necessary, you just need to make sure you ahve plenty of HD access speed, which means probably using an external drive in your case.

And yes that track count is completely within FW limitations, I have run similar with no problem in the past. You would need many more for it to be an issue.

At any rate test it out. You can record silence just as much as you can audio, the disk access will be identical and you can use this for a good test case.

Seablade

audioguy_on_ca
User offline. Last seen 4 years 26 weeks ago. Offline
Joined: 2009-08-31
Posts:

So then I should get an eSATA card for the Cardbus slot...
Thank you! I'll post my results and make a donation based on my experience.

atossava
User offline. Last seen 3 years 28 weeks ago. Offline
Joined: 2008-11-03
Posts:

This is actually fairly easy to calculate.

24 tracks times 3 bytes (24 bits) times 48000 Hz is 3,456,000 bytes per second (3.3 megabytes per second). Ditto for 32 tracks (4.39 megabytes per second).

Although it has to be said that Ardour interchange files seem to be 32-bit, but the data that your converters put out probably is 24-bit only (putting the bandwidth requirement of the bus at said values).

voltaire:~> sfinfo scratch/Vesa\ guitar\ L-1.wav 

File Name      scratch/Vesa guitar L-1.wav
File Format    MS RIFF WAVE Format (wave)
Data Format    single precision (32-bit) floating point, little endian
               slope=1, intercept=0
Audio Data     1.25 MBytes begins at offset 56 (38 hex)
               1 channel, 326656 frames
Sampling Rate  48 KHz
Duration       6.81 seconds

The hard disk bandwidth requirement would thus be 1.33... times the bus req, or 4.39 MB/s for 24 tracks, 5.86 MB/s for 32 tracks.

I would be surprised if everything in your PowerBook (or any computer circa 2005) was not quite fast enough to handle it. I doubt you will need an external hard drive because of the speed, but of course an hour's worth of 24 tracks takes up 16 gigabytes and 32 tracks, 21 gigabytes, so you probably want the external drive so as not to crowd up the internal one :)

I'm doing (up to) 24 track recording on a PC through a RME HDSP 9652. I noticed that setting JACK to the lowest possible latency that the card can handle made 24-track recording impossible and I had to set a higher latency.

audioguy_on_ca
User offline. Last seen 4 years 26 weeks ago. Offline
Joined: 2009-08-31
Posts:

Thank you, atossava, I did the math. And yes, an external drive makes things much smoother in my testing of 16 tracks.
32 tracks at 24bit/48kHz is only about 10% of Firewire 400's capability...and yes, my converters are 24 bit.

As this is live capture (as opposed to studio where monitoring/punch-ins factor into the equation), latency is not an issue. Hit record and let it roll, monitoring off the analog front end, and the converters.

seablade
User offline. Last seen 11 hours 56 min ago. Offline
Joined: 2007-01-22
Posts:

atossava-

While you are correct, the math is easy to calculate, real world conditions mean that theoretical math doesn't match what is actually happening.

Specifically when dealing with mechanical hard drives, and especially when dealing with a mechanical hard drive that is sused for multiple purposes at once, like loading the OS and software, handling SWAP, etc. All those different things are on different areas of the hard drive, and the heads have to jump back and forth to write and read to disk, many times if talking about accessing anything like SWAP or other software from the HD.

Its funny, given al that a test I did a while ago about the actual usable speed on the HD for this purpose was around the 5MB/s range, much slower than you would think looking at the raw specs and comparing them with the theoretical numbers.

All of this is exactly why I say use an external HD. When you have it dedicated to a single purpose, and specifically when the heads don't have to jump around, things go much smoother, and it is much easier to depend on it for higher track counts.

All of this similarly applies to theoretical vs real world of firewire interfaces as well, though not nearly to the same extent due to a lack of moving parts to have to wait for. But there is overhead involved in the firewire data stream, how much depends on the interface. Pieter could tell you much more about that than I could, generally I find FW to be perfectly acceptable for almost any workload I can name, and if I ever needed more bandwidth I could switch to a FW800 interface. (Multiple RME FireFace interfaces chained together for instance).

Seablade