fix(pulseaudio,pipewire): build on targets without 64-bit atomics

[roderickvd]

PulseAudio's latency tracking stores two microsecond counters in AtomicU64, which doesn't exist in std on exotic or legacy targets without native 64-bit atomics. This PR adds fallback to portable-atomic on such targets.

PipeWire hid the same error through its last_quantum field, but we can narrow that to u32 without any problem or pulling in another dependency.

Closes #1277

[roderickvd]

@sandreas

[sandreas]

Awesome thank you, try to provide feedback tomorrow.

[sandreas]

@roderickvd

Sorry for the delay, I'm currently fighting with my toolchain, so it may take some time. I try to keep you up to date.

[sandreas]

@roderickvd
Awesome, this does the trick. Thank you very much.
I checked this branch works and re-checked, that master fails to be sure, so it definitely compiles now.

Would it be useful to add a 32bit target to the workflows ensuring that this cannot happen again?

Maybe I have a little extra to think about (not this part of the code - this is an external APIs ID known to be 32bit integer, but maybe other parts of the code storing the amount of samples):

Let's say we have an audio book with 28 hours duration and a sampling rate of 44100Hz - that would make 28×3600×44.100=4.445.280.000 samples right?
Would these still fit in a 32bit uint?

• Samples: 4.445.280.000
• Max 32bit uint: 4.294.967.295

This was a problem on old iPod Nanos (although they had used int32, so 28 hours with 22050Hz was too much, maybe we can prevent this from happening in cpal, before it appears. Just a thought ;-)