[MPlayer-cygwin] questions about ao_dsound

[Sascha Sommer]

On Sunday 10 October 2004 15:15, Florian Dietrich wrote:
> Hey guys!
>
> Great to see that mplayer now has DirectSound output! Good work!
> I was actually the one who wanted to implemented this earlier this
> year, and i already had a lot of work done, but unfortunately it all
> got lost during a hard drive crash.
>
> Now I finally had the time to work on it again, but just when I had
> it all done and wanted to check in a working version I saw that there
> already was one :-)

:( There were quite a few people who wanted to write ao_dsound, Gabor
was the first who actually sent working code. 

> However, there are a few questions about DSound in general and about
> the current implementation:
>
> * First a little bug report: In ao_dsound and in ao_win32, you fill
> wformat.Format.cbSize with sizeof(WAVEFORMATEXTENSIBLE). But cbSize
> is only supposed to be the size of the additional members, so it
> should be sizeof(WAVEFORMATEXTENSIBLE)-sizeof(WAVEFORMATEX).
>

I'm not 100% sure. While cbSize should be zero when WAVEFORMATEX is used alone  
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/multimed/htm/_win32_waveformatextensible_str.asp
says that it should be at least 22 for WAVEFORMATEXTENSIBLE.

> * As you had realized, the channel order in AC3 is different from the
> channel order Microsoft uses. Now, the channel order MIGHT again be
> different on different audio formats. So how exactly are we supposed
> to know how to re-order the channels correctly? We could always do it
> the way it would work for AC3, but like I said, it might not work
> formats that order them differently then.

That is an interesting question and there should still be a way to swap the 
channels in an audio filter. However I think it is ok for now to reorder them 
so that it works for ac3. We have to copy the data anyway. Hopefully there
won't be to much speed difference.

> * Is there a reason for all the 'trouble' with hdsound.dll? Why not
> simply add -ldsound during linking? This worked just fine for me, and
> imho having to play around with DLLs is unnecessary.
>

I think it doesn't matter if  we do dynamic or static linking. The current way 
has the advantage that MPlayer will at least startup on systems without 
directx. I don't even know if there are such systems, though.

> * Why not calculate the buffer size more precisely? We have all the
> info we need to calculate how many bytes we play in a second, so why
> not pick a size corresponding to a certain amount of seconds?

If you could improve this that would be great.

> * I think there *might* be a bug, which is only masked by the current
> buffer size and the "Restore" stuff after the lock. At least my code
> used to look very similar before, and I experienced similar problems
> until I figured out why. I might as well be wrong though.

Share the secret with us ;)

> If you want, I can send my code to the list, it is not very different
> from the current implementation. Maybe a little less cluttered,
> that's all. Or i could somehow merge the two (I don't output
> cleartext errors in my version) and send a patch.
>

I would prefer if you would improve the current code. There really shouldn't
be to many differences in the implementation. You can also clean up the 
current code, but be carefull, we won't accept cosmetic changes.
If you are not interested in it, sending your code to the list
will be fine, too.  

Sascha