rrttdd

Prolog:
During the late 1990s, Aureal has been Creative's most dangerous competitor. They did compete against Creative with their Aureal A3D API, which gained huge advantages over Creative's EAX.

While Creative's EAX used a fixed set of standard reverb filters for different environments at that time (like "living room"; "cathedral" etc..), A3D allowed the level designer to assign reflection attributes to the surfaces of the virtual rooms. A3D was able to calculate the waveforms of sounds according to the reflections of the surfaces they had passed. This technology was by far more sophisticated and realistic than the simple EAX at that time.

To accelerate these wavetracing calculations, Aureal developed their AU8820 (aka. Vortex 1) and AU8830 (Vortex 2) soundcard ICs. They were used by several soundcard manufacturers like Diamond or Terratec. With the release of the latest Win 9x refrerence drivers, even soundfont support was added, so there was no need to buy a Creative card anymore.

The sales of the Aureal chips increased and increased, and so the market leader Creative decided to sue Aureal for (alledged) patent infringements.

After spending millions of $$ for lawyers, Aureal finally won the lawsuit. But it was a phyrric victory. The costs of the proceedings have been too high for Aureal and forced it into bankcrupcy. Creative Labs bought all assets, know how and technology of Aureal. A3D and the Vortex chipsets vanished from the market.

The Situation today
The main gaming operating system of the late 90s, the market Aureal aimed for, was Windows 98/ME. For these systems exist several versions of the full functional closed-source Aureal reference driver for AU8830.

It also was foreseeable that MS would switch their OS platform away from DOS to NT/Win 2000. Aureal released some Versions of a beta reference driver for Windows 2000. Several details, like 4-speaker support, don't work with that driver. MS later put the latest release into the first version of Windows XP. Due to memory management problems of that beta driver, MS released an "updated" Version with SP1 for XP, which reduced the functionality of the AU8830 to a simple stereo I/O device. All the support for A3D hardware acceleration had been removed.

AFAIK, MS published further basic drivers with Vista (x32) and Win 7 (x32). So I think they have the source code and did some quick ports for their newer Windows versions. It is also understandable that they don't waste (in their POV) effort in writing a x64 driver for that chipset.

For Linux, there is also a driver available which offers basic stereo functionality.

My thoughts
I wonder if it could be possible to write an alternative XP/Win7 driver which also supports 64 bits and stuff like hardware accelerated Open AL?? The kX project managed to write drivers for the Audigy 2 ZS etc., which are probably more complicated. The AU8830 and also the AU8820 are chips with so much unused potential within current OSses, what a pity...

The problem is that I don't know how and where to start. On my old driver CD, there should be some A3D demos.... I'm sure the API documentation and SDK was published in the 90s (mainly for Win 9x...). The problem is the communication between driver and AU88xx. There must be lots of geometrical and reflectional data als well as PCM data transferred to the soundcard...

I probably have to set up a Win 98 system, install the card, run some demos and try to monitor the data transfer with tools like RW-everything?



But it probably is not that simple...
I tried RW-everything yesterday evening with my Maya 44 PCI card (Ensemble Envy24 HT). I obviously found the mixer register, but not the PCM data I/O ports...
What approach did you use for the KX project?

Further information:
http://www.combatsim.com/htm/june99/sound-api2.htm
http://en.wikipedia.org/wiki/A3D
http://forums.eidosgames.com/showpos...9&postcount=11
http://books.google.com/books?id=1AE...aureal&f=false

Max M.

I wonder if it could be possible to write an alternative XP/Win7 driver which also supports 64 bits and stuff like hardware accelerated Open AL??

Everything is possible provided you have enough motivation and time.

The problem is that I don't know how and where to start.

The solid start would be learning generic Windows driver development, then crafting you own driver with "basic stereo functionality" and then extending it to support any high-level API you like (A3D, OpenAL, XNA.Audio etc.).
Any 3D API is based on the same "PCM data transfers" stuff/core/code as "basic stereo functionality" does, so the one won't get anywhere without the other (Basically each "3D voice" is a plain mono/stereo PCM buffer with further panning, filtering and reverberation applied).
To get go with a 3D API support you'll have to "recreate documentation" for ("how to program") the AU8830 ALU/registers/memory blocks responsible for those 3 signal processing units: panner/filter/reverb.

There must be lots of geometrical ... data ... transferred

AFAIK none of sound chips of 90's (and none of today's) processes geometrical data directly - in most cases it is the driver who takes the geometry input, applies any transformation and calculates necessary coefficients (per-voice and/or global) to be written to hardware memory/registers. Yes, the coefficients for those 3 processing units (yet again panner/filter/reverb).

run some demos and try to monitor the data transfer

It's not a good idea to use demos for this - demos usually have too many too dynamic voices so the monitoring will provide you with too large too chaotic data to get any valuable information out of it. It's better to start with some tool (a few are/were available for almost any 3D API) that can setup/play a single voice with static position/parameters.

I tried RW-everything yesterday evening with my Maya 44 PCI card (Ensemble Envy24 HT). I obviously found the mixer register, but not the PCM data I/O ports...

Usually PCM data transfers are done via DMA (i.e. PCM data is not "copied" to hardware directly - instead driver just needs to set the pointer to PCM data in host-memory) so actual data transfers may be hidden behind just one or two registers (host-memory-address + start/stop/etc flags).

Also take into account that hardware may have indirect memory space which is not directly mapped to PCI I/O (for example in emu10kx - the most of functionality (= thousands of registers) is hidden behind just two PCI I/O registers (known as PTR/DATA pair)). Most likely most of not-so-simple audio controllers use similar scheme.

What approach did you use for the kX project?

Well, at times we did it (>10 years ago :) there were not so many tools for hardware I/O monitoring so yes we had to craft a few tools of our own. But eventually the further you go you'll probably realize that you need your own dedicated monitoring utility anyway - you just progress faster with all those human-readable register names, uncrypted indirect memory I/O read/writes, some filtering (register-of-interest or redundant state changes) etc. etc.

----

I'm sure the API documentation and SDK was published in the 90s (mainly for Win 9x...)

Those high-level API documentation and SDKs (like A3D SDK or EAX SDK) provide no information on corresponding hardware programming so this won't make writing driver code easier. (It's only nice to keep those docs as a quick reference card of what-particular-hardware-is-capable-of, that's it).
I don't remember I have ever seen a hardware-related (signal-processing-unit registers map at least) AU88x0 documentation, but also I can't say I remember I haven't seen any for all those years. Not sure.

----

Usually the point of loosing interest for most people is "... learning generic Windows driver development, then crafting you own driver ..." :) - well, we'll see.

__________________

Max M.

btw., here's the list of related Aureal patents (you can find pdfs in the net) - those might be useful to see what units/blocks you're expected to find in the hardware:
Economical Generation of Expontential and Pseudo-Expontential Decay Functions in Digital Hardware (US555722)
Programmable Bus (US6526518)
Methods and Apparatus for Managing Multiple Direct Memory Access Channels (US6434645)
Three-Dimensional Virtual Audio Display Employing Complexity Imaging Filters (US6072877)
Methods and Apparatus for Efficient Presentation of High-Quality Three-Dimensional Audio Including Ambient Effects (US5802180)
Methods and Apparatus for Efficient Presentation of High-Quality Three-Dimensional Audio (US5596644)
Three-Dimensional Virtual Audio Display Employing Complexity Imaging Filters (US5659619)

Also I've looked in ALSA sources and it appears to provide some basic 3D functionaly for au8830 (i.e. = definition of related registers in headers) so it could be much easier to jump into au8830 signal-processing unit programming (provided the corresponding license applies).

__________________

rrttdd

Thank you for your reply.
I wonder if it's really that simple on the Vortex chips. Aureal always claimed that A3D is not just a simple reverb engine like EAX with "bathroom" filters or stuff like that. Each wall has sound reflection attributes, and the 3D voice is calculated considering several reflections. You can see 3D demo screenshots by clicking the google books link I posted above. That "Wavetracing" technology has been a kind of unique selling point of A3D, and the AU88xx were able to accelereate that in hardware.
I could imagine that the "reverb" section of the chips must be quite a complex thing. I would suppose there must quite a high number of "hardware reverbs" which can be connected and compiled to cascades in a quite flexible way. The demos also show that there are straight distances and things like angle of incidence=angle of excidence used for the calculations of the way of the soundwaves. So, for futher accelerating of the basic calculation of the way of a sound wave (and for proper and quick programming of the reverb cascades with correct parameters) it might also be possible that there's also a kind of "triangulation co-processor" included...


Thanks for the advice.



You can also see required parameters and and probably how they are passed to the driver.


Of course you need to know how to write a driver before you can write a driver... Trying to rewrite the Alsa drivers for Windows to get a stereo I/O is probably a time consuming task...

The "recreation" of the documentation of that closed source chip and revealing its secrets should be even harder. Some functions can probably be revealed by (self-written) software tools, but I really wonder how to catch DMA transfers of certain drivers...

Max M.

I wonder if it's really that simple on the Vortex chips.

Where did I say "simple"? Reverb is a reverb no matter how complex or simple it is. And if some unit adds reflections to the sound this unit is called "Reverb". And if there are many of such units then it's just "Reverbs". That's it. The same applies to filters and panners. Be it complex ITD/ILD panner or a trivial left/right one, basic Biquad or scary HRTF filter, it does not matter - these are still "Panners" and "Filters").
I guess I should be more careful with the terms I use since you seems to be too much biased towards that 10-ten years old "EAX vs. A3D holy-war" and tend to fall into such discussion very easy. But I don't think I'll participate. So don't like the word "Reverb"? Prefer long-scaring-hype loud slogans from some consumer posters? "Magic Wavetracing Unit"? Fine (just be ready engineers (like me) stop to understand you).
No panner/filter/reverb (yet again no "simple" here - in fact a combination of these units - especially a per-voice combination may be very very complex)? Let it be. There's "triangulation co-processor"? Sure it is, if you believe so (I won't argue - I have my reasons to be sure there's not - but it does not matter just because you will find the answer ("Is or Isn't"?) yourself eventually as soon as you get further with your driver development). OK, I hope you've got the point.

----

You can also see required parameters and and probably how they are passed to the driver.

Sure. But at this point you're more interested to know what parameters the driver should pass to the hardware
(and these parameters typically have very few to do with parameters passed to the driver since level of "hardware abstraction" of such APIs usually is *very* high).

----

Trying to rewrite the Alsa drivers for Windows to get a stereo I/O is probably a time consuming task...

I did not mean "rewriting Alsa for Windows" I only mentioned Alsa code as source of hardware information (available registers/blocks and their use).

but I really wonder how to catch DMA transfers of certain drivers...

Since you can control the transfers (i.e. usually one starts when you start to play something - i.e. hardware voice/channel starts) it's just a matter of monitoring register changes on those starts/stops. Sometimes this could be pretty non-trivial and time-consuming (once I had to analyze a ~1.5GB log for a week or so to find the location of a single(!) bit(!) responsible for some external add-on box (that was EDrive) initialization ;)
Luckily, in you case you can skip the "basic stereo functionality" DMA transfers monitoring since you can look up this stuff in Alsa code (at least at the starting point - eventually you'll find yourself monitoring that stuff when your initial code starts to work wrong - as every initial code does). (I would also add that "and these are the only DMA transfers there - everything else is programmed through PCI I/O registers" - but considering that there's a "Magic Triangulation Co-Processor" I won't ;)

----

P.S. Just in case - since I mentioned Alsa a lot I guess I should be more specific: all information you need there is in "alsa/alsa-kernel/pci/au88x0/"

__________________

rrttdd

I searched the web and found out that somebody has tried that task some years before...

http://web.archive.org/web/200512160...jander/aureal/
Index of /~mjander/aureal/re
Aureal Audio Chipset technical description

That auhook driver seems to be the self written I/O monitoring driver you were talking about.

stylus02

there are a lot of reverberation algorithms made since the first theoretical (scientific) works of moorer/ schroeder in the 1960's. you can go back hundreds of years to mathematicians leibnitz, fourier, laplace, gauss and so on - they dreamed about it. everthing is based on any recursive mathematical equations. some are more complex than the others: comb filters, waveguidemeshes, feedback delay networks, convolution, mixtures of all that with filters and amps in any place of the signal path. informations about that are free available in www, it's allmost a piece of physical science.
since, let me say 1996, every of that ideas could be realized with a pentium processor, not allways in realtime, but as waverender.
what i try to say is, that a hardwarechip for reverberation in the year 2000 was difficult to place on a more and more software- dominated market. the german synthesizer company "waldorf" had to face the same problems at this time - their sales went back. but no one offered hardware- specifications about their synthesis- chips.
we have to ask: why the companies internal informations are available for everyone at all?

__________________
http://kxm.dyndns.org