How do you know if hundred or thousands?
Is there a list somewhere?
It’s public or it’s a secret that only a few know?
See what happens when design to have thousands of drivers inside kernel?
You mean no one knows the exact number?
And no one knows the origin of them?
How you trust/know you are getting the best of your soundcard?
How do you know if hundred or thousands?
I don’t really have any idea what you are getting at.
You can find all the in-kernel drivers here: https://github.com/torvalds/linux/tree/master/sound
Nobody knows the exact number because these days almost all USB audio interfaces are class compliant, so they have no specific driver. Any company can bring out a new USB audio device and (assuming it is class compliant) it just works. It could be a totally new device from a totally new company or a minor variation of an existing device.
I am sure it is possible to count the devices supported by the drivers in the sound/ tree, but it isn’t trivial, since many of the drivers support several variations on a single piece of hardware. In some cases, a bit like the USB case, one driver can support many different devices from different manufacturers because they all use the same chipset(s).
Nobody really cares much about the question(s) you’re asking - the general question is: “Can I use the <DEVICE NAME> by <COMPANY NAME> with Linux?”
I think Paul is simply saying that that are many drivers and certainly too many to list in a forum like this! There are certainly no secrets…
Do you have a particular audio interface you are looking to use in Ardour? I use Behringer UMC series, an old M-Audio 192 PCI card and most recently an Audient iD44. Everything works out of the box save for the ADAT optical connections on the iD44.
and likewise, I use a MOTU Ultralite AVB interface, connected via USB (but also on my local area network via ethernet for configuration). Everything just works (except some minor issues that are caused by specific versions of the firmware in the device, and that have been discussed and largely “solved/understood” within the Linux community).
Paul, class compliant means there is a driver already inside system and you don’t have to install.
It means that the driver you paid when purchase the soundcard is given to the OS developers and not to you.
Since the software between the hardware and DAW makes a big difference I d like to know before I choose.
And what happens with pci devices or FireWire etc?
Many sound cards don’t work on Linux because they need a specific driver and the manufactures does not make one for Linux. You can find many USB devices that work in Linux because they are USB Class compliant. Are you about to buy a sound device and need to now if it works on Linux ? If so how many inputs and outputs it needs to have ?
Here is a forum discussion about Linux compatible audio devices, but it is starting to get a bit old (started in 2015). Audio Interfaces Under Linux
The rule of thumb for USB devices is if it is supported on iPhone / Android then it is USB Class compliant and works in Linux. Also if the device is supported on macOs but there is no driver download on the manufactures site, then the device is probably USB Class Compliant and works in Linux.
Knowing my hardware and the software that comes with it very well is critical for me. Just “working out of the box” is not enough some times.
Perhaps you know the driver version your system use?
Have you measure/compare with older or newer versions?
We should all keep in mind that code behind hardware makes a huge difference on the performance.
Linux device driver support doesn’t really work the way you seem to imagine.
There are (almost) no device drivers for audio interfaces on Linux that come from manufacturers. They are all written by user/developers of Linux itself.
The concept of “which version of the driver” is also not really how things thing work on Linux. The drivers are a part of the kernel, not 3rd party add-ons. So the only relevant question is “which version of the kernel do you have”. Asking about the individual drivers just isn’t a thing here.
For audio in particular, there are zero closed source drivers on Linux. Unless you insist on building your own kernels and deliberately using non-maintained, out-of-kernel drivers from some non-conformant manufacturers. Essentially nobody does that.
“Working out of the box” for me isn’t just adequate performance. I mean i get super-low latencies that enable me to record virtual instruments without ever thinking something needs to be improved. It’s the same for Windows and Mac. If your device allows you to do what you need without x-runs or other glitches then success!
If and when I come across an issue in Windows I work through the various Focusrite/Pyramix and other guides for optimizing Win10. On Linux, choosing a low-latency or realtime kernel often is all that is needed along with appropriate buffer settings in ALSA/Jack.
The important here is that you almost never improve performance or anything related by doing stuff to the device driver on Linux. The tweaks are all OS/kernel level, and they do not directly affect the device driver.
Also important: although there are a few exceptions, in general it is not normally “the device” that prevents low latency operation, but the computer as a whole. See: https://manual.ardour.org/setting-up-your-system/the-right-computer-system-for-digital-audio/ for more.
My advice @electrovalent is if you already own an audio interface plug it into Linux and see how it does! There’s nothing to lose. If you don’t own an interface there are plenty of excellent interfaces across the price spectrum that do well in Linux. At some point you just have to move past the numbers and comparisons and see if it enables you to make music / work with audio without issue.
It really is no different on any OS. I’m currently recording another Bach album and this time I’m using Win10/Ardour to do it (simply because I’m using Seventh Heaven for the reverb!). To my ear there is no noticeable latency with buffer settings at 128 samples (UMC204HD) so I’m a happy camper. Running at 96k/24-bit with two instances of Seventh Heaven (all on a 2012 custom FX-6300 build).
There is https://www.alsa-project.org/wiki/Matrix:Main which lists all soundcards know to be supported by Linux by vendor.
Manufacturers and OS developers have found a nice way to avoid comparison and customer support for what you pay, with most users not even wondering.
Try to use Win XP, first Ardour version and an older driver version and you will understand the difference of updated software in everything.
Use any device with a generic driver and then compare with the manufacturers latest version.
Remove your graphics driver and use generic (not the same).
Same goes with your soundcard just the difference there, is smaller that’s why no one cares.
But I do.
I check that before, didn’t help me to be honest.
Driver info not available in most cases.
I do care. I care that my device allows me to be creative without holding me back in any way. If I achieve that state, then numbers, versions etc etc are meaningless (as a musician who likes to geek out, at any rate).
I think you misunderstand a few things.
Newer doesn’t always mean better. There are professional studios in the world that intentionally run older software because it works. This applies on ALL OSes. Similarly I just updated my OS X machine, and despite the same audio driver, the audio subsystem is not quite as stable anymore.
That being said, on Windows and OS X you have several factors:
Audio System Used
Audio Driver (Often provided by manufacturer or installed elsewhere)
OS X Version
Kernel Version/ALSA/Audio System Used/etc.
As you can see on Linux things can be both more and less complex than you are used to. Almost all audio runs through ALSA these days. ALSA tends to be shipped with the Kernel version as it is part of the kernel. You can update it separately, but it is not for most people to do honestly. All of these things are in one bundle. They are not provided by manufacturers separately, not are they really inherently seperate from the OS itself for most people.
Your examples by the way are a bit ironic on Linux as the graphics driver in particular people tend to run the more ‘generic’ driver on audio systems (Nouveau which is open source) as opposed to the manufacturer provided driver because the former is often better performance due to being better incorporated into the kernel (Very oversimplifying here) and in some cases provides comparable performance (Generally on older cards). Now if they care about 3D performance for games etc. that is a different story of course, but one more example of why things aren’t the same on Linux as you may be used to.
The sound driver concept in Linux is very different from windows. Some things you learnt about it in windows won’t apply to Linux. In Linux the drivers are in ALSA (Advanced Linux Sound Architecture) and these drivers are not made by the card manufacturers but volunteer coders. Overall the driver quality is excellent, you need not worry about that. You can achieve similar and many times better sound card performance on Linux than in windows.
Please tell us specific details about what you want to achieve (get a existing sound card working / buy a new one that works in Linux, etc) and we can try to help you. There is no driver and version database, it does not exist.
Well I would like to go with one of the cards where better performance achieved over Windows.
Can you suggest some of them please?
I thought that code was provided from chip manufacturers, are you sure about that?
Graphics was an example. Although manufacturer’s driver archives better performance for gamers in most cases.
Studios that use old software will eventually have to upgrade if they decide to use new hardware. Compatibility issues will rise when mixing old with new. Unless they decide to keep everything “old”.
I am not saying using latest always the best choice, but you get the point here.
Yes, very sure about that. In the late 1990s and early 2000’s I was writing audio device drivers for Linux. Even when we got “help” from manufacturers, it was never in the form of (usable) code.