<div dir="ltr">I've got this working now!<div><br><div>In the version I had there is a small bug/typo which prevents the sliders and toggles from updating.</div><div><br></div><div>In the netbus.pd file there is an abstraction on the send side, pd oscformat</div><div>Inside it there is a message box 'set /syncjams$1'</div></div><div>I think this needs to read 'set /syncjams/$1' or the route object on the receive side doesn't do what it is supposed too.</div><div><br></div><div>Annoyingly I haven't managed to get adb access to my device yet - it is reported as offline and I lost the will to live trying to find out why.</div><div>But luckily I worked out what I needed to get syncjams to work.</div><div><br></div><div>The latency on my device, a Moto G, seems to be around 100ms. </div><div>The ping time from my laptop to my phone is 3ms so I guess I can pretty much discount that!</div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Dec 11, 2014 at 11:32 AM, Gavin <span dir="ltr"><<a href="mailto:info@digitalfunfair.co.uk" target="_blank">info@digitalfunfair.co.uk</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Thanks for your comprehensive reply.<div>Hopefully this conversation should now be on list.</div><div><br></div><div>Syncjams looks very interesting I will try it out today! </div><div>I opened it on my laptop and it seems I need the netsync object. I have found the repository on github - do I need to grab this?</div><div><br></div><div>Or is netsync bundled with pddroidparty? Which is the latest version? - is downloading 276 from the website sufficient or so I need to download it from github and compile it or something? </div><div><br></div><div>I'm finding it a bit difficult to know if the objects are missing on my phone. Bit of a noob at this. It's like blind coding! </div><div><br></div><div>I realised that Android has severe audio latency issues but I thought these were largely when using audio in. I thought my latency was largely created by the network but now I am questioning this. In any case yes your audio approach seems like a fair solution. Hopefully lollipop will improve this and in about 5 years it will be universally adopted!</div><div><br></div><div>Right I'll try and get syncjams to work - I'm currently using 1 phone and 1 laptop - if for some reason this will never work and I need to use 2 devices, please someone put me out of my misery!</div><div><br></div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Dec 11, 2014 at 2:08 AM, Chris McCormick <span dir="ltr"><<a href="mailto:chris@mccormick.cx" target="_blank">chris@mccormick.cx</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Gavin!<br>
<br>
On 09/12/14 19:27, Gavin wrote:<br>
> Is it ok to email you about this or would you prefer to keep it to the<br>
> forums?<br>
<br>
I hope you don't mind me CC'ing this to the Pd-list.<br>
<br>
I'm happy you emailed about this because it is exactly what I have been<br>
working on lately when I find spare time.<br>
<br>
> I'm a bit confused as to the network options with pddroidparty.<br>
> There is netro which seems to be based on netsend and x-netreceive but<br>
> also droidnetreceive and also netreceive!<br>
> Which is the recommended or latest one?<br>
<br>
The native netsend and netreceive now work in the version of Pd that<br>
ships with PdDroidParty. The other libraries are deprecated. Sorry for<br>
the confusion - there was a long standing bug with netreceive not<br>
working in libpd that is now resolved. x-netreceive was just my way of<br>
commenting out netreceive - you can change it back to netreceive and<br>
remove the top level droidnetreceive hack object and netro should just<br>
work again.<br>
<br>
Netro is an abstraction for doing timing synchronisation of Pd patches<br>
that runs on top of netreceive. I haven't updated it for a long time<br>
because I've been working on something that does the job better:<br>
<br>
<a href="http://github.com/chr15m/SyncJams/" target="_blank">http://github.com/chr15m/SyncJams/</a><br>
<br>
SyncJams uses OSC underneath and so it can interoperate more widely with<br>
other software. There is also a Python implementation and I am hoping<br>
for implementations in other languages (especially Supercollider) down<br>
the track. Patches welcome!<br>
<br>
SyncJams provides a way to not only sync metronomes during live<br>
performance but also a sort of distributed hash table ("set-state")<br>
where everybody involved in a jam can share state information like<br>
controller position, song key, etc. There is also a generic conduit for<br>
in-time events ("message") to be propagated in order such as drum beat<br>
hits from a live drummer.<br>
<br>
I've been testing on Android, and latency aside things are working<br>
pretty smoothly now.<br>
<br>
> Also is there anyway to debug/print to a console on a phone?<br>
<br>
If you use Pd's print object you can then use `adb logcat` to see what<br>
comes out - you'll need to have your phone in debugging mode and<br>
connected via USB or over TCP to adb.<br>
<br>
> I'm hoping to guesstimate latency by calculating the time it takes to<br>
> send data from one device to another and back and sync phasors on<br>
> separate devices.<br>
><br>
> Have you tried this?<br>
<br>
So latency is the exact problem I am tackling at the moment.<br>
<br>
After speaking to Peter Brinkmann, the resident Android audio expert,<br>
the outlook is as abysmal as ever. The way audio is implemented on<br>
Android means you can't ever really know with 100% certainty how long it<br>
takes between a software event and the speaker actually emitting the<br>
triggered sound.<br>
<br>
My approach, which is hopefully "good enough" is similar to what you<br>
suggest, except that a single device can send a signal to its own<br>
microphone to measure the round trip time. Hopefully half of the round<br>
trip time will give the approximate output latency. This is what the<br>
android-latency-tester patch did and I will probably use that same<br>
method (with the bonk~ object).<br>
<br>
<<a href="http://puredata.info/docs/AndroidLatency/" target="_blank">http://puredata.info/docs/AndroidLatency/</a>><br>
<br>
I tested a FFT based cross correlation approach to detect the<br>
same-device latency, but it wasn't really robust enough. That is in the<br>
SyncJams repository if you want to take a look. Maybe I did something<br>
wrong though as my DSP math is not very strong.<br>
<br>
There is also Raph Levien's audio buffer size tool:<br>
<br>
<a href="https://play.google.com/store/apps/details?id=com.levien.audiobuffersize" target="_blank">https://play.google.com/store/apps/details?id=com.levien.audiobuffersize</a><br>
<br>
Which uploads its results for different devices:<br>
<a href="http://audiobuffersize.appspot.com/" target="_blank">http://audiobuffersize.appspot.com/</a><br>
<br>
Code:<br>
<a href="https://code.google.com/p/high-performance-audio/source/browse/audio-buffer-size/src/com/levien/audiobuffersize/AudioBufferSize.java" target="_blank">https://code.google.com/p/high-performance-audio/source/browse/audio-buffer-size/src/com/levien/audiobuffersize/AudioBufferSize.java</a><br>
<br>
In the end I think the approach on Android is going to be:<br>
<br>
 * Alert the user the first time they run the patch that latency needs<br>
to be tested.<br>
 * "Please turn up your speakers while we run the test."<br>
 * Collect the timing data using bonk~ or FFT cross correlation or<br>
whatever and write it to disk.<br>
 * Everybody who makes an Android Pd app can use the same filename,<br>
location, and format for the data (/sdcard/Pd/latency-test.txt) so<br>
hopefully it only has to be done once.<br>
 * Use the values in that file to compensate for latency.<br>
 * Provide a menu option for the user to re-run the compensation if they<br>
feel latency is getting out of hand.<br>
<br>
> PS One more thing - where can I get x-netreceive so I can install it on<br>
> my laptop. Is it the same as xnetreceive?<br>
<br>
x-netreceive is not a real object - it's what I used to comment out the<br>
existing netreceive object in netro when that wasn't working under<br>
PdDroidParty. What you can do is replace it with netreceive instead, and<br>
remove droidnetreceive entirely. Things should work after that.<br>
<br>
Let us know how you go!<br>
<br>
Cheers,<br>
<br>
Chris.<span class="HOEnZb"><font color="#888888"><br>
<span><font color="#888888"><br>
--<br>
<a href="http://mccormick.cx/" target="_blank">http://mccormick.cx/</a><br>
<br>
</font></span></font></span></blockquote></div><span class="HOEnZb"><font color="#888888"><br><br clear="all"><div><br></div>-- <br><div>Gavin<br><a href="http://www.digitalfunfair.co.uk" target="_blank">www.digitalfunfair.co.uk</a><br></div>
</font></span></div>
</blockquote></div><br clear="all"><div><br></div>-- <br><div class="gmail_signature">Gavin<br><a href="http://www.digitalfunfair.co.uk">www.digitalfunfair.co.uk</a><br></div>
</div>