The disk system on your computer was not able to keep up with Ardour.

36 replies [Last post]
MaxDamage
User offline. Last seen 4 weeks 1 day ago. Offline
Joined: 2010-06-02
Posts:

Hey, dear Ardour community.

I'm encountering the following problem when I try to record with Ardour:
"The disk system on your computer was not able to keep up with Ardour."
This happens after a few minutes while recording 8 tracks simultaneously via the Edirol FA-101 Firewire-Interface. (no plugins or effects added)

I'm using UbuntuStudio 9.10 with 2.6.31-9-rt Kernel and Ext-3 filesystem.
My Machine is a Lenovo N200 Notebook with 1.8Ghz Dualcore CPU, 2Gb RAM and 4200RPM SATA Harddrive.
hdparm says the following about the disk:
Timing cached reads: 1588 MB in 2.00 seconds = 794.00 MB/sec
Timing buffered disk reads: 160 MB in 3.02 seconds = 52.90 MB/sec

As I've read in other posts I've found via Google (the search engine in this forum doesn't work), SATA drives don't seem to have the necessity of running in DMA mode. (this was one of the suggestions I've already found)
Additionally, I already added myself to the "audio" group and edited the limits.conf -file (rtprio:99, memlock, nice:-19).
I tried using Freebob and FFADO with no success.

The issue occurs quite randomly. Sometimes after just a few minutes, sometimes after 20 minutes of recording. Once I "faked" the input signal on all 8 tracks (because I didn't have 8 mics to plug into the FW-Interface) by connecting the outputs from the Vlc-player to each of the 8 Inputs via Jack and started recording with Ardour. This test-run went right through, 40 minutes long, until I manually stopped it.

Thank you very much in advance for any suggestions.

Greetings,
Steffen

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

My Machine is a Lenovo N200 Notebook with 1.8Ghz Dualcore CPU, 2Gb RAM and 4200RPM SATA Harddrive.
hdparm says the following about the disk:
Timing cached reads: 1588 MB in 2.00 seconds = 794.00 MB/sec
Timing buffered disk reads: 160 MB in 3.02 seconds = 52.90 MB/sec

Your test results there are certainly false, that is faster than SSDs, and you are running your OS WITH writing to a very likely, very slow, laptop disk. I would bet your problem happens when either swapping occurs, or it needs to read information from other parts of the disk to load programs(cron etc.) which vastly lowers your performance.

There is a setting in your conf you can use to increase buffered reading and writing in Ardour to help prevent this, but it will only help you so much.(And I don't remember it off hand but if you kick me here I can likely find it later).

Seablade

dissected
dissected's picture
User offline. Last seen 28 weeks 3 days ago. Offline
Joined: 2006-08-28
Posts:

Make sure your filesystems are mounted with the "noatime" option. That can make a big difference. It prevents the OS from updating the access time on each file it reads.

MaxDamage
User offline. Last seen 4 weeks 1 day ago. Offline
Joined: 2010-06-02
Posts:

4200RPM SATA Harddrive.

Your test results there are certainly false, that is faster than SSDs, and you are running your OS WITH writing to a very likely, very slow, laptop disk

I made a mistake there: It's a 5400RPM Western Digital Scorpio (it's not the disk that came along with the notebook) which seems to be not that bad regarding performance.
Anyway, I've seen people being troubled by the same issue on their desktop pcs even though they had faster harddisks. So, I thought that this issue is not mainly due to the performance of the harddisk but must have something to do with the configuration of Ardour and/or the OS.
Another point that speaks for a not-so-well-configured Ardour is that Audacity runs fine recording these 8 tracks simultaneously. (Since I only record these tracks without doing anything else at that time, both applications do the same job, don't they?) Is Ardour using a different filetype than Audacity that needs more performance or something like that?

I am thankful for every suggestion I can get, so it would be a nice thing if you could find that option you've mentioned (buffered reading).

Make sure your filesystems are mounted with the "noatime" option. That can make a big difference. It prevents the OS from updating the access time on each file it reads.

I'll try that one, thanks! Now that you've mentioned it I've found several websites that recommend this option to increase performance.

...damn this is so frustrating cause it's like looking for a needle in a bundle of hay...

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

I made a mistake there: It's a 5400RPM Western Digital Scorpio (it's not the disk that came along with the notebook) which seems to be not that bad regarding performance.
Anyway, I've seen people being troubled by the same issue on their desktop pcs even though they had faster harddisks. So, I thought that this issue is not mainly due to the performance of the harddisk but must have something to do with the configuration of Ardour and/or the OS.

Well one thing, as I mentioned above, is you are using the OS and SWAP on the same HD as you are writing to, which SEVERELY degrades performance any time somewhere else on the disk is accessed by the OS or swap, which is more often than you would think.

The second thing is no matter what spindle based HD you are using, those read numbers you posted are completely false and I suspect the write numbers are as well. You may be able to get that with a large RAID array, or off SLC based solid state disks(REALLY Expensive), but not off a single laptop based spindle HD. I am not saying that you are making them up mind you, what I am saying is what is being reported is wrong and pretty much impossible for a single spindle based 2.5" hard drive to accomplish.

Third thing, the setting I was thinking of is in ~/.ardour2/ardour.rc and is the one that reads...


Option name="track-buffer-seconds" value="XX"

Replace the XX with the desired value, NOTE this WILL affect seek times in a session as it buffers every time you seek.

Another point that speaks for a not-so-well-configured Ardour is that Audacity runs fine recording these 8 tracks simultaneously. (Since I only record these tracks without doing anything else at that time, both applications do the same job, don't they?) Is Ardour using a different filetype than Audacity that needs more performance or something like that?

No Ardour is designed to write the audio to disk as fast as possible by default and expects you to have a fast enough disk system to do this. When running your OS, swap, and data off the same disk, this doesn't work out so well.

Seablade

peder
User offline. Last seen 49 weeks 5 days ago. Offline
Joined: 2007-05-08
Posts:

seablade, are you sure his hdparm numbers are wrong?
I tested my Compaq nx9110 3.2GHz with an IBM Hitachi 60GB 4200RPM 8MB drive and get about half his speed; 367 and 21 (tried both with Ubuntu 9.10s hdparm and a freshly compiled one).

I also tested my AMD 2000+ with a Barracuda 160GB 7200 RPM 8MB and get 260/63.

Both disks are PATA.

peder
User offline. Last seen 49 weeks 5 days ago. Offline
Joined: 2007-05-08
Posts:

MaxDamage, since the recording works when you generate the signals internally, from VLC, I'd look into the Edirol for the problem.
You shold be using FFADO since the FA-101 is fully supported by it.

Here are some pointers :
https://help.ubuntu.com/community/FireWire

jrigg
User offline. Last seen 2 weeks 4 days ago. Offline
Joined: 2007-01-04
Posts:

The second thing is no matter what spindle based HD you are using, those read numbers you posted are completely false and I suspect the write numbers are as well.

I'm not so sure the figures are wrong. I get cached read speeds of around 1GB/sec and buffered disk reads of around 75 MB/sec on several of my 7200rpm drives according to hdparm. Performance of my system seems to bear this out. I also have another system with SSDs which has substantially faster buffered disk read speeds than these, so the figures look quite plausible to me. I suspect that the problem is somewhere else.

What firewire chipset is on the motherboard?

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

I get cached read speeds of around 1GB/sec and buffered disk reads of around 75 MB/sec on several of my 7200rpm drives according to hdparm.

Yet these numbers are effectively meaningless when it comes to actual testing useful scenarios for our purposes of multitrack audio. You need extended throughput testing(So uncached for one thing, and over a long period of time), and you need to look at the MINIMUM available at any given time to determine the numbers that apply to our purposes.

A better and more accurate test at the very least is going to be using dd and copying from /dev/random or similar to disk to test writing values. I can pretty well guarantee that on a 5400 RPM laptop HD with the os also running on the drive, you will be seeing nowhere close to those numbers. To give examples...

http://www.tomshardware.com/charts/2009-2.5-mobile-hard-drive-charts/h2benchw-3.12-Min-Write-Throughput,1114.html

That is the MIN Write performance of some of the top HDs out. Note that even now they cap at 50MB/s. Likewise on the reading side....

http://www.tomshardware.com/charts/2009-2.5-mobile-hard-drive-charts/h2benchw-3.12-Min-Read-Throughput,1111.html

Similar story. Certainly NOT the 700+ MB/s reported in that post, and likely be hdparm because you need to worry about uncached minimums, when dealing with a disk system error like was asked about.

Heck just for grins and giggles, look at the minimum write speeds for a velociraptor desktop drive here...

http://www.tomshardware.com/charts/3.5-hard-drive-charts/Minimum-WriteTransfer-Performance,669.html

These are the numbers that matter to the error in question. NOT Cached or Buffered Read or Write.

Add on top of this that running the OS on the same drive will mean your best performance for this drive will be destroyed in most cases(Unless your OS runs completely from memory and you never use SWAP, which requires a significant amount of custom tuning even on Linux) you are in actuality looking at MUCH lower numbers that matter for the purpose of this test.

Hopefully that explains it a bit better.

Seablade

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

@peder

The Edirol would not cause a disk system error like is being reported. Only the disk not being able to keep up with Ardour's requests for reading/writing would cause this. It is much more likely that there are random processes causing the spindle to move to other areas of the disk and it is not able to return and write out what Ardour is requesting at a fast enough time to keep up because of this. This is why it is a MUCH better idea to write to another disk all together than to read or write from the OS disk.

Seablade

nickmurtagh
User offline. Last seen 1 year 15 weeks ago. Offline
Joined: 2007-01-22
Posts:

Hi Steffen,

The larger figure is meaningless, but 54MB/s is what I'd expect from a laptop disk. Fast SSDs are in the 200MB/s range. These are best case scenario read speeds. In the real world, any disk seeking will significantly reduce the performance for rotational disks.

I've fought this particular situation before, here is a list of things you might try, in no particular order:

- Use an external drive, eSATA would be best, followed by FW800, FW400, USB 2.0
- Use the realtime kernel and rtirq
- Make sure the CPU governer has all CPUs set to maximum performance
- If you have a big session try consolidating some of the tracks to avoid seeking (or get an SSD)
- Delete or deactivate (not mute) any tracks you don't need
- Turn off plugins when recording
- If you have formatted the disk with XFS, use xfs_fsr to defragment the disk (this is a good reason for using XFS or any filesystem that allows you to defragment it)

Some of the above are about maximising CPU, but I've seen ardour produce this error when the CPU gets so overloaded that it can't service the disk. This is more likely if your external disk is USB 2.0 which needs more CPU that eSATA or Firewire.

Nick

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

Just for the sake of clarity, one more time, the read and write numbers are completely false in terms of measuring hard drive performance for this purpose.

I realized I didn't clarify I meant for this purpose initially. As I mentioned above, you ened to look at the minimum read and write numbers, and given that there are many other processes reading and writing from disk at the same time, you will get substantially lower numbers for the minimums the moment that another area of the disk gets accessed.

Seablade

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

And Nick got all the standard advice dead on:)

Seablade

jrigg
User offline. Last seen 2 weeks 4 days ago. Offline
Joined: 2007-01-04
Posts:

I have to disagree that the speed figures are completely meaningless. The cached read speed is the speed of a contiguous data read from the cache on the hard disk, not the disk itself, so it's not really useful here. The buffered disk read speed is for contiguous data reads from the disk and is at least indicative of the performance that can be expected in a recording system, even if it isn't an exact measurement.

In practice a recording system will be unable to achieve those speeds continuously because the heads spend a lot of time moving back and forth to different areas of the disk (unless you're using an SSD) which will slow it down considerably, but I still believe that a higher reading from hdparm will indicate a higher obtainable read/write speed in a recording situation.

Back to the OP's problem, I'd be a little surprised if a disk giving the hdparm figures quoted is the bottleneck here, unless the head positioning servo is faulty.

jrigg
User offline. Last seen 2 weeks 4 days ago. Offline
Joined: 2007-01-04
Posts:

Another thing: how full is the file system? Use df to check. If there isn't a lot of free space it can get badly fragmented, which will really slow things down.

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

The buffered disk read speed is for contiguous data reads from the disk and is at least indicative of the performance that can be expected in a recording system.

And has nothing to do with write speed either which is what is needed for recording data to the disk, which is where the OP is having problems supposedly.

In practice a recording system will be unable to achieve those speeds continuously because the heads spend a lot of time moving back and forth to different areas of the disk (unless you're using an SSD) which will slow it down considerably, but I still believe that a higher reading from hdparm will indicate a higher read/write speed in a recording situation.

It will indicate a higher performance in some regard but it will not be linear in any way, so it is effectively meaningless.

Back to the OP's problem, I'd be a little surprised if a disk giving the hdparm figures quoted is the bottleneck here, unless the head positioning servo is faulty.

You already mentioned what is likely the problem, if the heads are going back and forth over different areas of the drive, which happens MUCH more frequently when running the OS and Swap off the same drive, then performance is going to take a nosedive very quickly, and not linerally either. You will be getting a fraction of the performance as a result. This is why a single drive for the OS and data is not usually preferred. Can it be done? Certainly, in fact I did it for a long time, but I wouldn't depend on it without some custom tweaking as was already mentioned above. It will be unreliable, sometimes working great and sometimes seemingly not working at all, and all it takes is that one time in a recording session to screw with things.

As I mentioned above, increase that setting to an appropriate amount that provides a balance between performance of not getting that error, and seek time in the session. Follow Nick's suggestions is preferable in most cases.

Seablade

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

Another thing: how full is the file system? Use df to check. If there isn't a lot of free space it can get badly fragmented, which will really slow things down.

This I do agree with however;)

Seablade

jrigg
User offline. Last seen 2 weeks 4 days ago. Offline
Joined: 2007-01-04
Posts:

if the heads are going back and forth over different areas of the drive, which happens MUCH more frequently when running the OS and Swap off the same drive, then performance is going to take a nosedive very quickly, and not linerally either. You will be getting a fraction of the performance as a result. This is why a single drive for the OS and data is not usually preferred.

Agreed :-)

jrigg
User offline. Last seen 2 weeks 4 days ago. Offline
Joined: 2007-01-04
Posts:

To add to Nick's comments, it can be beneficial to copy all of the data to another drive and then back again every once in a while if you're using ext3. I do this whenever I notice fsck reporting more than a few percent of discontiguous data on my audio file system (which is on a different disk than the OS). Heavy editing in particular can cause a lot of fragmentation even if there's plenty of space left on the disk.

paul
paul's picture
User offline. Last seen 3 hours 49 min ago. Offline
Joined: 2006-03-16
Posts:

Heavy editing in particular can cause a lot of fragmentation even if there's plenty of space left on the disk Editing in Ardour doesn't cause any disk fragmentation whatsoever. Nothing gets repeatedly written to disk except the session file, the history file and (probably) some backup session files.

jrigg
User offline. Last seen 2 weeks 4 days ago. Offline
Joined: 2007-01-04
Posts:

I stand corrected. I should probably have said "heavy editing, then re-recording the edited sections to new tracks while simultaneously trying to do multiple overdubs and generally getting the session in a mess", which is the self-inflicted scenario that usually leads to fragmentation problems on my system :-)

itsgeorg
User offline. Last seen 47 weeks 5 days ago. Offline
Joined: 2007-01-19
Posts:

.. may I add my comment?

For long time I feel that this disk ".. not fast enough .." message/behavior is just a weak point in Ardours recording buffer algorithm. If enough RAM available, with a half way capable notebook harddisk, it shouldn't happen. Ardour should buffer to extra RAM. I have unlimited RAM in limits.conf, a rt-kernel, swap off. Every other day I get this message when doing 10 track recording with RMEs multiface.

Maybe the message itself isn't pointing in the right direction in every case.

For playback only, the seek time of the harddisk should become more relevant. (The before mentioned parameter "track-buffer-seconds").

Anyway, Ardour is one of the greatest programs I can run.

paul
paul's picture
User offline. Last seen 3 hours 49 min ago. Offline
Joined: 2006-03-16
Posts:

@itsgeorg: For long time I feel that this disk ".. not fast enough .." message/behavior is just a weak point in Ardours recording buffer algorithm. If enough RAM available, with a half way capable notebook harddisk, it shouldn't happen. Ardour should buffer to extra RAM. I have unlimited RAM in limits.conf, a rt-kernel, swap off. Every other day I get this message when doing 10 track recording with RMEs multiface.

There's no reason for any contemporary system to ever get this message unless some part of it is not working correctly. You suggest that Ardour should just use more RAM - this is not really feasible. The place where we realize that things are too slow is in a realtime thread. This thread cannot safely allocate big chunks of memory. This is why recording (and playback) happens via two *BIG* lock free ringbuffers. These buffers are 5 seconds per track by default (one for playback, one for capture) When you see this message it means that your system was unable to keep data flowing to/from these buffers for 5 seconds. That is ridiculous behaviour. If it occurs, the realtime thread isn't in a position to do anything about it, including allocating more memory.

Moreover, the message covers both capture and playback. If it occurs for the playback buffer, there's nothing that allocating more RAM there and then can do. The data needed to be delivered for playback is missing: game over.

As Seablade indicated you can choose to increase the amount of buffering in RAM if you wish. But really, a system that can't keep data flowing reasonably smoothly with 5 seconds worth of buffering in each direction is probably a system that shouldn't be used for multitrack audio.

itsgeorg
User offline. Last seen 47 weeks 5 days ago. Offline
Joined: 2007-01-19
Posts:

Thanks for clarification.

Will increase the buffers to 10 seconds, which would not hurt here at all, and 5 seconds doesn't seem to me so shure of a bet with all that reasonable system activity beeing on.

The more mediocre/universal systems can do recording, the better :)

MaxDamage
User offline. Last seen 4 weeks 1 day ago. Offline
Joined: 2010-06-02
Posts:

phew, okay, this issue seems to draw more attention to it than I thought. :)
thanks for all the advice!

@Peder
Like Seablade already mentioned, I think the Edirol device itself is not the problem. I had a look at the instructions on how to set up firewire in ubuntu studio (the link you posted) and found that firewire devices are not given maximum priority by default. Maybe this is something that contributes to the problem. Though, it is quite strange that the recording sessions with internally generated signals from VLC went through without any glitches. Maybe the firewire connection uses up a lot of cpu load additionally and that, combined with the hard drive issue, generates the error message?

@Seablade
The figures I was provided with from hdparm might not be correct as you suggested, but since the actual performance of the disk doesn't seem to be the problem in the first place, I don't mind that much. :)
It's a good thing to know that having separate disks for the OS and for Audio production is recommended. I didn't know that this causes that much of a problem. (I thought that using separate partitions does the trick already...)
If I were to use an external drive for recording via FW400, could the firewire bus be a bottleneck performance-wise?

@jrigg
I'm not sure about the firewire chipset. Device manager tells me the following:
R5C832 IEEE 1394 Controller
Ricoh Co Ltd (Lenovo)
I already thought about getting a firewire expresscard so I can use the 6-pin FW cable (the notebook default is only a 4-pin connection so I have to use the external AC-adapter for the edirol device, which is quite annoying). Could this also provide an improvement in this case?

As I've learned now my system with it's present configuration is obviously not the one of choice for audio production.(well okay, I already thought that this would be the case)
Still, there has to be a way to get Ardour running at least a bit more smoothly with this system. The way Audacity handles multitrack recording flawlessly even on my recording setup (without any tweaking beforehand) shows that the task is technically feasible on this system. (or is there some fundamental difference between Ardour and Audacity when it comes to plain recording tasks?)

Special thanks to Nick for your composition of useful suggestions. I'll follow your suggestions and tell you later if it worked.

Thank you all for your contribution!

Greetings
Steffen

philip8888
philip8888's picture
User offline. Last seen 1 year 1 week ago. Offline
Joined: 2007-03-30
Posts:

@MaxDamage

Yes using a firewire drive and a firewire audio will cause a bottle neck for the firewire bus on your lappy.
Getting an express card for an extra firewire device would be the ticket.
This is the set up I use on my MBP.
SIIG Express Firewire
http://www.sweetwater.com/store/detail/FWCardExpCard2/
I connect my M-Audio 410 to the the express card and I connect my external hard drive to the firewire connection one the MBP.
The drive you write audio to should be a 7200 RPM drive. No Lower.

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

If I were to use an external drive for recording via FW400, could the firewire bus be a bottleneck performance-wise?

If they are on the same bus, yes it will be. As phillip8888 pointed out the better solution would be to seperate it onto a seperate FW800 bus for the hard drive, or eSATA for the Hard Drive.

Or of course not use firewire for audio but I think that is less likely given you already bought the interface;)

For the record Paul and I do disagree with the assessment on some level of what constitutes an acceptable system in this regard and we have discussed it at length before. That being said, the basic premise of his point is perfectly valid, that if you are having issues with writing for a period of 5 seconds, you really shouldn't be using that setup for multitracking. This is absolutely correct, though I do often get forced to use less than ideal setups, for instance my laptop which has become my primary machine as of late, which is why the option I posted above exists, so that I can compensate for that in some way and at least increase my chances of a successful recording..

Seablade

MaxDamage
User offline. Last seen 4 weeks 1 day ago. Offline
Joined: 2010-06-02
Posts:

I've recorded a session yesterday and it worked without glitches for over 30 Minutes. (which is quite a success!! :) )
All I've changed so far was adding the "noatime" -parameter for the mounted drives.
I guess I'll change that buffer-thingy in the ardour config as well just to be on the safe side, but it seems like the "noatime" option did the trick for now.

Sure, you're right: For professional use the system i'm using right now would certainly be unacceptable. But since I'm doing this as a hobby I don't want to spend another hundreds of €uros on hardware (which I already had to spend for the interface and a mixing console). So if there is a way to get things running with the present hardware I have then things are perfectly fine, even if its not the best possible way of doing this.

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

@MaxDamage

Glad it is working for you. I wouldn't change the buffer settings unless you need to, if you simply didn't have the noatime parameter and that is all you needed, glad it is a relatively simple fix then.

Seablade

wolke
User offline. Last seen 1 year 13 weeks ago. Offline
Joined: 2007-06-28
Posts:

hi,
some times left i have the same problem with a laptop. i try to record 10 tracks simultaneous and ardour stop recording with a message something like (i don't remember the exact message) my drive is not fast enough.

what ever, i try to locate the problem and found no solution into my hardware set-up. everything was ok. i make some test with 16 tracks simultaneous and it works. the different was, that the test with 16 tracks was into my home-studio and the real recording situation which fails was into our practice room with much volume and bass - vibrations.

what's going wrong? into the practice room i have the disk writing problem and into my home studio with less volume and vibrations everything works fine.

my disk was unable to write successfully because the drive head becomes tracking problems with to much volume ( vibrations).

i solve this problem. i build a vibration absorber for my laptop. two plates of 8mm plywood with 4cm thick soft foam between.
i stick all together with contact glue which don't degenerate the foam.
works perfect for my. now i can record into loud environment without problems.

as i say this is only an other idea and maybe not your problem.
greetings wolke

MaxDamage
User offline. Last seen 4 weeks 1 day ago. Offline
Joined: 2010-06-02
Posts:

hm, this sounds funny somehow because this solution is far from being as 'technical' as the others, but why not!
I actually had the feeling that this had something to do with the recording environment. As I mentioned, I had no problems recording at home while everything seemed to run right out of order when I entered our rehearsal room with my notebook.
Maybe increasing the buffer in Ardour is just a workaround for that vibration caused problem?
Though, if this was the case then it's still quite mysterious why Audacity did the recording job flawlessly right out-of-the-box...

oh and btw.:

Another point that speaks for a not-so-well-configured Ardour is that Audacity runs fine recording these 8 tracks simultaneously. (Since I only record these tracks without doing anything else at that time, both applications do the same job, don't they?) Is Ardour using a different filetype than Audacity that needs more performance or something like that?

No Ardour is designed to write the audio to disk as fast as possible by default and expects you to have a fast enough disk system to do this. When running your OS, swap, and data off the same disk, this doesn't work out so well.

Seablade

you didn't quite answer my question. Sure, Ardour might be set to write to disk as fast as possible and of course a fast enough disk is required then but what does Audacity do differently so that there's no error occuring when recording with it?