You would have to ask the manufacturers. The most likely answer is that you can’t do this on Linux, because they provide some platform-specific (e.g. Windows) tool. On the other hand, MOTU lets you do this from their web-based “control panel”, and so is platform independent.
I have already attempted to explain the differences between USB3/USB2 as connections and the “2.0 audio class” and “3.0 audio class”. If you have more questions about that, please ask a more detailed question.
Everyone has cover me more than enough.
Thanks for your willingness to help and all the valuable information around this matter.
My personal way of dealing with this: Take a laptop with the OS I will be using to the music store. Try the audio interface I am interested in on my computer in the store. Buy the one that works best. Be sure to test things like adat if you intend to use it. (a number of “18” io boxes are 8i/o plus adat) If your music store is not willing to let you do this… find one that does. It is worth a drive to be able to do this. In Canada I would recommend Long & McQuade where I have tried and bought audio interfaces with no problems.
All I can tell you is my own (and my sons) experience of migrating to Linux. To begin with we found difficulties in changing our habits from being Windows users… Drivers, hardware and propriatory software seemed to be issues, but within a few weeks we had adjusted our thinking and realized how easy it all is when sorting out OS issues.
I like to build PC’s, my son is into coding. Within a couple of months we were wondering how we ever got by without Linux, it really is a truly remarkable entity and all the different flavours of it have become a delight for us to play with. I have a science Linux for home educating my son, Ubuntu Studio with KXstudio repos and all the bells and whistles for my music, video and photography, Debian Wheezy for running my CNC, Xubuntu on my ancient laptop (brought it back to life with that) and I use Kubuntu for gaming.
There isnt a piece of hardware that I have not been able to use yet, and I have boxes of bits and pieces, although if I ever have a problem with hardware drivers, I have a PC that runs Manjaro which I think will run just about any hardware out there.
Only issue I ever had was trying to get some software to run on my Ubuntu Studio, so I jumped on a forum, posted my problem and one of the team that produces Ubuntu Studio came on, sorted my problem and incorporated the solution into the next build. Thats how things work with Linux, thousands of (clever) users out there constantly tweaking things and improving them for the rest of us.
Certainly not trying to convert you, just saying that for us, the switch to Linux has been fabulous and we will never go back as the benefits are too valuble to us. I do remember whenever I used to install Windows, I would then go through a checklist of things to set up the system to work the way I wanted, it is the same for Linux, but that list does not now include installing drivers and I find Linux does exactly what I want it to, could not say the same for Windows…
As to my audio, I use a Focurite Scarlett 2i4 usb, which runs perfect out of the box, no drivers needed and my latency is 4ms. My needs are very moderate for an amatuer fun studio, but I have so many Linux tools to play with (all free) I will be years getting round to all of them…
Hope you manage to give it a try, please remember that the best way to check out your hardware compatibilty, is to create a USB live version of Linux that you can run without altering your system, you will get to play around with Linux, check your hardware and if you dont like it, you remove the USB stick and reboot, quite painless…
that holds true not only for class-compliant devices, but for almost all devices supperted by Linux (with the only exception of the few devices which requires a custom, often proprietary driver provided by the manufacturer which is not included in the kernel and must be installed by the user).
Nope. Linux drivers included in the Kernel are open source and, in most cases, they have been written by Linux developers volunteers, not by the hardware manufacturer.
A few manufacturer provides the open source code themselves. Other just provides some support to Linux developer, such as interface/protocol documentation, and perhaps some hardware samples to work with. Sadly many other are not Linux-friendly at all, and their devices are either unsupported or support had to be painfully created by the Linux developers using reverse-engineering techniques.
The software between the hardware and DAW is (usually) the ALSA stack, for all audio hardware. Support for individual devices (“drivers”) is also part of ALSA.
Thus your question should be restated as: “how well is card XX supported by ALSA”?
Or, put another way, more generically: “which are the audio interfaces with this and that characteristics which work best with Linux?”
same thing…
So, what is your answer? I don’t understand…
I honestly think we are going round in circles. @lenovens idea of taking a laptop to a music store is great (as is mine for using something like Sweetwater’s no-questions-asked 30-day return policy 
). Less stress + fewer numbers/comparisons (which turn out to be a bit of a red herring as everyone’s system/setup is different) = more productive music-making 
EDIT: Not forgetting @mhartzel and @paul for suggesting that perhaps Linux isn’t necessarily the best option for your particular case. If you really really want that expensive gear you mentioned previously just go for a Mac! You can still use Ardour or Mixbus…
basically the same thing that others already told you (my bad, I answered before to have read all the other posts).
IMHO, your problem is that you are approaching a new operating system while keeping in mind your previous knowledge of (and habits on) another, completely different one.
That does not work.
If you are serious about using Linux then you have to take a new, completely different approach. Basically you have to “forget” just about everything you know and are used to in Windows (and/or Mac) and learn about the new system from scratch.
Eventually you’ll find that there are some analogies, but there are also so many differences that would confuse you if you keep reasoning like you would do for the other system(s).
As a side note: while for many of the most common use-cases it just works out of the box (and it may be even easier to setup and use than other systems), in general Linux tends to be way more “technical” than Windows (let alone the Mac…). That’s particularly true when you have to choose the right hardware for some “specialistic” tasks (such as pro audio), optimize and/or customize your system for special tasks, etc. Again, if you’re serious about using Linux for audio production, you’ll have to get much more tech insight and better understanding of what’s goin’ on “under the hood” than what’s usually required on other systems.
Why you explain to me how Linux works?
I am using Linux over a decade.
I am asking for a compatibility report or list call it however you like, between the OS and audio devices.
I had several issues with Scarlett 4i4 usb2 with Linux & Mac, a device everyone here would say it’s working but it’s not. Not the way it should, I ll not discuss that here, everyone knows how to search and find hundreds of posts with issues usually caused by the driver or the audio system whether on Mac, Linux or Windows.
If drivers are coming from Linux devs where are they?
If open source where is the code?
Some kind of info, anything!
Kernel has thousands of code lines and it’s available to download, why drivers (free & non free firmware) are so hard to find?
And yet you have to ask where to find source code?
Below the top-level folder “sound” in the linux kernel source tree. Paul already posted a direct link, scroll up to post #6.
Anyway, this forum is mainly concerned with Ardour, I think your questions are best addressed elsewhere.
Yes, I am also a Linux/Mac/Windows developer (So WHAT?) and contributed to many forums/communities and articles and still find difficult to cross-check these with audio hardware. Even after 10 years.
If you found a way maybe you can share.
Yeah, I also have the feeling that I’m not in the right place for such questions.
A master was trying to explain something to a student. Now this student was not a brand new student, but a senior student who had learned many things. He had knowledge and experience aplenty to draw upon. But each time the master tried to explain something new to the student, the student kept trying to hold it up against his own notions of the way the world is and how it ought be, and he was unable to see the lessons in what the master was trying to teach him.
Finally, the master poured a full serving of tea into his own cup, and into the cup of the student. Then he told the student he wanted to give to him some of the tea from his own cup. He began pouring tea from his cup into the student’s cup, but the student’s cup was already full, and all the tea from the master’s cup spilled out over the cup onto the surface below.
The student said, “Master, you can’t pour anything into my cup until I empty it to make room for what you are trying to give me.”, and the master replied “Yes I know.” “And I can’t give you any new thoughts or ideas or perspectives on life’s lessons until you clear out some thoughts that are already teeming in your mind to make room for what I have to teach you.” Then the master paused for a brief moment, meeting the student’s eyes with his own knowing look and calmly but sternly said: " If you truly seek understanding, then first, empty your cup!"
The student pondered for a moment with a look of absolute bewilderment. Then a look of enlightenment came over him, followed by a smile, and a look of receptiveness. The master started to explain again, and this time the student saw what the master was trying to say.
Since there are linux audio masters here whose cup overfloweth… I’d like to ask (somewhat in the spirit of this thread), what is involved in getting DSP support for audio interfaces under linux? The class-compliant USB audio seems standard now, but it feels like every vendor and perhaps every device is going to have their own special protocol for the DSP aspect of the audio interface.
Is it worth the time to attempt to reverse engineer such things? With what I can only assume would be something like WINE or a virtual machine and wireshark involving proprietary binary closed source drivers/software… any hints on how easy or what the time investment is? Or would a wise man prefer a device which hosts its own web interface to control DSP, hardware mixing, etc?
Blair
It depends a lot on the device. In most cases you’d have to do a ton of wireshark-based reverse debugging. Most manufacturers have displayed close to zero interest in supporting access to the hardware DSP from Linux.
For something like the newer MOTU devices which can be controlled entirely from the web, you still have to do the reverse engineering, but it’s all at the HTTP level instead.
On the other hand, I have to ask: what do you think you’re gaining over DSP running in the CPU?
It is more of a curiosity from the coder side of me really. Also I don’t like spending money on devices that I can’t completely use and don’t really own/control. That said, I just put a deposit on a MOTU M4, which looks to have great specs and not much advertising about a DSP.
My current process is very simple, basically record dry over a click or basic drum track. I’m just now trying to figure out whether any processing while tracking is beneficial.
I guess the devil’s advocate answer to your question would be the few milliseconds of extra latency to trip through the USB and computer, although you raise a convincing point here. When I’m noodling in guitarix, the linux/alsa/jack/guitarix stack is tight. It seems we have accurate models/reporting for the various latencies too, and so we can compensate. Maybe my future purchases should be geared to clean conversion sans DSP or other offloading because my general purpose computer is fast and open.
A device seem to have a certain lifespan and then the manufacturer will replace it with a new device. Is it worth reverse engineering something that you probably can’t buy anymore in 5 years ?
Indeed. And not only that. By doing so basically you would be working (for free) to the advantage of someone who is trying hard to tie users to its own proprietary platform, which is the opposite goal of what FLOSS was created for…
IMVHO, while having some DSP power in the audio interface could be useful to reduce latency if/when real-time processing is needed while tracking, or to reduce the CPU load when mixing large projects with tons of heavy plugins, I think that’s not really a good idea… much better would be to exploit some more standardized DSP processing (e.g., CUDA) on the PC. 
The closest you’ll get of having a compatibility list, apart from reading the code in the sound/ subdir in the kernel souce, is the aforementioned ALSA page
https://alsa-project.org/wiki/Matrix:Main
If you’re having problems with the card on Mac as well and also have seen forum posts about it having driver issues on Windows then it’s not the Linux devs’ fault if it doesn’t work the way you want it to.
That said, this post indicates that it has at least basic functionality right now. And with a bit of luck Geoffrey will have a driver for the software side within the foreseeable future.
https://linuxmusicians.com/viewtopic.php?f=6&t=20669
Here’s his Ardour post regarding his previous Scarlet driver
There are two parts to this.
(1) is feasible, using some USB sniffer
(2) will be hard to near impossible, most likely this is a FPGA netlist and/or some SOPC binary
In many cases there are plugins (usually VSTs) that provide an equivalent to the DSP that (2) does. This way you can use the same FX for zero-latency monitoring in hardware, and later use the same FX when mixing in software.
Usually that VST plugin also directly interacts with the device to keep settings in sync.
A practical issue with (1) is that when Linux uses the device as soundcard, it is “busy” (device in use) and you cannot access it by other means. (This is why a dedicated mixer driver for the Scarlett has to be in the kernel, and be exposed via the ALSA-mixer API. A user-space application like scarlett-mixcontrol cannot directly interact with the device on Linux while the soundcard is in use for audio/MIDI I/O.)
So even if you manage to upload some DSP firmware, you’ll still have to expose interaction with it in some way. The ALSA-mixer API may or may not be sufficient.
(2) may also have legal issues. The firmware DSP is likely patented and/or © protected. Unlike (1) it’s not an interface which can be legally reverse engineered.
Still, if you manage to solve (1), some vendors may be open to support GNU/Linux.
This topic was automatically closed 182 days after the last reply. New replies are no longer allowed.