I've got this working now!

In the version I had there is a small bug/typo which prevents the sliders and toggles from updating.

In the netbus.pd file there is an abstraction on the send side, pd oscformat
Inside it there is a message box 'set /syncjams$1'
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.

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.
But luckily I worked out what I needed to get syncjams to work.

The latency on my device, a Moto G, seems to be around 100ms. 
The ping time from my laptop to my phone is 3ms so I guess I can pretty much discount that!



On Thu, Dec 11, 2014 at 11:32 AM, Gavin <info@digitalfunfair.co.uk> wrote:
Thanks for your comprehensive reply.
Hopefully this conversation should now be on list.

Syncjams looks very interesting I will try it out today! 
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?

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? 

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! 

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!

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!




On Thu, Dec 11, 2014 at 2:08 AM, Chris McCormick <chris@mccormick.cx> wrote:
Hi Gavin!

On 09/12/14 19:27, Gavin wrote:
> Is it ok to email you about this or would you prefer to keep it to the
> forums?

I hope you don't mind me CC'ing this to the Pd-list.

I'm happy you emailed about this because it is exactly what I have been
working on lately when I find spare time.

> I'm a bit confused as to the network options with pddroidparty.
> There is netro which seems to be based on netsend and x-netreceive but
> also droidnetreceive and also netreceive!
> Which is the recommended or latest one?

The native netsend and netreceive now work in the version of Pd that
ships with PdDroidParty. The other libraries are deprecated. Sorry for
the confusion - there was a long standing bug with netreceive not
working in libpd that is now resolved. x-netreceive was just my way of
commenting out netreceive - you can change it back to netreceive and
remove the top level droidnetreceive hack object and netro should just
work again.

Netro is an abstraction for doing timing synchronisation of Pd patches
that runs on top of netreceive. I haven't updated it for a long time
because I've been working on something that does the job better:

http://github.com/chr15m/SyncJams/

SyncJams uses OSC underneath and so it can interoperate more widely with
other software. There is also a Python implementation and I am hoping
for implementations in other languages (especially Supercollider) down
the track. Patches welcome!

SyncJams provides a way to not only sync metronomes during live
performance but also a sort of distributed hash table ("set-state")
where everybody involved in a jam can share state information like
controller position, song key, etc. There is also a generic conduit for
in-time events ("message") to be propagated in order such as drum beat
hits from a live drummer.

I've been testing on Android, and latency aside things are working
pretty smoothly now.

> Also is there anyway to debug/print to a console on a phone?

If you use Pd's print object you can then use `adb logcat` to see what
comes out - you'll need to have your phone in debugging mode and
connected via USB or over TCP to adb.

> I'm hoping to guesstimate latency by calculating the time it takes to
> send data from one device to another and back and sync phasors on
> separate devices.
>
> Have you tried this?

So latency is the exact problem I am tackling at the moment.

After speaking to Peter Brinkmann, the resident Android audio expert,
the outlook is as abysmal as ever. The way audio is implemented on
Android means you can't ever really know with 100% certainty how long it
takes between a software event and the speaker actually emitting the
triggered sound.

My approach, which is hopefully "good enough" is similar to what you
suggest, except that a single device can send a signal to its own
microphone to measure the round trip time. Hopefully half of the round
trip time will give the approximate output latency. This is what the
android-latency-tester patch did and I will probably use that same
method (with the bonk~ object).

<http://puredata.info/docs/AndroidLatency/>

I tested a FFT based cross correlation approach to detect the
same-device latency, but it wasn't really robust enough. That is in the
SyncJams repository if you want to take a look. Maybe I did something
wrong though as my DSP math is not very strong.

There is also Raph Levien's audio buffer size tool:

https://play.google.com/store/apps/details?id=com.levien.audiobuffersize

Which uploads its results for different devices:
http://audiobuffersize.appspot.com/

Code:
https://code.google.com/p/high-performance-audio/source/browse/audio-buffer-size/src/com/levien/audiobuffersize/AudioBufferSize.java

In the end I think the approach on Android is going to be:

 * Alert the user the first time they run the patch that latency needs
to be tested.
 * "Please turn up your speakers while we run the test."
 * Collect the timing data using bonk~ or FFT cross correlation or
whatever and write it to disk.
 * Everybody who makes an Android Pd app can use the same filename,
location, and format for the data (/sdcard/Pd/latency-test.txt) so
hopefully it only has to be done once.
 * Use the values in that file to compensate for latency.
 * Provide a menu option for the user to re-run the compensation if they
feel latency is getting out of hand.

> PS One more thing - where can I get x-netreceive so I can install it on
> my laptop. Is it the same as xnetreceive?

x-netreceive is not a real object - it's what I used to comment out the
existing netreceive object in netro when that wasn't working under
PdDroidParty. What you can do is replace it with netreceive instead, and
remove droidnetreceive entirely. Things should work after that.

Let us know how you go!

Cheers,

Chris.

--
http://mccormick.cx/




--


--
Gavin
www.digitalfunfair.co.uk