Archived

This topic is now archived and is closed to further replies.

hachi_roku

Is DirectSound a little bit strange ?

Recommended Posts

To all who already tried to use Direct Sound if have some maybe tough questions: Some specs first: PC : Athlon 500 OS : WIN 2000 SoundCard: SB 128 Vibra ( I guess ) ct4810 Using : DirectX 8.0 So far : Two buffers up and running in LOOP mode, one playback one capture, for both IID_IDirectSoundBuffer8 succesfully queried. Bufferformat: PCM_WAVEFORMAT, Samplerate : 8000 Hz , Bitdepth : 16bit, Buffersize ( both ) : 1200 bytes ; 1200 bytes -> 600 words -> 75 ms ( correct me if I''m wrong ) There I go: 1. Why does the Soundbuffer have a Notify Flag while the Capturebuffer has none ? Is it always set ? 2. Is it me or is that Notify thing inaccurate like hell ? I use the example procedure explained in the tutorial with a handle array / event objects in conjunction with the win32 WaitForMultipleObjects function. I use three Events for a capture buffer with a size of 1200 bytes, split by notifications into 3 blocks of 400 bytes. My call: Event_Result = WaitForMultipleObjects( 3, EventHandle(points to array), FALSE, INFINITE); gives me the index of the signaled handle/event object ( the first ) and I proceed. Now just for checking DirectSounds capabilities I put in a IDirectCapturebuffer::GetCurrentPosition and I get an Offset of 480 bytes after the first event at 400 bytes was triggered ! Is that possible that there is such a margin ? Or is it the Win32 function that is too slow to report the event fast enough ? This is a delay of 40 words = 5 ms of which I think it''s quite a long time for a high end tool like a pc. When I ask for the second event position at 800, the he gives me an absolutely accurate 800 !!! As much as I was happy the much I got disappointed when I lowered the event by 100 bytes. Result 800 ((( What the hell. Am I asking for too much ? Is this thing just completely useless ? My third event at a little bit less than the length of the buffer tells me that the pointer already returned via looping to the beginning again with quite a margin. Is the methode I just just too crappy or is it that I''m overlookin something. 3. Is there any syncronising at all ? The following extension First event at byteoffset 0 ( I want an event right away ! ) captbuffer8->Start( DSCBSTART_LOOPING ); // captbuffer8 = capture buffer object Event_Result = WaitForMultipleObjects( 3, EventHandle, FALSE, INFINITE); hr = captbuffer8->GetCurrentPosition( &CaptPos, &ReadPos); The result : Value of Captpos = 160; Lame as always but expected :/ Now I also start my playbackbuffer which got the pointer to the same WAVEFORMAT struct. No difference ! captbuffer8->Start( DSCBSTART_LOOPING ); // captbuffer8 = capture buffer object soundbuffer8->Play( 0 , 0 , DSBPLAY_LOOPING ); // soundbuffer8 = playback buffer object Event_Result = WaitForMultipleObjects( 3, CaptureEventHandle, FALSE, INFINITE); hr = captbuffer8->GetCurrentPosition( &CaptPos, &ReadPos); hr = soundbuffer8->GetCurrentPosition( &PlayPos, &WritePos); Again Result of Captpos = 160; But now ! The Result of Playpos is between 270 and 340 !!!! Now I''m lost. I can practicly give up ''cause this definately doesn''t make sense at all. How in the world can it be ahead ??? Could anybody explain this. Maybe I really makde a very stupid mistake but I really wanna know. Anyway just to make this whole I tried the opposite way around and made Playback Notifications. soundbuffer8->Play( 0 , 0 , DSBPLAY_LOOPING ); // soundbuffer8 = playback buffer object Event_Result = WaitForMultipleObjects( 3, PlaybackEventHandle(points to array), FALSE, INFINITE); hr = soundbuffer8->GetCurrentPosition( &PlayPos, &WritePos); Result : 160, the Notification for the Playpointer is as lame as for the Capturepointer. Now the same thing as before: captbuffer8->Start( DSCBSTART_LOOPING ); // captbuffer8 = capture buffer object soundbuffer8->Play( 0 , 0 , DSBPLAY_LOOPING ); // soundbuffer8 = playback buffer object Event_Result = WaitForMultipleObjects( 3, PlaybackEventHandle, FALSE, INFINITE); hr = soundbuffer8->GetCurrentPosition( &PlayPos, &WritePos); hr = captbuffer8->GetCurrentPosition( &CaptPos, &ReadPos); Whilst the Playpointers position is always as before the Capturepointer is between 0 and 96. That was to be expected due to the same difference in both tests. My question is, can this be characterized somehow ? And why is the pointer of the capturebuffer not further even if I start capturing first ??? I have even more questions regaring this but I think that those will be solved if the ones mentioned are answered. I''m grateful for any comments regarding that phenomenon and thanks for reading all this.

Share this post


Link to post
Share on other sites
Windows is only good to about 10ms by default, it can be worse on some machines *cough*Compaq*cough*. You can call timeBeginPeriod(1); to change the switching time to 1ms. Even then those notify events will _not land perfectly - it's not like you're in an ISR - so your code needs to check the position and work with however much data is there.

Magmai Kai Holmlor
- Not For Rent

I used a large buffer (5seconds) and polled it every 50ms. Setting up 1000 notify events didn't work so hot.

quote:

My question is, can this be characterized somehow ?


Yes. It's unpredictable.

quote:

And why is the pointer of the capturebuffer not further even if I start capturing first ???


Good question. Is the offset about the same amount? (it will of cource twiddle, but does it flutter aruond the same value or drift higher or lower?
Oh, DS8 is threaded, so just calling one start before the other, does not in fact garuantee that it will start first Put a Sleep(10) between them if you want the playback buffer to be ahead. Without hardware triggering it's impossible to make them start at the exact same time (actually, even _with hardware triggering it's nearly impossible - it's usually good to a microsecond or so a hardware trigger. A software trigger is good to, oh say, a millisecond or more, and it will *not* be consistent).

Edited by - Magmai Kai Holmlor on November 3, 2001 1:12:17 PM

Share this post


Link to post
Share on other sites