Andrew Eikum wrote:
Does CoTaskMemFree match HeapAlloc?
would anyone more familiar with CoTaskMem* want to comment?
[cbSize slot present?]
Hm, to my surprise it seems MS no longer does this check as of Win7.
Well, it's consistent with the documentation. So it's only the winmm API that has to be careful.
I went with the easy and probably good enough solution of only supporting a few common rates.
I may make perfectly sense with the new API. Modern apps seem to use mostly 48000 these days, with a few 22050 to mix for fun.
We'll just have to be careful in WinMM to pass a valid structure through.
Not only that. Old winmm apps expect weird rates like 9128 to work. So winmm->mmdevapi may not be a simple pass-through. OTOH, winmm probably won't use isFormatSupported and just get what ALSA returns.
Hmm... We should add one winmm test with such a weird rate and expect all Wine machines to play it.
An idea that goes a long way is to use a powerful machine to run software from a less powerful one. Here powerful translates to "pretend to be equipped with one of the best quality and least troublesome sound cards that the old SW might have known".
The argument is not unlike http://source.winehq.org/source/dlls/wined3d/directx.c#L2048 /* Default to generic Nvidia hardware based on the supported OpenGL extensions. The choice * for Nvidia was because the hardware and drivers they make are of good quality. This makes * them a good generic choice. */
That's probably a card which could play weird rates and several samples concurrently. Thus if my poor on-board audio card can't, the middleware (Wine or ALSA) ought to do it, resampling and mixing as needed, given that the powerful machine is fast enough to do that. That's IMHO why dmix is the ALSA backend that Wine should expect: an allrounder. Wine should not try to deal itself with the idiosyncrasies of current audio cards.
Well, that's my opinion. YMMV, especially if you want to use Wine to run the most recently released apps, then you probably expect Wine to deal with weird (but modern) audio HW and drivers -- like MS has done for 2 decades.
Regards, Jörg Höhle