No but thumb drives don’t always have the best performance so you may have been seeing just general performance errors there. Especially depending on how many tracks you were writing out at once.
SeabladeThanks Paul. I did find that in my research into the issue. To test for this, I tried setting up the project on a 8G thumb drive. To my amazement, I got the same error. Unless there is some intermediate step where data is written first to the HD, then to the project file location on the thumb drive, I don’t think the bass frequencies could be causing this. Am I thinking about this correctly?
@Aaron: the default in A2 and A3 is 5 seconds in both directions.
One other thing to be aware of that can seem a little unbelievable when you first hear about it. If you have the computer doing the recording inside the recording environment, then high levels of bass can cause errors with the disk that will sometimes be the sole cause of these “disk subsystem cannot keep up”. This issue has been seen with systems running Linux, Windows, OS X and a variety of DAWs other then Ardour. One early user of Ardour was using laptop and was unable to get reliable behaviour until he put the laptop into a semi-isolated spot within the room. Ardour would of course run completely reliably when he tested without the band actually playing. I’m not sure of the precise frequency range(s?) that can affect conventional drives in this way, but its fairly well documented. Its also another benefit of using solid state disk drives.
First of all, I appreciate all of the attention to my issue. I can’t tell you how much it means to be able to get input directly from the likes of you guys. It’s been said many times but this is what makes this community so special.
Seablade and Paul - I had no idea I could tweak the disk buffers with A2. I searched for solutions for this issue and spent some time in the IRC looking for help and no one mentioned this. Anyway, I now understand why the A3 feature is described as the capability to ‘dynamically’ adjust the disk buffers. Dynamically = in the app with sliders instead of tweaking config files. I think I’m going to set it at 10 seconds and see what happens. What is the default in A2? Is disk buffering fundamentally more robust in A3 or is the new thing simply access from the application to tweak the buffers? (I won’t be offended if you redirect me on this question since I know we have been asked to discuss A3 elsewhere)
Also, I do understand the distinction between latency in the traditional digital recording sense and the sluggishness that can result in the buffers being large. Thanks for that clarification.
GMaq - Thanks also for you input. Being fairly technical but still a relative noob in Linux and Linux audio recording, I very much like what you (I’m assuming you are closely associated with AVL) have done with AVL, particularly with all of the pre-installing and pre-configuring. Brilliant stuff. I will definitely be watching for an AVL release with A3 installed and ready to rock. I know with Ubuntu I’m getting a lot of overhead not contributing to recording. Ultimately, I know AVL is a better solution. I will watch for 6.0. Are you planning to have A3 included or just prepared for it?
For the record AV Linux comes with a LOT of plugins pre-installed and over the last few months it has come to light that some of the older JUCE-based LinuxVST Plugins in AV Linux 5.0.3 can cause Ardour 3 to segfault or behave badly while creating a session. At the AV Linux forums there is info and updated plugin packages to alleviate these issues and AV Linux 6.0 coming in June (hopefully) will have these updated plugins all sorted out and if all goes well (*subtle hint Paul) also ready to use Ardour 3 packages with support for LV2, Linux VST and an alternate Windows VST build.
If you are content with Ubuntu then by all means go with that, just thought I’d offer an explanation and make you aware that Ardour3 can and does run magnificently on AV Linux 5.0.3. 
Yes that is what I intended to convey, apologies for not being clear. The latency Iw as talking about in this case wasn’t to do with audio hardware IO latency as much as latency when jumping around and selecting new points on the timeline and hitting play, etc.
Seabladeseablade: the buffer size doesn’t have any relationship to “latency” in terms of the audio signal, and thus “latency compensation” has nothing to do with it. it might be better to say “bigger buffers lead to reduced responsiveness when locating to a new position on the timline”. the program has to fill up the buffers first, and this takes more time the larger the buffers are.
You can actually adjust the buffers in A2 as well, but you have to edit a text file and it adjusts playback and capture both identically.
Playback buffer means more latency and less responsiveness when starting palyback. No real drawback as long as latency compensation is properly set up for it.
Capture buffer effects when audio is written to disk, there is conceivably the chance for more data lost if Ardour does crash, but in all honesty this is rarely an issue.
Personally in A2 to record multitrack(between 24 and 60 track) events I set my buffers to 60 seconds. I would recommend your capture buffer to be about this in A3 as well myself, but to each their own. It should be high enough you don’t see those messages, period, any higher and it may not be needed but likely won’t hurt so long as you don’t crash Ardour.
SeabladeOK. I’ve got A3 running now on Ubuntu 12.04 (crashed on AVLinux but that’s OK, I would prefer to get it running in Ubuntu). I found the buffers. What I found are not labeled as disk buffers but I assume ‘playback’ and ‘record’ buffers are disk buffers. Default is 5 seconds. What setting should I use to insure I don’t get the error? I assume that larger is better. What is the drawback to setting the record buffer very high? Is A3 going to be better for this issue right out of the box with the default setting?
In any case, I will be able to test this Wednesday during the next rehearsal. Hoping this resolves this issue!
Thanks!
Aaron
@Aaron: the precise conditions are very simple: the playback buffer is empty and/or the capture buffer is full. This means that the system has, for any number of different possible reasons, failed to keep the flow of data between Ardour and the disk moving quickly enough. Its not possible to be more specific than this. The reasons can include many different aspects of your system, both software and hardware.
For playback ONLY Jack can run in a more “forgiving” mode, so you can raise your Periods/Buffer to a higher value, this is usually helpful during Mix/Mastering since you will be adding more fx plugins and real time monitoring is not necessary and will help you prevent xruns.
EDIT: Ah I also see you are connecting/running JAMIN which is a very intensive application and could also be causing you some xruns, so try with higher Period/Buffers as I mentioned, might help…
@linuxdsp - What might you suggest? I’d say the features of Jamin I appreciate most are the 3-band compression, its all-in-oneness, and the graphical representation in one place of all of the functionality. Given that, are there alternatives to consider?
what linux dsp suggests, is using his plugins instead, and he s right with that! 
also with zero budget i think it s better to just use the available plugins than jamin, i m not sure about that, but jamin hasnt been developed since along time…
Your audio quality will also improve if you don’t use JAMIN…seriously. It served a useful purpose a long while back, but there are now many far superior alternatives, most of which will not consume anything like as much CPU either.
OK. Finally and update. We had rehearsal tonight and no disk errors! Here’s what is different since the last time I unsuccessfully recorded:
- I’m on Ubuntu 12.04 w/Unity
- I’m running A3 beta
- I changed the disk I/O buffer (record) to 20 seconds
- I moved the laptop from on top of my bass rig to somewhere potentially less prone to vibration and/or electro-magnetic interference
If I had time to approach this scientifically, I would have changed one thing at a time, then tested, so I would be able to pinpoint what actually solved the problem. I don’t so I didn’t. I’m calling this solved but I wish I could contribute a more precise solution back to the community.
I have new issues, however. During playback/mixing, I’m getting periodic drops and gargles and this is what Jack is saying about it:
23:14:59.938 XRUN callback (3 skipped).
23:15:09.476 XRUN callback (933).
Wed Jul 11 23:15:09 2012: e[1me[31mERROR: JackEngine::XRun: client = jamin was not run: state = 1e[0m
Wed Jul 11 23:15:09 2012: e[1me[31mERROR: JackEngine::XRun: client = ardour was not run: state = 1e[0m
Wed Jul 11 23:15:09 2012: e[1me[31mERROR: JackAudioDriver::ProcessGraphAsyncMaster: Process errore[0m
Wed Jul 11 23:15:09 2012: e[1me[31mERROR: JackAudioDriver::ProcessGraphAsyncMaster: Process errore[0m
Wed Jul 11 23:15:09 2012: e[1me[31mERROR: JackAudioDriver::ProcessGraphAsyncMaster: Process errore[0m
Wed Jul 11 23:15:09 2012: e[1me[31mERROR: JackAudioDriver::ProcessGraphAsyncMaster: Process errore[0m
23:15:10.079 XRUN callback (1 skipped).
23:15:19.451 XRUN callback (935).
Wed Jul 11 23:15:19 2012: e[1me[31mERROR: JackEngine::XRun: client = jamin was not run: state = 1e[0m
Wed Jul 11 23:15:19 2012: e[1me[31mERROR: JackEngine::XRun: client = ardour was not run: state = 1e[0m
Wed Jul 11 23:15:19 2012: e[1me[31mERROR: JackAudioDriver::ProcessGraphAsyncMaster: Process errore[0m
Wed Jul 11 23:15:19 2012: e[1me[31mERROR: JackEngine::XRun: client = jamin was not run: state = 1e[0m
Wed Jul 11 23:15:19 2012: e[1me[31mERROR: JackEngine::XRun: client = ardour was not run: state = 1e[0m
Wed Jul 11 23:15:19 2012: e[1me[31mERROR: JackAudioDriver::ProcessGraphAsyncMaster: Process errore[0m
Wed Jul 11 23:15:19 2012: e[1me[31mERROR: JackAudioDriver::ProcessGraphAsyncMaster: Process errore[0m
Wed Jul 11 23:15:19 2012: e[1me[31mERROR: JackAudioDriver::ProcessGraphAsyncMaster: Process errore[0m
23:15:20.086 XRUN callback (3 skipped).
23:15:29.621 XRUN callback (939).
Wed Jul 11 23:15:29 2012: e[1me[31mERROR: JackEngine::XRun: client = jamin was not run: state = 1e[0m
Wed Jul 11 23:15:29 2012: e[1me[31mERROR: JackEngine::XRun: client = ardour was not run: state = 1e[0m
Wed Jul 11 23:15:29 2012: e[1me[31mERROR: JackAudioDriver::ProcessGraphAsyncMaster: Process errore[0m
Wed Jul 11 23:15:29 2012: e[1me[31mERROR: JackEngine::XRun: client = jamin was not run: state = 1e[0m
Wed Jul 11 23:15:29 2012: e[1me[31mERROR: JackEngine::XRun: client = ardour was not run: state = 1e[0m
Wed Jul 11 23:15:29 2012: e[1me[31mERROR: JackAudioDriver::ProcessGraphAsyncMaster: Process errore[0m
Wed Jul 11 23:15:29 2012: e[1me[31mERROR: JackAudioDriver::ProcessGraphAsyncMaster: Process errore[0m
Wed Jul 11 23:15:29 2012: e[1me[31mERROR: JackAudioDriver::ProcessGraphAsyncMaster: Process errore[0m
23:15:30.134 XRUN callback (3 skipped).
I exported the session as a wav and it appears to be clean so whatever is happening appears only to be impacting the playback.
This may just be a noob issue but if this is an A3 issue, I will be happy to post this on the mailing list.
CPUs are at 50%. I did notice some wierd graphics behaviors in Jamin. . . like the GPU couldn’t keep up with everything and the refreshs on the Jamin display had lots of freezes. Anyway, if someone could point me in the right direction on this new problem, I would appreciate it.
Hi!
Just stumbled across this thread and recalled that I had very similar problems with the “disk can’t keep up…”-message.
Here’s the previous discussion about it:
http://ardour.org/node/3609
In my case as well as in the case of “wolke” (at the bottom page of the discussion posted above) the problem that caused the error message was due to vibration in the rehearsal room.
Increasing track-buffer seconds can compensate the vibration-induced disk latency.
(in ardour 2 you can find the config file to change this setting here: /home/user/.ardour2/ardour.rc )
Better solution would be to cushion or damp the laptop and protect it from vibration.
Been away for a while and see this thread still has some life. . . .
I am pretty much satisfied that my issues had to due with physical vibration. The band I am in that is doing the recording stuff hasn’t been together much recently. We will be getting back to it, however, and I will be able to continue to test this. Last time we got together, simply moving the laptop off the top of my bass rig seemed to resolve the issue.
Also, based on some advice in this thread, I have put Jamin aside and built my own on a bus with Calf plugins . . . seems to do what I need and more efficiently.
Aaron
I installed a rubber fixation device for my harddisc in my desktop to get it silent. This could perhaps be a solution for vibrations in a loud enviroment, too. Isn´t it?
An elastic suspension for your hard drive will protect it from equipment case vibration, but not air vibration. So it may solve the problem sometimes.
Hi Aaron, I now read the whole post.
How do you solve your second big problem??
I mean this…
e[1me[31mERROR: JackEngine::XRun: client = ardour was not run: state = 1e[0m
e[1me[31mERROR: JackAudioDriver::ProcessGraphAsyncMaster: Process errore[0m
I have the same problem and it’s very frustrating because i can’t get the solution for weeks and it’s quite impossile to mix down or even playback the tracks. The cpu overloads and there is a great amount of xuns.
It seems a plugin issue, but it’s strange because it happens with all plugins (that I used to use…)
Here’s a link of the specific tread of the forum I created in relation to this problem.
Any hint? thank you!
Lorenzo
(my setup…)
processor: Intel® Core™ i7-2600K CPU @ 3.40GHz × 8
os: Ubuntu 12.04 32bit with kxstudio repos , low latency kernel
soundcards: Alesis i/o2 (usb) or RME hammerfall 9652 (pci)