02-09-2020, 10:31 PM
(02-07-2020, 06:07 PM)andrea Wrote: Woooow thanks a lot, I'm impressed by the effort you put in this forum!
Thanks - I cannot ignore a good question
Interesting use case. Synchronizing multiple phones is always a bit tricky and many users expect that the phones are just in sync by default, which is far from true - at leat for these time scales. I often recommend knocking on a table with all phones, so the peak can be recognized in all recordings for later synchronization.
This of course would not make sense for your experiment (unless you can move the phones after giving a reference signal with the phones in the same place), so your idea make a lot of sense. Unfortunately, there are also difficulties when it comes to synchronizing event within the phone. When looking into alternatives to synchronize phones, one finds that sensor events do not have a time stamp from the realtime clock (because this can skip when it is adjusted and it has a lower resolution), but instead we get sensor events relative to the time at which the system was started. This already makes it difficult to give precise real-work timestamps and complicates synchronization even if phones have well-synchronized real-time clocks.
When it comes to audio data, the situation is even more complicated. The data from the microphone is neither a stream of values with timestamps nor are audio samples necessarily delivered to an app at the time they have been recorded. What happens is that phyphox sends the command to record audio and from then on, we get the audio data in packages of few hundred or thousand samples. There is no timestamp, but from the sample rate we can calculate exactly the time of each sample - relative to the first one. And here is the problem: The time of the first sample. The delay between the recording command to the first sample depends on the device and the delay between the actual recording of a sound to it actually reaching phyphox is typically around 10ms on Android (although newer Android systems supposedly can achieve 3ms and iOS seems to be better generally in this area). Most applications only care about the latter value as it affects the perceived delay for audio effects.
In any case, the time of an audio sample is nothing that is automatically delivered (although I think it should be possible to obtain it) and so far, phyphox did not really care about this. In phyphox you can get the timestamp for each sensor event (time since startup adjusted to the beginning of the experiment), but audio data is only a block of samples. Tools like our "acoustic stopwatch" calculate a relative time difference by counting the samples, but you do not get a starting time. The best phyphox can do here at the moment is using the time at which the current data batch started processing, which is subject to the phone's performance and which will always be worse than the buffer size used by the device.
So, it might be possible to get precise audio timing (at least a quick search showed that there are more people discussing latency for audio processing), but at least at the moment phyphox does not provide anything which will allow you to synchronize the audio to the accelerometer data.
The only things that can be directly synchronized this way (at least at the moment in phyphox) are sensor events from the sensor API (see the list here https://developer.android.com/guide/topi...s_overview). Is there any way, you could synchronize your devices through something detected by the accelerometers? Either by synchronizing them in one place and then moving them (although I have to admit that this will open the question about long-time stability of the internal clocks, which I cannot answer) or maybe by sending seismic impulses from different directions, similar to how we determine the speed of sound (actually, we do it like this because of pretty much the same problem, see here: https://phyphox.org/experiment/speed-of-sound/).