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

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....

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!)