.NET (Core and Framework)

molesworth wrote:

That's not a good idea. Any change to the play position will affect the output. The results from GetCurrentPosition may be incorrect / inaccurate due to the way DirectSound works (especially on XP).

molesworth wrote:

Your basic idea of double buffering is good, but you need to manage it in a more reliable way. The "Sleep" in particular, since it's the same length as the time to play one buffer-full, doesn't allow any time for the data copying. (You should also try to only have one copy / write for efficiency.)

molesworth wrote:

That shouldn't happen - it sounds like something else is going wrong in that case.

Andrey U wrote:

I know that the play position affects the output, but in my real application I receive packets and I can't wait.
I use PlayPosition property only for finding out what happens, so I don't rely on it.

Andrey U wrote:

I've tried different types of buffering and the only way to improve the output is to use bigger buffer, but this means more latency...

Andrey U wrote:

I've just read in another forum that this problem migth be caused by "The Windows resampler", which works better at certain rates and bad at 8 kHz. But how could I avoid this?

while (stillPlaying)
{
    CheckForInputData();

    playPos = GetCurrentPosition();

    if (playPos just crossed half-buffer)
    {
        FillOtherHalfBuffer();    // hopefully data has arrived, if not more complex logic needed
    }

    Sleep(10);    // some short-ish time
}

public void PlayingInThread()
{
    NotifyPlaying();
    playBuffer.Play(0, BufferPlayFlags.Looping);
    bool flag = true;
    byte[] data;
    while (true)
    {
        arePlaying.WaitOne();
        data = jitter.Get();

        if (flag)
        {
            playBuffer.Write(playBufferBytes / 2, data, LockFlag.None);
        }
        else
        {
            playBuffer.Write(0, data, LockFlag.None);
        }

        flag = !flag;
    }
}

class JitterBuffer
    {
        Queue<byte[]> mBuffer = new Queue<byte[]>();
        int mItemLength;

        public JitterBuffer(int length)
        {
            mItemLength = length;
        }

        public void Put(byte[] data)
        {
            mBuffer.Enqueue(data);
        }

        public byte[] Get()
        {
            if (mBuffer.Count == 0)
                return new byte[mItemLength];
            else
                return mBuffer.Dequeue();
        }
    }

public void CatchUp()
{
    if (playBuffer.PlayPosition >= playBufferBytes / 2)
        playBuffer.SetCurrentPosition(playBufferBytes-2);
    else
        playBuffer.SetCurrentPosition(playBufferBytes / 2-2);
}

Andrey U wrote:

Am I right up to this point?

Andrey U wrote:

Maybe I should only drop a packet from the queue when there are a lot? (What bothers me about the threads is that I manipulate playBuffer from 2 threads in this case. Am I supposed to do it?)

Andrey U wrote:

And my last question: should I rely on the notification from a secondary buffer? I've read several times that there are bugs with it.

supercat9 wrote:

would expect two system clocks should be easily within 0.1% of each other.

Mark Salsbery
Microsoft MVP - Visual C++

sivakumar.mariappan wrote:

it may be a Mainframe Db