Fix time on 32-bits platforms

[tleb]

A long is 32 bits on 32-bit platforms. Changed nanoseconds_t to long long to use 64-bit integers on 32-bit platforms. Tested on a armv7l with CONFIG_SND_ALOOP enabled in the kernel and:

$ signal-estimator -m latency -o hw:0,1,0 -i hw:0,0,0
opening alsa writer for device hw:0,1,0
suggested_latency: 8000 us
suggested_buffer_size: 384 samples
selected_buffer_time: 8000 us
selected_buffer_size: 384 samples
selected_period_time: 4000 us
selected_period_size: 192 samples
opening alsa reader for device hw:0,0,0
suggested_latency: 8000 us
suggested_buffer_size: 384 samples
selected_buffer_time: 8000 us
selected_buffer_size: 384 samples
selected_period_time: 4000 us
selected_period_size: 192 samples
successfully enabled real-time scheduling policy
successfully enabled real-time scheduling policy
latency:  sw+hw  53.129ms  hw  31.643ms  hw_avg5  31.643ms
latency:  sw+hw  59.833ms  hw  32.550ms  hw_avg5  32.097ms
latency:  sw+hw  59.605ms  hw  31.692ms  hw_avg5  31.962ms
latency:  sw+hw  59.847ms  hw  32.558ms  hw_avg5  32.111ms
latency:  sw+hw  59.594ms  hw  31.686ms  hw_avg5  32.026ms
latency:  sw+hw  59.831ms  hw  32.553ms  hw_avg5  32.114ms
latency:  sw+hw  59.587ms  hw  31.686ms  hw_avg5  32.053ms
latency:  sw+hw  59.837ms  hw  32.561ms  hw_avg5  32.116ms
latency:  sw+hw  59.595ms  hw  31.688ms  hw_avg5  32.069ms
latency:  sw+hw  59.819ms  hw  31.692ms  hw_avg5  32.031ms

I haven't tested this change extensively, and it might break some things. I haven't tested the GUI side on a 32-bit platform. I can run stuff on a 32-bit platform to do some testing if you are curious; both latency and losses modes run without issue.

I just sent a patch to Buildroot to provide this software as a package, with the same patch applied.

Thank you for this tool!

[gavv]

LGTM, thanks!

No idea why it was long, I'm actually copy-pasting this header from project to project and everywhere else it's int64_t :)