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.
“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.
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.
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.
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 unsupportedYes, 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 ;-)
.. 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 ;-)
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
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 
I’ll just let your comments simmer and consider what may be the most feasible path to take.
Cheers,
Jesper
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.
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.
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.
“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.
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…)
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.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.
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.
I’m curious, what are you doing with that sample rate?
@ccaudle: Thanks for your feedback & actually trying out if zita would work at these rates … 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 rateThat 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
Jesper
@evalon: “which computer configuration”
The experiment was on a Tyan dual Opteron workstation. Pretty old and slow by modern standards, but very stable. Two dual core 1.8GHz processors, 16GB RAM. Not running a -RT patched kernel, but there were so many errors that wouldn’t help until the errors were down into the just occasional category.
If I get a chance this weekend I may try again but with something more reasonable, like jackd running at 384k or 192k and zita-a2j resampling to 96k. Just to make sure the jackd configuration with dummy backend works correctly at all before going to such a high sample rate.
“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).”
Ardour always works at a single sample rate, so to end up with a 384k file it would create the output file at the same sample rate as all the session source files, then run a script after to generate a lower sample rate copy.
But, without hardware running at 1.536M you would be working without being able to hear what you are doing. Not sure what the point of using a DAW is if you can’t listen to your work, you might as well use SoX and just do everything offline. That said, I think what you proposed could work. I’ll also see if I can try that this weekend, I generated three 1 minute long source files at 1,536,000 sample rate using SoX and loaded them into ARdour, I will see if export works, then use off line sample rate conversion to convert the generated output file back to base rate.
My original attempt was with no plugins active, just three mono channels connected to a stereo main bus. I would think that assuming any plugins you want to use can calculate parameters for such a high sample rate, the processor utilization is going to be very high.
“I’ve inquired with the main programmer helping here about ALSA and ASIO and he is not immediately familiar with this”
That is in direct conflict with your earlier statement:
“a programmer which I understand has some experience also with audio devices.”
" have previously been employed with a major audio company making e.g. soundcards and sound processors"
ALSA is the only Linux audio API in current use, and ASIO has been used by every professional multi-channel sound card on Windows since at least the mid or late '90’s. Anyone not familiar with ALSA has never worked on audio programming on Linux, and anyone not familiar with ASIO has never worked on professional multi-channel audio on Windows. The fact that the “main” programmer does not have expertise in the problem domain should throw up some red flags regarding how quickly you could expect to have working and stable drivers.
“saving the files to a .wav format (or if there is a better format?) and loading them from there”
ALSA and ASIO are a layer lower than that. Those two API’s are different ways of describing how the software which reads data from a wav file then presents that data to the audio hardware, or how to retrieve audio data from the hardware so it can be saved to a wav file. The ALSA or ASIO driver runs as part of the OS kernel, and implements the appropriate API for use by software such as Ardour, and has the required logic to copy the data to and from the hardware. The programmer needs to understand the hardware, kernel driver programming, and have a list of required functions to implement the API. None of those tasks individually is difficult for an experienced programmer, but there is a learning curve involved.
Had time to try out my suggested setup but with different sample rates. I verified that jackd running the dummy backend at 192k sample rate, with zita-j2a converting to 48k works correctly. I made a session with three imported test files, and could mix them together and play back with the hardware running at 48k and the session running at 192k. Using a session with the same setup, i.e. three imported mono files being mixed together to a stereo master bus, DSP utilization was about 17%. So the setup works in principle, I just can’t get it to work on my system with the dummy backend running at 1536k sample rate and the hardware running at 48k or 96k sample rate.
The other experiment confirming that Ardour can run at 1536k sample rate was almost but not quite so successful. I created the same style session, with three imported files (the files in all cases were just 1 minute sine wave files generated with sox), but this time no zita-j2a running, so Ardour just connected to the jack dummy output. The session loaded OK, and when I hit play it looked like the session was running, although of course there was no audio output to verify in this case since only the jackd dummy backend was running.
However, when I tried to export using “session sample rate” the export went much slower than real time, and when I checked the output file with sndfile-info it showed the exported file as having 192k sample rate. I did not see any messages about sample rate conversion, so I’m not sure what triggered the conversion to 192k. Perhaps the export routine has a limit on the maximum sample rate considered valid.
But, all it not lost because of the flexibility provided by the jack infrastructure. I played the session again, and this time used jack_capture to record in real time directly from the master bus to a file. That file was confirmed by sndfile-info as having a sample rate of 1536k. I used sndfile-resample to convert back to 48k for listening, and it sounded like what I expected, and Jack/Alsa Audio Analyzer did not show any IMD or harmonic distortion when connected to the 1536k jackd output, just the three frequencies from the sine input files.
So the main Ardour editor and mixer functionality seems to work fine at stupid high sample rates, but the export feature won’t quite work. Export is nice because it runs faster than real time, and will just output the session audio, so you don’t have to worry about starting and stopping another program that might add blank audio at the beginning and end that you didn’t want.
As an aside, don’t try recording the output with jackrec. I don’t know why, but but the result was horribly distorted. The recorded file from jackrec was less than half the file size as the output recorded by jack_capture, so something went very wrong. Using jack_capture is pretty easy, so at least there is a real time work around for the export not allowing high sample rates. Might be a simple patch if you want to build a version which doesn’t limit the exported sample rate after you have real hardware working at that rate.
Hi ccaudle … This is just a quick message to say that I’m currently doing some hardware design and need to be quite focussed on this. So I’ve read what you write & will get back when time (and the Ardour installation) permits.
Cheers & a good day to you
Jesper
I’m new to Linux and having trying quite a few distros. I’ve settled on Linux Mint (18) and Ardour is working a treat with my Steinberg UR22 interface. I did try to run Ardour in Elementary, but no luck. The version of Ardour in Elementary was gray, so perhaps an older release(?).
I’m also using Calf plug-ins which are working fine as well.
Goodbye Logic Pro & Ableton Live.
Oops, it should read I have been trying a few distros…