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 logcatto 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-...
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.
-- Gavin www.digitalfunfair.co.uk