AudioScience GPLs Hardware-Abstraction Layer

Rob Dye writes "According to an article at RadioWorld Online, AudioScience has GPL'ed their hardware abstration layer that allows access to the DSP power provided on their audio interfaces. Stating that 'Linux is becoming more important to the broadcast and professional audio industry,' they also released full documentation for this code and intend to release ALSA drivers for their boards. This is terrific news for professional sound under Linux, especially considering the reluctance of video card manufacturers to open their HAL's."

Comments

About time

[thecoder42]

Hopefully the videocard makers will follow suit and release their drivers open source to the world.

the light is shining

[castlec]

professional rendering has been on linux for a while, mostly under proprietary apps, but they recognized the need to support more than just the proprietary OSs. It's good to see professional audio begin to make its slice available to the free world. this could be the beginning of the end of the large recording studios.

Doubtful

[wowbagger]

I don't think you can draw parallels between an audio processing card and a video card:

In an audio processing card, the "magic" is in the DSP firmware loaded onto the card, which a GPL driver will simply treat as a binary blob of data stuffed in by a user space program when the driver module is loaded.

Once that "blob" is loaded, the audio streams are fairly simple, and the "magic" of the DSP is not reveiled by feeding the audio streams in - you feed in 44.1kS/s 16x2 audio, you get an MPEG stream - that operation reveils nothing about how the MPEG algorithm is implemented. Additionally, the MPEG algorithm is well documented and public knowledge (NOT public DOMAIN - public KNOWLEDGE!)

In a video card, the "magic" is in the chip's hardware design - in that respect it is simillar to the audio card.

With one significant exception: the way you "feed" the data into the card reveils MUCH about the implementation of the underlying algorithms, many of which are trade secrets.

So while I applaud AudioScience for this move, and while this move provides a good example to the video card makers, their situation is sufficiently different from AudioScience that, at this time, I doubt this will make much difference to them.

Now, if things progress to the point where Linux is a significant fraction of the video card manufacturer's market....

Quick question

[GreatOgre]

Is it possible for the video card manufacturers to build their boards such that the information about the chipsets, algorithms, etc. are not easily revealed? If so, why don't they do so?

Re:Quick question

[wowbagger]

It's due to the complexity of the operations done by a video card.

Consider what must happen every frame of your frag-fest in UT2003:

1) The game must hand a list of polygons to the card. This poly-list contains the position of the poly in 3 dimensional space and what texture map to use.
2) The game must also tell the card where the camera is looking, how wide the field of view is, and the rate at which depth changes effect the view.
3) The card must then transform the 3D polys into a list of 2D poly.
4) The card must then try to eliminate as many of the polys as possible - the ones that won't be seen. This gets more complicated because some polys are translucent, so you CANNOT eliminate what's behind them.
5) The card must then fill in the texture, applying any bump mapping and other alterations.

There are several places "magic" happens. For example, the triangle setup (step 3) - that requires multiplying a 5x5 matrix against a 5 vector (if my memory serves - it's been awhile since I've written a transform routine like this). If you try to do this in floating point, it makes the work rather more difficult (read: a LOT more transistors). So, many venders use a simpler fixed-point representation here - and the details of that representation give a lot away about how the card works.

Then there is hidden surface removal - that is VERY complicated, and is usually done by the CPU in the driver rather than the card. More magic.

Sure, one day it may be possible to embed all those things into the card, so that all the hardware driver sees is a GLX interface, but that day is unto todays graphics cards what a modern DSP based sound card is unto a Soundblaster 8-bit.

(and yes, I've skipped a few steps in the graphics pipeline - this post is long enough as it is!)

Re:Quick question

[Hard_Code]

But most (all?) graphics programmers are programming to a high level interface like opengl or directx *anyway* (and in turn these can only use whatever the driver for the card exposes, right?), so why even bother exposing more than is necessary? Anything you can't hide, open source. I'm buying hardware, not software. If "hidden surface removal" must live in the driver, and is complicated, open source the damn thing and compete on hardware merits. The programmability is even being abstracted through mid-level shader languages, so I see the need for exposing the guts of the card decreasing. In fact, I think reprogrammability of graphics cards [and drivers] would be a great thing...you could load a module that is "optimized" for a given application instead of having a monolithic driver from a vendor which tries to balance everything accross the board.

Is there really any innovation in the closed source drivers?

Re:Quick question

[wowbagger]

If "hidden surface removal" must live in the driver, and is complicated, open source the damn thing and compete on hardware merits.

But that is exactly what the hardware venders DON'T want to do, and that is why they don't open their drivers.