Quote:
Originally Posted by DTL
"Also disabled on x86 (no x86 DLL)."
New fixed build now have also x86_32 .dll - https://forum.doom9.org/showthread.p...04#post1987704 . Also the errors in conversion to RGB are now decreased. So the fastest AVX2 engine with 16bit immediate processing now produce residual errors close to natural quantization noise of 8bit samples of YUV. |
Thanks! will use it in the next version.
Am curious, have not tried it yet. Will report back.
Quote:
Originally Posted by FranceBB
it makes no sense... 
Any other ideas? |
Playback and scrubbing pass the audio data to different routines.
The whole thing runs through PortAudio via a Python wrapper.
There are two ways to write the data, writing is correct, because it is written to the output stream.
Scrubbing uses the direct write to stream method, I put the whole thing in a thread so that the video frame fetch is not blocked.
The direct writing requires more effort, but for me it was easier to implement the code and test the audio in the beginning.
In the playback a callback function from PortAudio or the wrapper is used. PortAudio fetches the provided audio data itself in this routine.
The advantage: I only have to care about reading the audio data and providing it. This also brings speed advantages in the playback, I don't really trust the Python threads, they mostly behave differently than one is used to from other programming languages.
But apparently there are problems with 32bit in this callback routine.
Here I have a version that uses your own thread for audio playback. I am full of hope.
Not tested much but runs under x64.
https://drive.google.com/drive/folde...usp=drive_link
And I also have something to say about the slower fps (Emulgator):
I had changed that in the last version, don't know if that helped with Emulgator's fps, FranceBB apparently had no problems with it.
Anyway, I have undone the changes. The reason is my stupidity (forgetfulness?), at that time I had sat for days on the playback thread until it ran satisfactorily.
The problem is the timing:
Windows has an accuracy of about 10-20 ms, but this is not enough, so the system timer is increased for the duration of the playback. If the used OS and hardware can't do this to 1 ms, everything runs a bit slower.
According to Microsoft, the performance timer is available from Win 2000, so if it runs slower with XP, then XP or the hardware is to blame.
I tried a loop, which is stupid because it also increases the CPU load. Therefore I have undone this.
The displayed fps are also only average values. It is the read frames with the past time calculated, and with several hundred frames then already deviations can arise.
@FranceBB I only want to read good things
