Hi. First thing made with Ardour. Running on OpenSuse 13.1.
Thanks.
Doh! It helps if you paste in the right URL:
Cool - great guitar playing, and very good production, thanks for sharing.
Thanks so much!
I’m excited can do this stuff on Linux now… ;^)
You got a great sound for your first try using Ardour and you sure packed a lot of melody into a song under 3 minutes.
Thank you for checking it out!
It took me a little while to get my head wrapped around Jack and how things connect together. It was different than what I was used to. But it’s really powerful. Also all the available plugins sound amazing.
Hi,
As was said before a very impressive first production on Ardour! Great job! I am also a longtime Hydrogen/Ardour combo user and if you haven’t already heard about what’s going on on the development version of the next Ardour release it’s MIDI stability and capabilities have far surpassed 3.5.403 so the potential for drum programming within Ardour itself has greatly improved which doesn’t necessarily make using Hydrogen passe, it just adds even more options…
Thanks GMaq. Yes, I’ve used midi for drums before in other systems. I think midi region cut and paste can be easier to work with sometimes, but I do find the hydrogen interface more intuitive for drum stuff. I could see going back and forth for some things.
Yes, I heard that next version will have better midi support. I tried a couple of the nightly builds but not working for me. Soon as I try to play any file it complains that disk can’t keep up with audio. Figured would wait for next release and see how that goes.
what platform are you running Ardour on? The disk-can’t-keep-up is a known issue (with no good solution) on OS X, but if it happens on Linux then it suggests something is fairly “wrong” with your system.
Goto Edit->Preferences->Audio and change the playback buffer to something like 20 seconds. It is a current problem with the latest Dev version that playback will fail with the default settings (which I think are 5 seconds).
@Paul: Why is there “no good solution” on Mac? I run Logic, Cubase, Reaper, Sonar etc etc on Mac(s) (and / or Windows) for development / testing without problems. Ardour hasn’t disgraced itself recently in that respect either (on linux) although I confess the only time I’ve ever had problems in the past with disks seemingly being “too slow” was with Ardour. This would suggest it was something unique to Ardour rather than anything OS - or even OS X - related?
We don’t understand it. A LOT of work has gone into diagnosing disk i/o performance on OS X. It is really terrible. You can run Ardour on Windows hosted as a guest OS on top of OS X and it works much better than when run natively on OS X. OS X shows much stronger dependence on number of files being written to than any other platform. A disk capable of 100MB/sec will slow to 5MB/sec for long enough periods of time to defeat any buffering scheme we could come up. We have asked an inside connection at Apple who offered no insights. We can reproduce this behaviour easily outside of Ardour, using some test programs in the tools/ folder of the source code. We have plotted graphs to show the behaviour. It is a mystery, and we have no real idea how to solve it.
A disk capable of 100MB/sec will slow to 5MB/sec for long enough periods of time to defeat any buffering scheme we could come up.
Never had an issue if I increase the disk buffer size beyond the simple 5S buffer as chrisg mentioned above. My suspicion is that is likely what most other software is doing as well, and just emptying the buffer as fast as possible so that when bursts of available speed happen it empties as much of the buffer as possible giving plenty of room to handle slowdowns in the future.
Of course I suppose to check this would require doing a massive and instantaneous kill of a piece of software (Read kill power to computer) and see how much audio recording to disk actually happened, more difficult in some software if you don’t know where they are writing to disk to stat with, and of course brings all the normal power corruption issues to the top as well.
Seabladeseablade: we’ve run the test programs on many different OS X systems. Poor performance is witnessed on ALL OS X systems when there are lots of files (tracks). As I mentioned, the dependence on the number of files being written to is really big on OS X. This is (we think) why hosting Windows on OS X works much better: guest-Windows’ entire filesystem is actually just a single file on the host OS.
The test programs all “fail” in the same way that Ardour does: increase the number of tracks to a high enough value, and the minimum sustained bandwidth provided by the disk/OS is not capable of supporting that number without buffering insane amounts of data in memory.We also know how much memory (e.g.) Logic uses, and they do not use this insane amount.
This isn’t the result of 10 minutes worth of observation. I spent nearly a week working on this with some analysis and design help from Robin, and we didn’t get anywhere in terms of an actual working solution.
You won’t see these sorts of problems till you get up above about 100 tracks - most testing was done with 128.
BTW, the positive record so far has been Ardour on Linux with an NTFS-formatted disk: 1024 tracks recorded simultaneously with no issues. Amazing.
Strange, pretty certain I did some benchmarking on my NAS box with about 128 tracks for someone I know off Ardour on OS X with no problem. I wonder if network filesystems behave different.
I don’t doubt that you spend lots of time testing it, but the fact remains that other DAWs have found a way around this somehow, whereas Ardour does show MANY more issues at much lower track counts without tweaking, and the tweaking Chris pointed out works well for several hour live recordings of up to 64 tracks that i do on occasion in Ardour. Yes OS X may be much worse than Linux in regards to how Ardour is writing out files, but that doesn’t mean there isn’t a workaround (And may have to be deemed a solution if the issue is truly OS related).
SeabladeJust for grins and giggles by the way, recording 128 tracks to the internal SSD on the MBP through A3 (A nightly, can’t remember which one off hand, can grab version if needed) and so far working fine, how long before you typically saw issues? Was this on a mechanical disk you tested or SSD, the earlier of which I could easily see being an issue, and would make me suspect disk format might be playing a major role in what you are seeing. Maybe I should just jump on IRC next week to chat…
SeabladeHi guys. Didn’t expect this much chatter on this thread… ;^)
Anyway I downloaded the nightly build Ardour_64bit-3.5.4561-dbg and followed chrisg’s suggestion to increase the playback buffer and then things worked. Cool.
@Paul - I’m running OpenSUSE 13.1. Things seemed fine with 3.5.403 with playback of at least 12-15 audio tracks. Before adjusting the playback buffer on any of the nightlies it would fail to play files with even one audio track.
Let me know if you would like any more of my system info. Thanks.
seablade: SSD’s definitely reduce or hide the issue just because they are SO much faster than a spinning disk. We tested on spinning disks because that is where the problem is. I am not suprised that your NAS worked … it isn’t really OS X or an OS X filesystem (HFS+).
Yea that is my suspicion, is that you might be running into a FS issue when talking about multiple open files, depending on where the sectors used are physically on the platter, whereas other FSs may handle this better.
Seablade@cchoowee Glad that worked for you. I see this as something that needs fixing or reverting. Prior to the experiments with disk playback and record bandwidth, I could playback any sessions, including those with up to 64 tracks. Now, I cannot play a single track with the playback buffer set as it used to be, it has to be increased or it’s just no go.