uze6666 wrote:Ok, I will try and apply your patch to see if it improves things. My issue is that I don't seem to be able to reproduce your line drop issue. And I don't like to apply patch on something Iccan't see. I'm starting to wonder if it has somehow to do with the OS or GCC version. Btw, Y which version to you have? Can you send me a HEX file and capture that show the problem early?
I had lowered the buffer to reduce latency, but putting it back to 1024 didn't change anything.
The change from 512 samples to 1024 samples might not change anything for you, but that can make a difference depending on a person's hardware capabilities and configuration. For instance, on my desktop I was able to go down as low as 128 samples without crackling, but not on my old laptop. Changing it to 2048 or 4096 added too much latency.
In a previous PM, I sent you the .hex and a .cap file that can reproduce it. The hex hasn't changed since, but if that input capture file takes too long, then just run the .hex file manually and skip ahead to Level 10 (the dirt-themed level that has many lines of fire that you have to jump underneath without touching) and as soon as the level starts, hold right and then press and hold the jump button, and it should jitter a whole bunch right there in the beginning. I verified this using the Windows build that you posted the day you posted it, but I did not record an input capture, because it was something I can reproduce every time. Later tonight I can send you another input capture that will do that procedure, if you're willing to wait.
I've compiled Uzem with gcc 4.7, 4.8, and 4.9 with and without optimizations (-O3, -O2, -O1, -O0) and still got the same results (missing first scanline) without that patch applied on both Windows and Linux. I did not compile it myself in Windows, I just ran the build you posted.
As far as sound issues, the other difference between the master branch and the uzem140 branch is on the master branch SDL is configured with a sample rate is 15700, and on uzem140 branch it's configured with 15734. The documentation states that if your hardware isn't capable of setting it to what you request, then it may do a conversion internally to something the hardware can handle. I suspect that this is what might be happening, because I have bumped that number up to 15734 in both my master branch and my uzem140 branch and they sound exactly the same, but when I changed it back to 15700 there is noticeably less distortion. This happens independently of the version of SDL in use, it's just an inherent limitation of the underlying audio hardware. 48000 Hz is what most sound cards run at internally, and anything else is most likely going to require a conversion of some sort.
Edit: I'm not sure if SDL1.2 handles audio from a separate thread, but I know for sure that in SDL2 the audio callback you configure it to use runs in a separate audio thread. If the ring buffer isn't thread safe (a quick glance tells me it isn't), then that could also be causing audio issues.