Hi, thanks for testing!
What is the DLL-timefilter?
This is a delay-locked-loop (DLL) which estimates the *real* samplerate based on the system time (which is different from the nominal samplerate of the audio device). This allows us to dynamically resample audio coming from another machine, so you can stream over long time periods and still stay in sync. We currently have an installation running for 6 weeks non-stop.
Why resending of lost packages doesn't work?
I think this is just a spurious error message coming from the fact that on Windows, UDP packets can arrive out of order *even on localhost* if they are sent in fast succession. Packet reordering is actually handled in the library, so this is not a problem. Unless you *hear* the dropped packet, everything's fine. I think the error should already be gone in the latest develop version:
Win32: https://git.iem.at/cm/aoo/-/jobs/11496/artifacts/download
Win64: https://git.iem.at/cm/aoo/-/jobs/11497/artifacts/download
If you still have problems, please create an issue on https://git.iem.at/cm/aoo/-/issues.
Christof
On 18.04.2020 17:21, lacuna_@gmx.net wrote:
Hi
Thank you for such a great tool!
Here: v2.0-pre1 from Deken, Windows 10, tested the help-files on the same machine.
Send and receive -helppatches within the same instance of PD, one stream only:
Added an array with the statistics of [sel block_lost] and [sel block_resent].
block_lost from time to time within in a while, with an avarage around ~+- 1 second. No block_resent prints at all (neither if I activate this manually)!
Realtime-Priority of wish86.exe and pd.exe is set in the Windows-taskmanager. It seems, that working or not on the machine, changes the number of times lost blocks accrue a little. Moving a PD window around, resizing it ect. but this doesn't always happen. Less lost packages when leaving the machine alone, but still some.
Seems to be independent of )bufsize] settings, tried 2 to 200 ms. Seems to be independent of wifi turned on or off.
Send and receive -helppatch separated by two instances of PD, on the same machine, one stream only:
block_lost around every 200 ms, with bufsize >10, tested until bufsize 5000. With bufsize small as 4 ms, much more lost blocks. Never any block_resent print out.
Both instances with real-time priority.
Never touched other settings, such as timefilter or packetsize, as I am not sure how to match such parameters?
Didn't try -nogui flag yet. Didn't try on Linux yet.
What is the DLL-timefilter? Why resending of lost packages doesn't work?
Regards *