[ardour-users] A decent sound card for Ardour

Thomas Vecchione seablaede at gmail.com
Sat Feb 10 10:24:08 PST 2007


John-

    What you are describing is the job of the distribution, not of linux 
itself.  There is an important distinction there.

    In many cases of linux, you will never deal with installing drivers, 
though saying you never have to install drivers manually in windows is 
being hopeful at best.

    What the common desktop distribution aims for is to make these 
things as painless as possible.  Though different distributions have 
different priorities in as far as this is concerned.

    Example would be the Realtime-Preemption Enabled Kernel.  In a 
common Desktop Distribution, you will not find this in most cases. 
Whether or not you should is a different story.  In a music oriented 
distribution you will find this.

    Does this make it harder for a device manufacturer to provide a 
driver?  If it is open source absolutely not.  Why?  Because the 
distribution is tasked with the job of making sure it has appropriate 
drivers for its setup.  The open source driver is able to be compiled 
against the kernel headers, that is all it needs.  The distribution 
takes care of providing the precompiled version.  The device 
manufacturer should only be keeping its driver up to date against the 
linux kernel version and providing bug fixes in the source.  While the 
kernel source is updated constantly, the basic API for the driver does 
not change often is my understanding.  In many cases drivers do not need 
to be updated unless there is a major shift in kernel versions(2.2 to 
2.4 or 2.4 to 2.6 for example).  That does not happen any more often 
than Windows updates its kernel.  So in actuality it takes just as much 
effort to maintain an open source kernel driver for Linux as it does for 
any other OS really.

     Closed source drivers should not exist.  The closest they come is, 
as an example, NVidia's drivers that have a binary closed source blob, 
with an open source layer connecting it to the kernel.  The 
appropriateness of this solution and legality is a debate for a 
different list and time.  But at any rate the open source layer there 
only changes more often if the binary blob it connects to changes. 
Essentially if anything closed source makes it harder on the 
manufacturer, but truthfully it should make it about the same difficulty 
to maintain as they normally would.

 > It stands to reason that any kernel based driver is never going to 
work in
 > every conceiveable case.  Of course, there'll be thousands of cases where
 > the drivers work first time - but there are bound to be cases where the
 > standard drivers don't work or need to be upgraded.  And therein lies the
 > problem.

Why?

If the driver needs to be upgraded fine.  You can upgrade the driver 
without it affecting the rest of the system.  In fact with ALSA drivers 
I used to do that quite regularly as I had a poorly designed piece of 
equipment for a while that I was continually looking for updates to the 
driver to handle it.

 > Re-installing or upgrading drivers under Linux is simply
 > too difficult for the average computer user.

This is true of ANY OS.  I still get asked to install printers in 
windows by others, or any other driver.  The primary difference?  In 
windows I have to go track down the drivers on the manufacturer's 
website.  And so help me if the manufacturer is out of business, or the 
driver for their version of windows is no longer available on the website.

 > There are too many different
 > methodologies and even within those methodologies, there are too many
 > variations.


Again this goes back to your choice of distributions.  This is the 
different distributions causing this, but from a manufacturer's point of 
view, it won't matter, all they have to keep up to date is the open 
source version of their driver.

 > I can fully understand why hardware manufacturers want to avoid a 
scenario
 > like that.  It's the #1 achilles heel with Linux and, for reasons which I
 > don't understand,  the entire community seems hugely resistant to doing
 > anything about it

Because you are misunderstanding the role of various things in Linux. 
What you are labeling as Linux right now, are the distributions of 
Linux.  That is a very important distinction.  That is where 95 percent 
of your problems seem to stem from(Well that and the firmware issues 
courtesy of things not being kept up to date in the open source driver 
by the manufacturer, like they have done for any other OS with the same 
amount of work involved.)

As I mentioned above, what distribution of linux you are using does not 
matter to the driver.  So therefore this is not a reason for a 
manufacturer to ignore Linux.

 > The community might have practical reasons for being
 > so reluctant; or the reasons might be political; or historical; or
 > philosophical - but whatever those reasons might be, they've led to a
 > hotch-potch of disparate methodologies that is almost guaranteed to
 > produce failure.

If you go with LFS(As an example), the method of installing a driver by 
hand is the exact same method that will work on ANY distribution.

To install a driver by hand, you need the kernel headers for the kernel 
you are running.  You then compile that driver.  You then install the 
driver.  Literally it is 2 or 3 commands in most cases with an open 
source driver.  And those same 2 or 3 commands WILL work anywhere.

The problem you are seeing comes from package management systems, and 
the number of different ones that are out there, and the variety of 
distributions.  If you do those same three steps on Ubuntu, it wil work 
fine, but APT on Ubuntu will not recognize that you have that package 
installed unless you tell it you do.  Thus when you install a package it 
thinks requires the package you installed manually, it will think it is 
not installed and install a new one, thus overwriting your package.

Does ANY of that have anything to do with the manufacturer?  No.  The 
manufacturer's driver has not changed in the least.  But it means to 
install for that distribution, your best bet is to use its package 
management.  And yes I will agree that because of the variety of choices 
out there, things get confusing unless you stick to your distribution's 
instructions.  But if something doesn't work right in that, you need to 
tell the maintainers of that distribution, so it can be fixed.

 > It's all very well to blame the manufacturers but
 > personally, I wouldn't blame any company for wanting to keep its distance
 > while this sorry situation persists.

Again everything you have listed has nothing to do with the manufacturer 
keeping an open source driver for their hardware.

 > Linux
 > URGENTLY needs to thrash out a simple, unified strategy for driver 
upgrades.

No.  Distributions of Linux need to agree on one way for pacakage 
management systems to communicate.  Thing is it won't happen as some 
people prefer one method to another, and that is why Linux is great.  It 
gives choice.  In this case choice of distribution.  But whether or not 
it does happen has nothing to do with the manufacturer.

       Seablade



More information about the Ardour-Users mailing list