[PD] PdDroidParty latency, syncing etc.

[Gavin]

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 at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20141211/c0affeb7/attachment.html>