Hey,
Op 19-10-12 15:29, Andrew Eikum schreef:
Patches 1 and 2 in this series look fine.
I have a series of patches similar to this one in my dsound multichannel branch. This patch seems to do too much at once.
When I did this cleanup, I split it up into four patches:
- Allocate the device format in the Device struct
- Load the default format from the IAC, not hard-coded in dsound
- Put SetFormat() calls into their own WFX that we don't really care
about 4) Always use WAVE_FORMAT_EXTENSIBLE for the device format
Tried to revisit it and split it up, but there's no sense in keeping it separate. It's in fact quite impossible to do so because of how dsound works.
What I'm doing is the smallest possible thing that makes sense. I want to have writeprimary mode separately, so the commit does pretty much that. When toggling writeprimary mode you reopen the device, those parts are in dsound.c, and you need to change the wave format. Those parts in primary.c do that.
It may look like a patch, but all the parts are needed. Splitting this up will just break it, or end up with something that doesn't make sense, some of the changes look big but it's not that big a change.
1. DSOUND_ReopenDevice format changes: - 3 cases, in !writeprimary mode it tries to allocate GetMixFormat as float, and clips channels to 2. If writeprimary, it will try to allocate a waveformatextensible for PCM and IEEE float if possible, and use that. If not possible, it just copies format unmodified. Then calls isformatsupported to get the proper format, and initializes with that.
2. primarybuffer_SetFormat changes: - some removal of code, if !writeprimary, format is not modified, but copied from the internal format instead. if writeprimary, device is reopened like before. Some format recalculations have been moved to PrimaryOpen.
3. SetCooperativeLevel changes: - Just reopen device when toggling writeprimary, straightforward.
I would love to split this patch up further, but I ended up with patches that didn't make sense from that.
~Maarten