I ran the Day 9 code successfully, the tone plays, it responds to input etc, but I noticed in the output that it was scrolling cannot lock buffer continuously.
In this area of the code for Win32FillSoundBuffer, I had forgotten about an else if it didn't succeed that printed that it couldn't lock the buffer that call. So I changed the if statement to catch the error, and then I put a breakpoint that would trigger after 9999 hits (this is how I usually count iteration loops by checking how many times the breakpoint has been pinged).
Lo and behold, every 3 calls of Win32FillSoundBuffer it would get an error and produce the cannot lock output string. I repeated this from scratch a few times and sometimes it would be every 4 calls. The Region1 and Region2 pointers were both null when the error was caught.
What was even more interesting is that if I breakpointed the actual win32fillbuffer call and simply pressed continue to watch the values change for the lock parameters, it NEVER went to error, even after dozens upon dozens of 'continue's. So I'm guessing there must be something going on in the realtime performance of directsound or my sound card that causes it to periodically null the pointers?
In this area of the code for Win32FillSoundBuffer, I had forgotten about an else if it didn't succeed that printed that it couldn't lock the buffer that call. So I changed the if statement to catch the error, and then I put a breakpoint that would trigger after 9999 hits (this is how I usually count iteration loops by checking how many times the breakpoint has been pinged).
Lo and behold, every 3 calls of Win32FillSoundBuffer it would get an error and produce the cannot lock output string. I repeated this from scratch a few times and sometimes it would be every 4 calls. The Region1 and Region2 pointers were both null when the error was caught.
What was even more interesting is that if I breakpointed the actual win32fillbuffer call and simply pressed continue to watch the values change for the lock parameters, it NEVER went to error, even after dozens upon dozens of 'continue's. So I'm guessing there must be something going on in the realtime performance of directsound or my sound card that causes it to periodically null the pointers?
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 | internal void Win32FillSoundBuffer(win32_sound_output *SoundOutput, DWORD ByteToLock, DWORD BytesToWrite)
{
VOID *Region1;
VOID *Region2;
DWORD Region1Size;
DWORD Region2Size;
HRESULT Error = GlobalSecondarySoundBuffer->Lock( ByteToLock , BytesToWrite ,
&Region1 , &Region1Size ,
&Region2 , &Region2Size ,
0 ) ;
/*if (SUCCEEDED(GlobalSecondarySoundBuffer->Lock(ByteToLock, BytesToWrite,
&Region1, &Region1Size,
&Region2, &Region2Size,
0)))*/
if (SUCCEEDED(Error))
{
blahblah code blahblah
else
{
OutputDebugString("Locking failed!\n\n");
}
} // end success if
|
What is Error variable value?
I would guess that ByteToLock and BytesToWrite values are wrong. You're asking buffer for too many bytes than it can provide. When you are pausing application with breakpoint, DirectSound empties buffer a bit more than without stopping at breakpoint. That's why it works with stopping in debugger.
Verify that you are calculating these values correctly.
I would guess that ByteToLock and BytesToWrite values are wrong. You're asking buffer for too many bytes than it can provide. When you are pausing application with breakpoint, DirectSound empties buffer a bit more than without stopping at breakpoint. That's why it works with stopping in debugger.
Verify that you are calculating these values correctly.
Edited by Mārtiņš Možeiko
on
It's something really cryptic like Err_InvalidArgs, I couldn't find a specific reference in the directsound msdn area, so I can only guess this is probably because both region1 and region 2 are null in that instance.
Yeah calculations are exactly as per the vid and the sourcecode, so it's a bit puzzling as to what exactly is causing those pointers to come up null.
Not a huge deal, I'd be curious to see if other people have hooked up the else condition and what kind of results they've gotten.
Yeah calculations are exactly as per the vid and the sourcecode, so it's a bit puzzling as to what exactly is causing those pointers to come up null.
Not a huge deal, I'd be curious to see if other people have hooked up the else condition and what kind of results they've gotten.
Invalid args error in this case would 100% mean that ByteToLock and BytesToWrite values are wrong.
Edited by Mārtiņš Možeiko
on
Not surprising since when that comes up they are both 0x000000000000