Today I did some "tests" with dmusic; I've tried to run dxdiag with mixture of builtin and native dm*.dll and I have some questions based on observations:
1. dm*.dlls don't share DllGetClassObject function like I did in wine's implementations (dm*.dlls other than dmusic.dll have their functions forwarded to dmusic.dll). Shall we implement such separation or shall we leave it as it is? (personally, I'd choose separation because then mixing dlls would be more efficient; at the moment, all dm*.dlls call dmusic.DllGetClassObject, which mean I must replace all of them with native equivalents if I want to replace dmusic.dll; besides, dxdiag crashes in a mysterious way with builtin dlls and I expect the problem lies here).
2. when listing dmusic ports, dmusic calls EnumLegacyDevice, which is stub, because I can't find any info about it's parameters... It calls some winemm stuff and lists Wine midi out mapper, although it can't be used. It is obvious that it lists devices that could be used as ports, except Microsoft Software Synthesizer, which is available only if native dmsynth.dll is used (i used native dmusic.dll). Any ideas where I could get more detailed info about what does this funct. do and what parameters it takes?
3. this one concerns RIFF loading stuff I've been working on recently. MSDN states that IStream and IPersistStream insterfaces should be used in parsing data, which means all functs. in helper.c are wrong. I'll look deeper into docs and try to find out how it's supposed to go (just expect that all functs. will be replaced so do not modify them ;=) ).