With Ardour2 (not 0.99.3) disk not fast enough

Firstly, thanks for everyone’s work in developing Ardour. A few comments about the latest beta version:

While giving Ardour2, beta 10, a test drive, and successfully making three half-hour recordings—with a few glitches, I had only a few problems with the recording stopping and error messages being displayed telling me that the disk system couldn’t keep up with Ardour.
With the previous version of Ardour, I couldn’t record for more than a few seconds, so there’s been a definite improvement. However, with 0.99.3, I didn’t have to restart the recording several times, as a result of error messages about disk system performance, in order to get a half-hour’s worth of recording.

Furthermore, with 0.99.3 I could also play the recording back and copy parts of it to other tracks with no problems regarding disk system speed. With Ardour 2 beta 10, I can’t even play the recording back for more than a few seconds.

My disk subsystem may not be blazing fast, but surely it’s not excessively slow (is it?) since hdparm shows the following:

epona:/home/rdd# hdparm -Tt /dev/hdc


Timing cached reads: 516 MB in 2.00 seconds = 257.98 MB/sec

Timing buffered disk reads: 60 MB in 3.07 seconds = 19.56 MB/sec

Should that be too slow?

Note: hdc is also the system disk, so perhaps there’s a problem with swapping; I have about 192MB or RAM installed and the system’s processor speed is 800MHz.

When using /dev/hdd, not in used with any other processes, there were similar results for hdparm, for recording with version beta 9; I still encountered problems with ardour telling me that the disk couldn’t keep up.

Thanks for any help that anyone can kindly provide with this.

Is dma enabled for the disk you are recording on? Which filesystem are you using? Have you read guides about optimizing disk performance on linux?

Hi, yes, DMA is enabled and I’ve read various guides about optimizing drive performance. I’m using the ext2 filesystem.

multcount = 16 (on)
IO_support = 1 (32-bit)
unmaskirq = 1 (on)
using_dma = 1 (on)
keepsettings = 0 (off)
readonly = 0 (off)
readahead = 256 (on)
geometry = 65535/16/63, sectors = 78165360, start = 0

When I issue an “hdparm -I” command, one thing puzzles me:

Logical max current
cylinders 16383 4047
heads 16 16
sectors/track 63 255

Did something go wrong when Linux formatted the disc, using too few cylinders and too many sectors per track? Could that be causing problems?

To simplify things, I’ve just ordered a large enough SCSI hard drive, since I already have an Adaptec 2940U installed for backups.
Still, I’m curious about the decreased
efficiency between 0.99.3 and 2.0beta10. Adding about 512MB of RAM
in the near future won’t hurt anything either. :slight_smile: Hopefully the 800MHz CPU will be fast enough for some time to come since I can’t upgrade to much faster CPU without hacking the motherboard or finding an adapter.

Thanks for continuing to look into this. I recorded the session with ardour2beta10.

One thing that I found interesting was that the first time I tried ardour2beta9, I was able to record without any problems, then all of a sudden I was unable to. There were no programs other than X with fvwm, a couple of rxvt windows and qjackcontrol, and of course some of the usuual daemons, running before and after the problem.

One thing that I haven’t tried was to try recording something shorter and see if that make a difference; the
recordings that I made, and can’t play back, are all between approximately 25 and 35 minutes in length. Also, I know that it shouldn’t make any difference, but I’m wondering if rebooting makes any difference for any reason… I’ll give that a try out of curiosity.

I have come across the same problem…however it seems to only occur while trying to playback in ardour2 an existing session created in 0.99.3. I’m yet to see it happen with a new session created from ardour2…i’ll keep looking for it though