On 04/04/2020 15:02, Christof wrote:
>
>
> I'm currently working on a UDP punch hole server, so that people can
> easily create peer-to-peer-networks over the internet und jam together
> :-)
Not in any way to minimize how cool this would be to have built in to Pd, but are you familiar with Ross Bencina's OSCGroups?
http://www.rossbencina.com/code/oscgroups
We've been using it for 15 years for just this purpose; it links up a whole group of people with hole-punched OSC-over-UDP.
Phil Stone Davis, CA
Hey, thanks a lot for the link! Will check it out and see how it fits our requirements.
Christof
On 04.04.2020 23:21, Philip Stone via Pd-list wrote:
On 04/04/2020 15:02, Christof wrote: > > > I'm currently working on a UDP punch hole server, so that people can > easily create peer-to-peer-networks over the internet und jam together > :-)
Not in any way to minimize how cool this would be to have built in to Pd, but are you familiar with Ross Bencina's OSCGroups?
http://www.rossbencina.com/code/oscgroups
We've been using it for 15 years for just this purpose; it links up a whole group of people with hole-punched OSC-over-UDP.
Phil Stone Davis, CA
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
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 *
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 *
We currently have an installation running for 6 weeks non-stop.
This is Linux only, isn't it?
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
I do hear the dropped packets. The block_reordered report doesn't occur neither.
Tried with windows defender firewall turned off, - still the same.
To be more precise: Not one stream only, it is the stereo example i.e. one stream with two channels.
After further testing I found: The described happens with PD's block-size @ 64 latency 80ms and 160ms the same. When increasing the block size to 128 samples, drop-outs occur much more frequent, even with 160 ms latency. Everything @ 44100 and changed in PD's audio-preferences, not re[block~]ing. All those drop-outs are related to the network stream on localhost, not to the audio, even though I do hear the stream's lost packages.
Win64: https://git.iem.at/cm/aoo/-/jobs/11497/artifacts/download%5Bhttps://git.iem....]
Guess, I have to compile it?
If you still have problems, please create an issue on
https://git.iem.at/cm/aoo/-/issues%5Bhttps://git.iem.at/cm/aoo/-/issues].
Will do, as soon I have tested the latest version.
Thanks for reporting back! This is definitely interesting, as I mainly test on Windows and Linux, even across machines and over the public internet...
Guess, I have to compile it?
Why not just open the link and see? Spoiler: no, it's binaries.
Let's continue on the issue tracker! I'm happy to figure out what's going on.
Christof
On 18.04.2020 21:41, Manuel Haible wrote:
We currently have an installation running for 6 weeks non-stop.
This is Linux only, isn't it?
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
I do hear the dropped packets. The block_reordered report doesn't occur neither.
Tried with windows defender firewall turned off, - still the same.
To be more precise: Not one stream only, it is the stereo example i.e. one stream with two channels.
After further testing I found: The described happens with PD's block-size @ 64 latency 80ms and 160ms the same. When increasing the block size to 128 samples, drop-outs occur much more frequent, even with 160 ms latency. Everything @ 44100 and changed in PD's audio-preferences, not re[block~]ing. All those drop-outs are related to the network stream on localhost, not to the audio, even though I do hear the stream's lost packages.
Win64: https://git.iem.at/cm/aoo/-/jobs/11497/artifacts/download%5Bhttps://git.iem....]
Guess, I have to compile it?
If you still have problems, please create an issue on
https://git.iem.at/cm/aoo/-/issues%5Bhttps://git.iem.at/cm/aoo/-/issues].
Will do, as soon I have tested the latest version.