Add event timestamping

[strohel]

Follow-up to #11 (comment)

I got and idea for an empirical test to see how important would proper event timestamping be: extend #12 just a little to produce the click event at a steady and very high rate (e.g. 250 Hz, once every 4 ms), and then run it over long network like Tokyo -> Prague.

This may even turn out to be useful "hear the network jitter" probe on its own (which would depend on absence of timestamping as a twist).

[skywhale]

This is a great idea! I'm very curious, too :)

[strohel]

Not sure where to report this, so I'll abuse this issue.

When playing with tick_probe from #30 (which produces events at given frequency) today with @goodhoko and @bschwind, the heard "frequency" increases between tick_probe 30 and tick_probe 40, but beyond 40~80 the heard "frequency" doesn't really increase - tick_probe 400 sounds louder than tick_probe 200, but that's it. This is happening both with main and the jukebox #25 branch.

We know from Jen's research that simply overlaying the same sample can produce arbitrarily high-pitched sounds.

This problem basically reduces our time resolution to one buffer length (e.g. 25 ms), which is I think too low for good fidelity.

After musing about that a bit my theory is that this is caused by the fact the audio libraries work with buffers of samples. So when we call output_stream.play_raw(sample), the library cannot actually start playing right now - it can only start playing from the next buffer it submits. So all events that happen to arrive between the same buffer submissions play 100% aligned (and not shifted by a couple of samples as one would expect).

One way to circumvent this with rodio would be to save "inter-buffer delay" for each received event and then use https://docs.rs/rodio/latest/rodio/source/trait.Source.html#method.delay to shift playback of each sample appropriately. That circles us back to adding timestamps to events.

But I ran into problems setting or querying the buffer size/length with rodio [1], but maybe @bschwind you got more confident in the meantime that we could switch to fundsp instead, which may handle this better?

[1] I think that rodio exposes cpals API in suboptimal way: https://docs.rs/rodio/latest/rodio/struct.OutputStream.html#method.try_from_device_config accepts https://docs.rs/cpal/latest/cpal/struct.SupportedStreamConfig.html - but that is a range of possible values, and I think it should accept https://docs.rs/cpal/latest/cpal/struct.StreamConfig.html (which can specify particular buffer size) instead.

[strohel]

Hmm, there was a string to resolve https://github.com/tonarino/acoustic_profiler/issues/19#issuecomment-1522348735 in #36, but GitHub interpreted this as resolving the whole issue.

On the contrary, we've seen (heard) that network (Tokyo -> Prague) indeed introduces audible jitter (https://tonari-no.slack.com/archives/C051C9VPXKJ/p1682678798638329 - albeit only with high frequencies like 1000 Hz), so timestamping does make a difference.