Added patches to support EAX in dsound.

[maharmstone]

Hi,

This is a set of patches to implement EAX v.1 support in DirectSound - Creative's proprietary Environmental Audio Extensions, used in a number of games from around the turn of the century.

I realize this is an awfully large patch with some decidedly non-trivial mathematics, but most of it was copied near-verbatim from Alc/alcReverb.c in OpenAL Soft 1.15.1, so it ought to be accurate. I've uploaded the Creative EAX SDK to http://burntcomma.com/EAX10SDK.zip - there's a sample called EaxTest there if you want to test the code.

Thanks

[slackner]

Very nice, good job! :) Was Alc/alcReverb.c the only external source used? It probably makes sense to copy the copyright line Copyright (C) 2008-2009 by Christopher Fitzgerald. into the corresponding Wine source files where this was used as a reference. I'll do that while merging in the patches.

[maharmstone]

Yes, it was. Thanks, I should have done that!

[slackner]

Hm, I am hesitating a bit because the first patch allocates a huge chunk of memory directly in one of the mixer functions, which might cause performance issues. Adding additional ifchecks inside of the mixer loop might also be a bit dangerous, and have a negative impact on the performance (which is already very bad, at least one opened bug report about that). I'll think a bit about it, if I can come up with a better solution. If you have an idea, feel free to update that patch.

[maharmstone]

I think it ought to be okay... the memory only gets allocated if EAX is activated or there's DMOs enabled, both of which are fairly rare occurrences. And I don't think I've ever seen a case where EAX wasn't a toggle switch in the application anyway - users can always disable it if it's giving bad performance. I imagine the DSP code will be many times slower than the alloc anyway.

As for the ifs, they nearly all take place outside of the loops. The exception is one in cp_fields_resample, but that's a straightforward boolean comparison using a variable on the stack - or even, depending on how on the ball GCC is, in a register. I can't see it making much difference to the speed.

[mmueller2012]

Why did you close the pull request?

[slackner]

are you working on an updated version? i was still busy with reviewing the rest of the patchset, since the set was very huge this might take some time. I was planning to merge later or this weekend.

[maharmstone]

I didn't close it deliberately - GitHub must have done it automatically when I reverted some of the commits. I have an updated version, but it only affects the first couple of patches.

[slackner]

Ah, okay, was already concerned that you gave up because I didn't merge it so fast ;) Will wait for the updated version then.