Day 20 Sound Question: Write cursor calculation

Hi.

I've just finished day 20 and I have a question regarding the calculation of the target cursor.

We spent a lot of time calculating the number of seconds and then bytes that is expected before the flip happens.

Why calculate the ExpectedByptesUntilFlip variable if it never gets used anywhere?
Am I missing something or is this changed later in some other episode?

I suspect it should be used in calculating the next line:
DWORD ExpectedFrameBoundaryByte = PlayCursor + ExpectedSoundBytesPerFrame;
I think this would be fixed on day 24 or something like this.
Ah, thanks.
I will wait to get to that video.
This is why you never turn off the unused variables and parameters warning!

I have a question about this lesson too:
Should the white/red lines be equally spaced? On the video they appear to be equally spaced but mine are everywhere. I am typing along and not looking at Casey's source code (to prevent myself from getting lazy) I might have bugs.
Do you have any idea what I might have missed?

Also the sound still skips even on the stream (I think) and the volume changes. Is that my fault or does this get fixed?

Edited by Hristo on
Why don't you try running Casey's code to see if it behaves the same on your system?
This is a good suggestion but I don't want to take the source code yet (not at least for a few months) because I might be tempted to start cheating :woohoo:
I'm trying to catch up with the stream yet. I missed the start of the series.
OK. I couldn't wait any more :) I got the original code compiled it and the sound is clicking badly. So my typing is not the problem.

The sound was OK before this episode.
You can try to run Casey's code from day 24 and see if it it solves the issue.
He made some changes there to fix a bug.
If not, then I don't know. The yellow line should be as close as possible to the play cursor, but always to the right of it.

Maybe you have have a better sound card? The one Casey (and me too) is using, has a very big latency. It may be that there is a bug in the code that is only showing up on your configuration.

Edited by Stefan on
I think I have the same or a familiar problem. :(

I don't want to check the source code aswell, because I want to write on my own. I learn much more that way..

So I get random skips/cracking noises aswell, after Day 20 and I dont know what the problem is. I've been looking, but Soundoutput was very complicated, so I'm not sure if I understand everything that might cause a bug.

I fixed the bug at the beginning of day 24 (I sneek peeked from Day 20 - but I found that one myself already). Has anyone got an Idea what could be the problem?

I'll attach some screenshots so you get an idea..

[attachment=24]day20_1.jpg[/attachment]

[attachment=25]day20_2.jpg[/attachment]
I think you can see the skips clearly there.

@Zingam: Did you fix the cracking?
I cant say why you have a bug, but as you can see from your screen shots, the yellow line is before the play cursor. So the sound data is not written far enough ahead of the play cursor.
Just to get things straight and I understand them correctly:

0. row: all the old play and write curors:
If its the CurrentMarkerIndex we go on row down:
1. row:
Here we are before we calculate where we write sound
OutputplayCursor: White
OutputWritecursor: Red

2. row:
OutputLocation (this is where I'm writting to): White
OutputLocation + OutputBytecount (this is where we stop writing): Red

3. row
FlipPlayCursor: White
FlipWriteCursor: Red
These are both very shortly after the page flip..

Yellow Line:
ExpectedFlipplayCursor (should almost be the same as the FlipPlaycursor from 3. row?)

I dont really get what you mean :/

Edited by Dominik on
You want the expected cursor to be as close as possible to the actual flip cursor.
It is acceptable for the expected flip cursor to lead the actual flip cursor, but you will have more sound lag, the more it leads.

If the expected flip cursor is trailing the actual flip cursor, you are in trouble because you are writing where they cursor has already been.
Hope that makes sense.
The way I see it, it should not be a problem. Because the yellow line only estimates where the Pageflip should be, but I write the sound somewhere entirely else:

The write is actually the white line in the second row, which is far ahead of the actual and estimated PageFlipPlaycursor of the third row.
if(LowLatency)
{..}
else
{
TargetCursor = WriteCursor + ExpectedSoundBytesPerFrame + SoundOutput.SafetyBytes;
}


Plus somtetimes the estimate is after the actual frameflip:

[attachment=26]day20_3.jpg[/attachment]

So - I don't know, maybe I missing something or I do not understand it properly.


Ive got another question:
1
2
3
4
5
6
7
DWORD SafeWriteCursor = WriteCursor;
if (SafeWriteCursor < PlayCursor)
{
	SafeWriteCursor += SoundOutput.SecondaryBufferSize;
}
Assert(SafeWriteCursor >= PlayCursor);
SafeWriteCursor += SoundOutput.SafetyBytes;

This is the code to determine the AudioCardIsLowLatency later - is that correct?
Because I think casey wrote something like
SafeWriteCursor += (WriteCursor + SoundOutput.SafetyBytes);
(at least as far as I can remember, but that would add WriteCursor again (but it was initialised with WriteCursor), which should not be the case..)

I don't think that's a reason for the bug, but I just wanted to confirm.

[edit]:
I hope its ok to post code snippets?

Edited by Dominik on
There seems to be lot of audio problems. I also had them, but solved them my own way. Not necessarily the right way, but worked for me. My notes on the subject are here, maybe helpful for someone:

https://forums.handmadehero.org/i...um?view=topic&catid=4&id=137#2134
@ZenSoturi:
Thank you for pointing me there. :)

So I changed things, so it doens't sleep anymore and is just checking in a loop if the time for the next frame is there yet.

This seems to improve audio alot. o_O
On the laptop, its quite ok now and on my desktop the sound is scratching far less. (But both are still scratching.. :/)