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.
@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..
Thanks everyone for you input!
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:
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.
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.
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.
Hi Aaron, I now read the whole post.
How do you solve your second big problem??
I mean this..
[1m[31mERROR: JackEngine::XRun: client = ardour was not run: state = 1[0m
[1m[31mERROR: JackAudioDriver::ProcessGraphAsyncMaster: Process error[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!
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)
On the subject of the "disk can't keep up" errors I got this recently exporting a session using the option "range markers into separate files".
This is a very simple session with just a limiter plugin so, as the export speed is much faster than playing the session I assume the playback speed no longer has timing tied to sound hardware so surely wouldn't you expect the disks speed to be the limiting factor and, as such, shouldn't ardour be waiting for the disks to provide the data? What else might be happenning?
This is ardour 2.8 BTW. Ardour 3 Beta 5 does not seem to suffer from this problem - instead it gives random xruns when doing nothing at all, i.e. with the transport stopped.
I have never seen this on an export, so my first question is what version of 2.8 exactly?
Hey, I noticed in this discussion someone saying that there's a text file in Ardour 2 that can be modified to increase the buffer size so this annoying issue goes away. Can anyone point me to the file and tell me exactly what needs to change? If so, that would be great!
Can't wait for Ardour 3 for Mac!
Or, would adding more RAM make this go away? I only have 2Gbytes.
Going off memory...
id just like to add a note about hard disks and vibrations. it should be known that excessive vibrations can cause issues with hard disks.
some laptops do have a safety feature that will park the heads if excessive vibrations are detected. this is to minimise the risk of damaging the surface of th disk or the heads. Obviously this will cause a delay in being able to write or read form the disk.
I know too well of these issues as a live engineer when working with bands using laptops. Had it happen to me just a few weeks when a band was using a mac book to close to the pa, the backing track would start jumping and had to cut out some sub from the PA.
Pretty much the vibrations can cause a hard disk to "skip"
I a rehersal situation you might find that you may have to reduce the bass on the amp. I know bass players love having tons of bottom end, but whats the most important thing. hearing the bass. this applies live aswell. On stage you just need to hear yourself playing and not worry abotu how it sounds "outfront"
Shomewere in the "past" in this thread was mentioned that
harddisk is partitioned for "os-es". As i can understand an internal
hd of one "laptop" with 3 or 4 OS-es! Right?
This is bad idea. Poor HD head is running like mad looking for "OS partitions".
And also JAMIN isnt friendly software for a whole running system.
made a lot of testings on diferent notebooks with suse 8.2...( in 2003, used ardour on suse machines and was blown with
-|opensource-"Pro Tools" |- solution
Linux "always as one own" partitioned
system and recorded on external drives ( usb 1.0 or 2.0 ) but never used jamin paralel to ardour on sessions.
And never got such a " vibratons troubles" .
(if so, move your hd away from LF sources)
I know this might be sounding arogant but:
People must know their Computers and configurations.
Swap and swapiness (Its nowhere mentioned how its configured )
All that ACPI and APM things, swap tools, hdparm tools, cpu scaling, software bugs and so on and so on.
Good start point is inside A/V Linux Manual but its not only source of knowledge.
I whish you a lott of patience and "microscopic" researches of your Machines.
and so on
there is so much to know and it´s a MUST THING.
Search, print those manuals and read it, learn, its important.
But what does this mean?
Going off memory...
Partitioning the hard drive for each os is not only recommended, in many cases it may be required. Assuming we are referring to mechanical hard drives, if the hard drive is partitioned like this it is going to cause the heads to search within the partitions, not the entire disk, which depending on the layout of the disk in many cases can be better than simply using a single partition.
Maybe you meant it is better to have the OS and the data on seperate drives? In which case you would be absolutely correct, at least in the case of mechanical hard drives. It is far less of an issue on solid state drives though.
In as far as vibration issues, veda_sticks is absolutely correct when referring to mechanical drives. This can be a huge problem on occasion, particularly for DJs, but even on louder live stages. And sometimes moving the HD away from these sources is not a practical solution. In these cases, SSDs are again the better option.
Not to say SSDs are a be all and all solution, just that they can be a good improvement in several circumstances, but a poor SSD can be worse in other circumstances than a good mechanical drive.
That is the text file you asked about you would want to edit to increase your buffer size in Ardour2 on OS X (or Linux) for live recordings.
Yeah, I had just found another thread with info on how to locate the file. I'll put it here in case other's need it. On a Mac press Option+Shift+G and paste or type the file name (~/.ardour2) without the parenthesis, and you will see the file. I opened it with Text edit and increased the buffer size to 60, but it really didn't see to help. So I went and increased it to 100 and it was just as bad. Now, I've put it back to 5 secs.
This is very frustrating as I'm more than half way through tracking a CD project with Ardour 2.8.16 and now am having all kinds of sputtering (farting sounds) during playback AND the hard drive can't keep up warning.
I really want/need to get this running smoothly again and can't find out how.
My set up is:
Focusrite Liquid Saffire Firewire interface
Jack Pilot OSX .089
MacBook 2GHZ Intel Duo Core
I would greatly appreciate any input on how to get things running smoothly again. Seemed like we were fine when doing tracking, but now as I'm adding effects and doing some other editing (slicing, dicing, copying and pasting) Ardour can't keep up. Please help if you've had the same experience and have overcome the issue(s).
And, I just left the room and came back and it crashed. :-(
Well my first question would be, what is your DSP percentage at? I suspect you are approaching the limit of your computer in as far as effects from the sounds of it, and you may have to look at ways to use things more efficiently, for instance running with larger latencies if you aren't actually tracking (And even if you are so long as latency compensation is correct)
With the text file buffer set to 5 seconds, my DSP is running around 60% and the "p" and "c" Buffers (don't know what the p and c stand for) are in the upper 90% all the time. Ever now and then it craps out and makes a horrible buzzing sound. When I increase the buffer up to 60 in the text file (a possible fix) it made it worse but the "c" buffer (cache?) was a lot lower, but the "p" buffer was at 99% and the DSP was in the teens (I think).
Would more RAM help or is this a buffer or processor speed issue(s)?
90% is pretty hard, your probably getting to the limits of the core 2 duo. 2ghz is not that fast by todays standards, i start struggling with my 64 bit amd 2ghz dual core when working with multiple tracks and plugins. Especiallay when using pitch shifteres.
you may need to bounce tracks that you are happy with all the processing to free up some cpu . theres an option somewhere to bounce with processing or something like that
@StuartJoseph: "p" and "c" are the playback and capture disk buffers respectively - the percentages are how full the buffers are, and these should ideally be near to 100%. If they reach 0%, that's when you'll get "Disk can't keep up with Ardour". Seems odd that increasing the buffer from 5 to 60 seconds made things worse: I have no idea why that might be...
what kind of internal drive do you have. IDE or SATA?
Seems odd that increasing the buffer from 5 to 60 seconds made things worse: I have no idea why that might be...
It might be that using extra memory for those buffers is taking away memory from some other process or the file system's disk cache.
Thanks for all the help/troubleshooting.
veda-sticks, I have a Serial-ATA HD.
I have multiple takes of several instruments (like three bass tracks, etc.). I think these tracks use resources even if they are muted. If this is the case, I think I need to decide which parts of which tracks to keep and merge those various parts from various takes into one track. That should free up some resources. But, having said that, I'm still not finished tracking or using plugins so my needs are likely going to increase even after I merge these multiple takes into one track.
I worry about bouncing a track with plugins because what if I want to modify the settings later on? I don't even know if that's possible unless I keep multiple files (which I do) and open a previous version and re-bounce. What a hassle. Ugh!
theres an option in ardour to silence plugins when transport is stopped, it wont help with issues during playack. theres also some options to handle denourmals which can cause dsp sues if a plugin isnt coded correctly to handle denourmals.
an option maybe to group certain tracks, record them to new tracks and then disable all plugins from the origional channels and mute them. that way you could go back. But it would mean alot of clicking stuff.
record the drums onto a new stereo track, then say guitars onto another stereo track, bass to a new mono track etc
Stuart, you're correct in thinking that muted tracks take up some resources.Up until recently I was using a rather old system as my main studio machine, and on larger sessions I definitely had to coddle it and be very cognizant of my resources. This meant sub-mixes, tough decisions about takes, and track bounces - very much like my old 4-track tape deck days, but with better fidelity!
Increasing your RAM is definitely the single best thing that you can do to help. Ardour is pretty RAM intensive, but operating systems have a trick when the demands on RAM get high called swapping. The OS will take chunks of RAM that have been less-accessed for a while and write them to disk, and will read those chunks back into RAM as needed. This will keep things running, but more slowly. If one of these chunks happens to be audio that Ardour needs to play back, it's very likely that it'll take too long for seamless playback.
You're probably aware of this, but before starting Ardour, make sure that all other programs have been quit from, not just minimized.
I understand your situation where you're tracking and aren't close to deciding the final effects or even takes, but that's OK. If you make a "scratch" mix track to record to and remove the tracks used to create that track, the recorded regions are still there. You can always add tracks later and bring in the original regions again. This loses any plugins you may have had but that's where good note taking comes in. If a take has been edited, bounce that to a track and you can pull that region in later.
Thanks for the help!
I ordered more RAM today and hope that will help. I also have a lot of takes of instruments with two tracks (two different mics/mic placements). I will merge each take into one track and that will save some resources. BUT, right now, I'm running into this problem and I'm not using effects on every track. I'm running six guitar tracks through one Bus and putting effects on the bus instead of each individual track. Can't imagine what would happen if I tried to but effects on each track instead.
Anyway, I'll report back what, if any, improvement the RAM has.
Thanks again for all your help!
Your subscriptions & donations are critical help that make it possible for full-time development of Ardour to continue. Your support is critical and much appreciated.
July goal US$6200 (US$74.4k/yr)
Subscribers 3052 US$7852.00/month
Support Ardour, get free upgrades: pay $1, $4, $10 or $50/month: