Smooth streaming with DirectSound

ergonomy_joe

Hi there,

I am doing an application (actualy and emulator) which runs at 60 frame per seconds. Each frame, I am locking a 735 bytes of data from the soundbuffer and copy the sound data generated during the last frame.
. The frame rate is controled by polling the InVBlank field of a D3DRASTER_STATUS structure (from directX).
. The soundbuffer is WAVE_FORMAT_PCM, 16 bits samples, 44100 Hz sample rate
. 735 is 44100/60
. the buffer size is 0x8000 (it is a little arbitrary, I didn't really think about a size as an issue in fact)
. When locking the soundbuffer, I do not use DSBLOCK_FROMWRITECURSOR. I read somewhere that this feature may be buggy, and that the application should keep track of its own write cursor.

The sound is smooth, but at some points, it seems that the readcursor and the "application write cursor" get desynchronized. On the case of the computer I'm testing on, the read cursor seems be a little slower than the write one.
So first the image and the sound gets a little desynchronized (to the extend of the buffer size). And when the write cursor crosses the read cursor, it makes noise.

If you read that far, thank you :-D

So now, here is the problem. Is there a good way to do "cursor computation" so that the sound rendering always sounds smooth ? Some kind of formula ?
Let's say I read the read cursor, makes a diff with the write cursor, and update one or the other, what should be the parameters ?
Maybe it's my way of feeding the buffer which is bad from the start ?

Any suggestion, help, warm words of encouragement, congratulation, ... would be greatly appreciated.

Thanks in advance.

Joe
Fo-su to tomo ni aran koto wo.

dabuzz

Hi.
I have exactly the same problem.
It dosent seem that the writing and reading done wrongly its just that the playing is done little bit slower then capturing.
Dose anybody have a solution for this or an explanation why this happens?

ergonomy_joe

: Hi.
: I have exactly the same problem.
: It dosent seem that the writing and reading done wrongly its just
: that the playing is done little bit slower then capturing.
: Dose anybody have a solution for this or an explanation why this
: happens?
:

Hey cool, I feel less lonely this way.

But in fact, I think I found some explanations to my troubles.
BY READING THE DOCUMENTATION. Yes stupid of me, I didn't do that seriously the first time.
So what I do know is, before locking my secondary buffer, call the GetCurrentPosition() method.
I read somewhere that the returned "writeCursor" is inaccurate. But I think it's ok with it; playCursor and writeCursor indicates the buffer's zone that should'nt be lock (and maybe you get an error if you do).
So (as stipulated by the documentation) I keep track of my own write cursor. If it "falls" into the zone [playCursor, writeCursor] I update it to the writeCursor value.
Also, if the size I want to lock makes the upper bound of my locking zone bigger than the playCursor, I update this size so that it fits in the "lockable" zone.
So maybe it's not related, but I got a better rendering this way. Only some "scratches" from time to time.

But now comes the new question. Reading the code of other people -- yes I do that from time to time m(_'_)m -- I found that a common practice is to create a primary buffer just play it and in fact lock/unlock a secondary buffer. It looks like you should set the primary buffer to the same format as the secondary buffer to avoid performance loss.
Does this mean that if you don't create this primary buffer, you get a default one ?

by the way Dabuzz, which kind of application are you working on ?

Joe

dabuzz

Actually i am adding a voip like support to our game center software gizmo.smartlaunch.net.
Well i also found interesting thing. Although i have read the documentation where is stated that creating a buffer in software would make playback notifications to fire at correct position it didnt. If you start any other application that might use direct sound the playback notification events occoured in wrong positions sometimes or even with 0 ms difference. So i had a problem with calculating the prebuffered and played data. Now the problem stays the same with captrue buffer being ahead of playback buffer. There must be some standard solution to handle this situation there is so many software out there using Directsound as core sound engine.
By the way you shouldnt feel loneley as there many people expirencing this problem the bad thing is that i found 0 answers on how to resolve the problem correctly.