I think timestamp queries are supposed to return GPU-side timestamps.
Otherwise I don't see the point in adding a complex d3d query around
QueryPerformanceFrequency.
There's GL_ARB_timer_query which looks like it does what you need.
It would be nice if you used more descriptive variable names. For example:
+struct IDirectSoundCaptureBufferImpl
+{
+ DWORD buf_size;
+ DWORD pos;
What units are these sizes and positions in? Frames? Bytes? Time? What
position is being represented here, read, write, or something else?
Using more descriptive names helps when understanding and verifying code
like this:
+ pos1 = This->pos;
+ if (This->playing)
+ {
+ pos2 = This->format->nSamplesPerSec / 100;
+ pos2 *= This->format->nBlockAlign;
+ pos2 += pos1;
+ if (!This->looping && pos2 > This->buf_size)
+ pos2 = 0;
+ else
+ pos2 %= This->buf_size;
+ }
+ else
+ pos2 = pos1;
+ pos2 %= This->buf_size;
Are all of these positions in Bytes? I hope so... (Remember this has
tripped things up in the past, see bbbf72ddcb). If everything is always
in bytes, maybe make a note of that near the variable declarations, and
then verify that it's true throughout the code. Also, why is pos1 a
separate variable here?
These patches are all missing quite a lot of error handling, which
really makes me hesitate. Especially on some important calls:
+ IAudioCaptureClient_GetBuffer(buf->cap_dev, &data, &read,
&flags, &pos, 0);
+ IAudioClient_GetDevicePeriod(This->dev, &default_period, &min_period);
+ IAudioClient_Start(This->dev);
Knowing when these functions fail will help debugging if something goes
wrong. Much worse to suddenly crash four function calls later due to
invalid default_period value than to just error out appropriately when
the error occurs.
This doesn't matter a whole lot, but I think it would be more clear to
use a separate object here, instead of a separate refcount:
struct IDirectSoundCaptureBufferImpl
{
IDirectSoundCaptureBuffer8 IDirectSoundCaptureBuffer8_iface;
- LONG ref;
+ IDirectSoundNotify IDirectSoundNotify_iface;
+ LONG ref, notify_ref;
If not, at least a comment explaining why two refcounts are needed.
Obviously a test would improve it even more, if one doesn't already exist.
Hi all,
with http://repo.or.cz/w/wine/multimedia.git and
http://repo.or.cz/w/openal-soft.git you should be able to get the
benefits of openal-soft's mixer while continuing to use whatever driver
you want for mmdevapi. As a result directsound will only support
openal-soft, but multi channel is suddenly supported, as is support for
the floating point format. 24-bits and 32-bits int are currently not,
but as soon as that capability is added to openal-soft.git wine will
have a nice working dsound implementation with support for a lot of
things that are missing now. The resampling code will also be a lot
better and you should expect a higher quality when resampling is used.
The capture changes should work nicely, and I don't expect a problem
with that, since it's based on openal. The rendering code is essentially
reviving the old dsound-openal, and outputting it to mmdevapi.
Note: 24-bits and 32-bits int are unsupported and will most likely cause
a crash, disable the #if 1 in get_fmtstr_EXT to prevent lying about
support. It was put in place so the wine dsound tests would pass.
A dsound.dll.so binary with openal-soft.git statically linked in can be
found at: http://www.astro.rug.nl/~lankhorst/dsound.dll.so
If you're using pulseaudio, patch your 32-bits alsa-plugins with the
attached patch, or silence may occur when using the new mmdevapi drivers.
Cheers,
Maarten
2011/4/26 Nicolas Le Cam <niko.lecam(a)gmail.com>:
> msdn tells us to use 0 to disable colorkey [1]. Let me know if you
> think it isn't the correct things to do.
>
> [1] http://msdn.microsoft.com/en-us/library/bb172902%28v=vs.85%29.aspx
>
> --
> Nicolas Le Cam
>
Argh, this was already spotted by Gerald Pfeifer some time ago and I
told him I was going to send a patch, which didn't happen yet...
I'm sending it now (I prefer to fix this in a different way), assuming
your patch wasn't already committed by AJ.
Nikolay wrote:
>> Who has authority to approve it?
> A patch? Alexandre Julliard, he's the only project maintainer.
> Send a patch to wine-patches at winehq.org when you think
> it's ready and you'll get some feedback if it's not.
Be sure to send it to winetestbot first, and fix any problems it finds;
see http://wiki.winehq.org/SubmittingPatches
- Dan
