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 
… 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.
@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.
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
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
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
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.
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…
SeabladeI’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.
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.
Seabladehi,
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
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?
@MaxDamage: audacity uses a lot more audio hardware buffering than typical JACK+Ardour configuration.
Thanks Paul, now I got it. So actually Seablade did answer the question and I just didn’t get it.
@Dissected: hehe, this is quite an interesting way of testing things.
So, I’ll reset the buffer time to 5 seconds and instead, try cushioning my notebook next time I’m in the rehearsal room. I’ll post the results afterwards.
btw.: keep up the good work! I mean forum/support- as well as Ardour-wise!
Hey, just a short feedback on the cusioning-thing:
it worked fine!
Yesterday I´ve recorded hours-long sessions and it worked without any problems.
I wouldn’t have thought you have to be that cautious when recording in a live-environment. Good to know.
Again, many thanks to all of you who contributed to the solution!
I’ve been having this same problem for a few weeks now - the system works just fine in a controlled setting (electronic drums and all guitars plugged directly into the mixer) but produces this same “disk system was not fast enough” error when recording in a “live” environment with acoustic drums, loud guitars and the like. I have tweaked and tweaked the system to no avail and haven’t seen any promise in the forums until I stumbled across this thread. I’m going to try the external hard drive, setting the disk to “noatime” and using a foam buffer to reduce vibrations and see how that works. Thank you all for the informative posts!
Is it ok if the OS is not updating the access time? I hope I would not end up trying to fix computer errors in the long run.