2.8.??
I have never seen this on an export, so my first question is what version of 2.8 exactly?
SeabladeOn 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.
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!
Thanks,
Stuart
Or, would adding more RAM make this go away? I only have 2Gbytes.
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)
Finitto!
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.
https://dl.dropboxusercontent.com/u/10573557/SuSE-DAW%20v2.pdf
https://wiki.archlinux.org/index.php/Pro_Audio
http://www.redbooks.ibm.com/redpapers/pdfs/redp4285.pdf
and so on
there is so much to know and it´s a MUST THING.
trust me.
Search, print those manuals and read it, learn, its important.
Nedzad
Sorry Seablade,
But what does this mean?
Going off memory…
~/.ardour2/ardour.rc
Thanks,
Stuart
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.
SeabladeThanks, Seablade,
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
2G RAM
Mac OS10.6.8
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).
Many thanks,
Stuart
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)
SeabladeWith 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)?
Thanks,
Stuart
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.
Good luck!