New to Ardour & Linux - which linux installation to choose?

Installation & Configuration Linux
#1

Hi All,

First greetings to people here - those who have developed/develop Ardour - and the forum’ers here. I think Ardour looks mighty interesting and I look forward to first evaluating it and after that hopefully using it (and supporting it). A thanks for making it available :wink:

To this end I’m about to set up Ardour on my PC and would much appreciate some tips on how this is best done. I suppose a bit of information about where I’m coming from may be a feasible starting point:

  • I have a technical background but unfortunately no programming experience, nor previous experience e.g. with Linux. I normally use a WIN7 based computer.

  • I will be using Ardour to record high resolution .wav files with custom hardware (1.536 MHz, 32 bit word length, up to 6 channels at a time). I know this often causes some comments but, please, this is what I’ll be using it for - there is a purpose in so doing :wink:

  • For evaluation purposes I intend to install Ardour on my modestly powerful laptop: Dell E6420 with a core I3 2.1 GHz processor, 8 GB RAM & a Samsung SSD (the processor may be replaced with a core I7 2.2 GHz version if feasible).

  • Admittedly, my main purpose in this is to make the recordings and so I’m looking for accessible and stable solutions that will work for quite some time.

So this is a bit about where I’m coming from with respect to Ardour.

And then to my question about installing Ardour which I hope you may help with … Although I’d prefer to install Ardour on my Win7 I seem to read here that this is not feasible in terms of stability issues etc. Thus I would like to install it using a suitable Linux distro, however, given my background I’m a bit unsure which one to choose? I’ve read through this thread:

https://community.ardour.org/node/8699

and it seems that there are many possible linux distros to use, although some prefer KXStudio, AVlinux & plain Debian … My personal main criteria for selecting a linux distro would be stability, easy setup, and an intuitive user interface - I simply know that if “something” is intuitive for me to use I will learn to use it much quicker and simpler. With this in mind would there then be a suggested Linux distro to use?

Additionally, with reference to an earlier email exchange with Paul Davis, I reckon I will be using the JACK backend which is to be set up to work with files sampled at these frequencies. I understand that there is also a GUI for the JACK backend that simplifies setting up JACK (based on Qt), however, I don’t know if it is feasible in this context - someone here knows? … ? Or should I use a plain JACK version?

To this end I can see that there are two JACK versions. Given that - at least initially - I will mostly be loading files from a HD, or otherwise use a single soundcard, it looks as if the version to use is the JACK2 version … There’s a link here comparing the two versions:

Doesn’t this sound sensible? As far as I can see the only “downside” to using JACK2 is that it doesn’t support metadata API (which I, to be honest, don’t know what is) …

Finally, as there’s currently a programmer kindly helping me with connecting the ADCs to be used with the PC, are there any links or hints on how to make the PC/Ardour recognize the associated custom soundcard as a sound device from which files (.wav) may be streamed (needs be key points/an introductory format due to the time available)?

Now, this has become a long post … if you got this far, thanks for reading - and maybe being able to help :wink:

Cheers,

Jesper

#2

@GuntherT … Thanks for your feedback. I will watch both the nightly build & the official site then for news on the Ardour 5.0 Windows version …

Cheers :wink:

Jesper

#3

@evalon:
"So it may be possible that an ASIO driver or ALSA support could be available (will check with the programmer). "

Do you currently have a multi-channel sound card of some kind? You could start using Ardour with what you have to get some familiarity before your new custom hardware is ready. For the new hardware you WILL have to have an ASIO driver for Windows or an ALSA driver to use Ardour, “may be possible” won’t cut it, there is no practical way to use it without an operating system driver.

“But for a start the intention is to save the recorded files as a .wav file and then load this file into Ardour.”

That’s well and good, assuming you have some kind of custom software which can access the hardware directly and write to a file, but then what? Ardour requires all source files and input/output streams to be at the same sample rate, so now you have a bunch of 1.5M samples/s files loaded, that means Ardour will require an output device capable of handling a 1.5M sample rate. You might be able to get away with running jack at that sample rate, and using a sample rate converter to convert down to 48k or 96k to use with existing hardware if you want to see how well Ardour can handle that amount of data. I would suggest zita_ajbridge, but I’m not sure if those work without a hardware master clock.
The jack1 package includes this equivalent feature, but the jack2 package requires loading external software:
http://kokkinizita.linuxaudio.org/linuxaudio/zita-ajbridge-doc/quickguide.html
I don’t know what kind of processor load you will get with 32x base rate, it might be pretty high.

@paul: will jack dummy backend come up with a reasonable clock approximation if you specify the sample rate you want, or does jack require a “real” hardware backend to run at a fixed rate (as opposed to freewheel running as fast as possible)?

#4

:wink: smiling at my last sentence: … “And with these words no further comments from me.” It should have been “… in this post”. This makes me wonder though if there is a way to edit a post when it’s been posted - e.g. a short time after it’s been posted?

Jesper

#5

@GuntherT:

… About the nightly site I found this:

https://nightly.ardour.org/

Is this where I may be downloading the version 5 when it’s ready? And to this end: Is there any recommendation about waiting or downloading the current version?

Regards,

Jesper

#6

Yes, that is the site where I watch for release versions of Windows builds to arrive, but as Paul pointed out earlier in this thread, there will be an official release of the Windows build when 5.0 comes out, so watching the nightly site will no longer be necessary. The Windows build of Ardour 5.0 should be available on the official download page of the main site when it is ready…unless I misunderstood Paul’s post. I definitely recommend waiting for 5.0 as the versions currently on the nightly site are for testing purposes only.

#7

“custom hardware (1.536 MHz, 32 bit word length, up to 6 channels at a time)”

I will emphasize what Paul said, because you are putting the cart before the horse a little bit here. First you have to get the custom hardware working and verified, then you have to get a working driver for the custom hardware. That is quite a bit of work to get done before you have to worry about getting Ardour installed.

This statement is slightly worrying:
“are there any links or hints on how to make the PC/Ardour recognize the associated custom soundcard as a sound device”
That seems to indicate that you are not familiar at all with ALSA, which is the standard audio interface software on Linux, so it may be a while before you have anything which Ardour can use.
The “requirements” tab on the main Ardour page states it pretty clearly:
“Any ALSA-supported device will function with Ardour, either directly or via JACK.”
For OS X:
“Any device supported by CoreAudio can be used with Ardour, either directly or via JACK.”

There is not an equivalent Windows tab yet, so I am not sure which audio API’s are supported. Harrison Mixbus is based on Ardour and supported on Windows, and the requirements page at Harrison ( http://harrisonconsoles.com/site/mixbus32c-sysreq.html ) says any ASIO supported card will work. It is possible that the other Windows API’s will also work (Windows Core Audio exclusive mode?) but you will in any event need either a Windows ASIO driver or a Windows WDM/KS driver for the hardware.

So I think the short of it is that you need to worry about getting an ALSA driver on linux or an ASIO driver or WDM driver on Windows working first, and then you can come back in (optimistically) a couple of months and ask about getting Ardour installed to use with your new custom sound card.

#8

Ardour on Windows supports the ASIO API for audio interfaces. If there’s an ASIO driver (either native or using ASIO4ALL) then things should work.

#9

Hmmm … thank you all for taking the time to reply. I think I’ll reply as you posted your comments:

@paul: First a comment on intuitive in post #4: I’ve read your first post in the thread “Reflections on intuitive” and although it gives me an impression of where you are coming from in this, to me it’s nevertheless so that words & meanings have many different levels and explicit or implicit meanings, and uses. Also, in my experience, they may or may not be “efficient”, i.e. people understand what I mean - or they don’t. Previously when I’ve used the word intuitive in a context in relation to other people they have most often had an understanding of what I meant - it has led to feedbacks and responses from these people that have been meaningful to me and in line with what I was looking for. This has also happened when I’ve been inquiring about softwares - I’ve received some very fine suggestions on softwares that appeared to be intuitive to me and which I use today - for the very same reason. What I’m trying to say is: I’ve read your suggestion above that I shouldn’t use the word intuitive in relation to softwares but I respectfully will choose to continue to do so … because it is meaningful to me and is in line with how I perceive the word intuitive. And it has also been “efficient” for me in terms of communication with others e.g. about softwares. And then, since I’m essentially here to learn about, & learn to use what I perceive is a very interesting software I’ll now, again respectfully, round off this exchange of words on my part.

@GuntherT:

Speaking as a Windows user who tinkers with Linux as a hobby, I would recommend becoming a subscriber ASAP and watching the nightly site for the Windows 5.0 release, which should be available soon.
Thanks Gunther for this comment. I really am most interested in recording and so if I can continue to use Windows with Ardour I'd prefer to do so. Can I ask you to post a link to the nightly version (I will subscribe then)?
I don't know what you are referring to when you say Ardour has stability issues on Windows. My experience is Ardour pretty much functions identically on Windows as on Linux, and most stability issues are due to 3rd party plugins.
I remember reading in a thread, possibly the one I linked to in my first post, that the windows version might not be as stable as the Linux version. But it is indeed good news that this is not the case :-)
Windows in general has better hardware support, so if you have a unique soundcard that is another reason to stick with it.
It's not really a soundcard but most likely an FPGA which reads the data from the ADC and passes them on to the PC. The practical solution is being looked at now by a programmer which I understand has some experience also with audio devices. So it may be possible that an ASIO driver or ALSA support could be available (will check with the programmer). But for a start the intention is to save the recorded files as a .wav file and then load this file into Ardour.
Keep in mind the Windows versions are only available to subscribers and are unsupported
Yes, I've read this.
but if you are paying attention and snag the release version, there shouldn't be much the Ardour team can't help with after you get your hardware connected and the program up and running.
Hmmm... this is good news indeed. In due time I would also be willing to pay for help here should I run into set up challenges I cannot solve myself.
Another option is to buy Mixbus, which is based on Ardour and does come with Windows support.
I've just briefly skimmed the Mixbus user manual and I can't see any information about setting up higher sample rates ... ? Anyway, for now I'll prefer to stay with Ardour but will keep Mixbus in mind - thanks for the tip ;-)

@Paul:

.. but as GuntherT noted, prettty much everything beyond that is now consistent across all 3 platforms and so we can, to some limited extent, provide some kind of support (certainly if users display the general technical awareness that is common on Linux). ..
This sounds good - although I, as I mentioned in the beginning, am not a programmer. I am much interested in getting this to work, though.

@anahata: Hi … Thanks also for your comments. However, as a wrote above, since a Windows version appears to work fine I’d prefer to use this in place of the Linux version.

@ccaudle: Hmmm… I suppose that in real life there’s always a risk that things doesn’t progress as intended … However, the programmer(s) kindly helping here are well-versed in FPGA programming and have previously been employed with a major audio company making e.g. soundcards and sound processors. So my hope (and quite clear understanding actually) is that they are able to make this work. By now there’s a test version version ready (single channel) - waiting for the summer holidays to conclude.

This statement is slightly worrying:
I agree with you :-I .. and you are pointing towards a lack of knowledge I currently have, which is related to the wordings & definitions & practicalities of professional audio. I've been searching for an accessible introduction to this field but haven't really found any (yet, I hope). So if you - or one of the other contributors here - know of an accessible and intuitive introduction to this field (leaflet, internet link) I'd appreciate hearing about it.
.... and then you can come back in (optimistically) a couple of months and ask about getting Ardour installed to use with your new custom sound card.
... My personal experience is that being up front with potential future bottlenecks may help ensure a flow in things - thus I'm looking into Ardour at this point in time - to get my first impressions & questions which may then evolve in the months to come. I don't expect the hardware to be ready just now - but I've already learned some by starting this thread ;-)

@Paul:

Ardour on Windows supports the ASIO API for audio interfaces. If there's an ASIO driver (either native or using ASIO4ALL) then things should work.

… With reference to my comment above I hope to learn more about e.g. an ASIO and how it relates to other audio structures in a PC.

Thanks again for your comments & suggestions … And with these words no further comments from me.

Cheers,

Jesper

#10

Hi Paul,

Thanks for your comments & suggestions. I’ll consider what you’ve written, yet just a brief comment to one of your points:

I believe I’ve corrected your use of “32 bit format” previously, possibly on IRC. There is no such thing as a 32 bit audio sample - what is common is a format that packs the 24 bits handled by the A/D-D/A converters into a 32 bit quantity. It is inaccurate and confusing to refer to this as a “32 bit sample” - it is a 24 bit sample, that just happens to be packed into the data stream in a way that reduces the CPU load required to deal with it. A 32 bit sample would include a recording of brownian (atomic) noise, which hopefully is clearly absurd.<<

You have previously noted this, and actually, when I posted this thread I did pay attention to not wording it as a 32 bit sample (although there are 32 bit resolution - not precision - converters like the AK5572) but used the wording 32 bit “word length” - to indicate that the length of each channel’s data (which is really from a 24 bit converter with just about 20 bits ENOB) is packed into a 32 bit structure. I do not know if “word length” is the right wording either but I hope my message comes through with sufficient clarity for others to understand what I mean.

That said - thanks again for your feedback :wink: I’ll just let your comments simmer and consider what may be the most feasible path to take.

Cheers,

Jesper

#11

The correct term “24 bit sample”. No other aspect of the situation is really important. There are devices that provide the sample packed into 24 bits, the low 24 bits of 32, or the high 24 bits of 32. These details don’t matter to use anyone except the person who writes a device driver. “32 bits” does not describe the resolution or precision - it is just a transmission format, nothing more. There are lots of devices that do this - it isn’t novel, remarkable or notable for a user.

#12

Speaking as a Windows user who tinkers with Linux as a hobby, I would recommend becoming a subscriber ASAP and watching the nightly site for the Windows 5.0 release, which should be available soon. If you want to use Linux, I agree with Paul that AVLinux is your best bet, but you may find yourself spending a lot of time learning a new OS when what you really want to be doing is recording. If your interest is in Ardour only and not other Linux audio applications, there is little reason to make the switch, in my opinion. I don’t know what you are referring to when you say Ardour has stability issues on Windows. My experience is Ardour pretty much functions identically on Windows as on Linux, and most stability issues are due to 3rd party plugins. Windows in general has better hardware support, so if you have a unique soundcard that is another reason to stick with it. Each OS has its strengths and weaknesses, so I’m not arguing that one is better than the other, but if you would prefer to use Windows 7, it is probably a better choice for you. If you decide to try out AVLinux, you may want to wait until Ardour 5.0 arrives as GMaq intends to update the ISO once it is out. The 5.0 release may have some compatibilty issues with sessions from prior versions, so you may want to wait before starting any long term projects. Keep in mind the Windows versions are only available to subscribers and are unsupported, but if you are paying attention and snag the release version, there shouldn’t be much the Ardour team can’t help with after you get your hardware connected and the program up and running. Another option is to buy Mixbus, which is based on Ardour and does come with Windows support.

#13

There will be some changes with 5.0 … we plan to do a normal release version for Windows a long with OS X and Linux. We do not plan to offer any kind of support for installation or device driver issues, but as GuntherT noted, prettty much everything beyond that is now consistent across all 3 platforms and so we can, to some limited extent, provide some kind of support (certainly if users display the general technical awareness that is common on Linux).

As far as we know, there should be no backward compatibility issues with older sessions.

#14

“we plan to do a normal release version for Windows a long with OS X and Linux”

That’s great news.

“As far as we know, there should be no backward compatibility issues with older sessions.”

That’s also great news. I must have misunderstood some of the posts related to the nightly builds after they switched to the pre-release versions, my bad.

#15
If you decide to try out AVLinux, you may want to wait until Ardour 5.0 arrives as GMaq intends to update the ISO once it is out.

All the same, if there’s any delay between the release of Ardour 5 and the AV Linux update, be assured that new versions of Ardour generally install on AV Linux without any problems, so you could get the current AV Linux now and install Ardour 5 when it’s released.

(I don’t know if the AV Linux upgrade will have other improvements worth waiting for, of course…)

#16

1. Ardour no longer requires JACK at all, so unless you plan to use standalone synths or processors in conjunction with Ardour, it really doesn't matter.

2. Use hardware MIDI devices with JACK2 is a bit more cumbersome than with JACK1 (you need to start a2jmidi -e as well, which isn't hard but isn't trivial for someone new to Linux. Other than this difference, yes, it really doesn't matter very much.

3. Ardour on Windows is, as far as we can tell, just about as stable as Ardour on Linux. Problems on Windows tend to occur mostly at install time or with device drivers.

4. Please don't ever use the word "intuitive" when talking about software. "Works for me" is the most accurate thing you can say without getting into the weeds. https://community.ardour.org/node/3322

5. If you're brand new to Linux and/or audio on Linux, AVLinux is highly recommended for most use cases. Ubuntu which is probably the most widely used version of Linux, will typically require more work on your part to set it up correctly. Because you require a custom device driver, it is much more difficult to make suggestions. Your final decision will likely be based on personal/situational factors that are hard for others to comment on. More or less all Linux distributions can be made to work correctly for this purpose, it is just a question of how much and what kind of work is required.

6. all audio I/O on Linux (more or less) uses ALSA at the lowest level. If your new device driver, but if it isn't part of ALSA, nothing in the Linux audio ecosystem will be able to use it, including Ardour and JACK. If it is part of ALSA, there's no work required - both Ardour and JACK will discover it normally.

7. Just to correct an aspect of how you think about what is going on ... you do not "stream files from" an audio interface. There is a data stream available, in a certain format (normally linear PCM). It is the job of user-space recording software to take that data and create files in the filesystem that hold the data for future use. Audio interfaces known nothing about files, only data streams, and these days, most of them only speak linear PCM as the format.

8. I believe I've corrected your use of "32 bit format" previously, possibly on IRC. There is no such thing as a 32 bit audio sample - what is common is a format that packs the 24 bits handled by the A/D-D/A converters into a 32 bit quantity. It is inaccurate and confusing to refer to this as a "32 bit sample" - it is a 24 bit sample, that just happens to be packed into the data stream in a way that reduces the CPU load required to deal with it. A 32 bit sample would include a recording of brownian (atomic) noise, which hopefully is clearly absurd.

9. You should not expect to be able to use any remotely low latency settings if you insist on recording at 1.3MHz. I don't know what buffer size you will require, but a sample rate that high will require substantial buffering on any current general purpose computing platform.
#17

I tried what I suggested above, use zita-j2a to sample rate convert to 48k while running jackd at 1536000 rate, and zita-j2a could not keep up, it was a constant stream of error messages that zita-j2a did not finish in time (using 4096 or 8192 period size).
Maybe a beefier computer could handle the load, maybe an even larger period size would help. I may try later with something like a 32k period size to see if that works, maybe forcing zita-j2a to the lowest quality settings. Doesn’t look promising. Ardour didn’t seem to complain about the crazy sample rate, I just couldn’t get any output to my sound card.

#18

Nope, jack2 dummy backend only allows up to 8192 as period size, and even with zita-j2a set to lowest quality it could not keep up resampling 1,536,000 down to 96,000. I would be interested to know if anyone has a computer fast enough that the combination works, or whether it just isn’t possible with reasonable hardware.
I don’t have my system tuned very well, so I won’t say it’s unlikely yet, but it definitely isn’t easy.

#19

I’m curious, what are you doing with that sample rate?

#20

@ccaudle: Thanks for your feedback & actually trying out if zita would work at these rates :wink: … just so that I have a reference relative to the trials you conducted - can I ask you which computer configuration you use (processor, SSD HD?, RAM, motherboard)?

Ardour didn't seem to complain about the crazy sample rate
That sounds indeed positive ... Then there may be a way forward with what I describe below ...

What I’ve been thinking is that a feasible way to do this could be to load and edit the .wav files into Ardour, and then again save the file as a 1.536 MHz file - or as a 384 kHz file (if this is possible). I don’t have a bi-directional soundcard but I have a 192 kHz DAC (can be up to 768 kHz with a little time invested) that may playback such files. In case Ardour cannot save to a different sampling rate than the one that was loaded maybe a sample rate converter could be a way to progress (could also be directly decimating the 1.536 MHz file by 2 or 4 I guess) …

BTW I’ve inquired with the main programmer helping here about ALSA and ASIO and he is not immediately familiar with this - so at least in a first round it will be saving the files to a .wav format (or if there is a better format?) and loading them from there.

Also, so that I actually know what I am referring to when asking/talking about Ardour I’ve decided to become a subscriber (will start at a basic level while evaluating) and will download and (try to) setup the software on my computer. It probably will take some days though as time is a little tight right now …

@Robert Edge: Hi Robert - thank you for your interest & question. What I can say is that I’ll be using the setup for special audio recordings.

Cheers to you & thanks again ccaudle for investigating whether zita would work :wink:

Jesper