All audio packets are late on 32-bit CPUs

[SebastiaanGeus]

I've Tried to compile this project for an old Asus Tinkerboard,
all seems well but i cant seem to transmit actual audio.

i've tiried both PTPv1 and PTPv2 and with both i get a clock so i would say statime is working.

i am using the Alsa implementation, and when i run aplay -D inferno_out -f S32_LE -r 48000 -c 2 /home/dante/test.raw -V stereo
it starts playing and i can see the ALSA VU meters moving.

In dante controller i can link my inferno output to a Genelec dante speaker, and the link is established.
However no sound is audible from the speaker.

in dante controller i see all packets are late...

[DrEVILish]

What did you set the latency setting in Infero?
Seems strange that peak of exactly 2 seconds and average of exactly 2 seconds. Meaning they are arriving in a predictable and stable timeframe. Doesn't seem to be a misconfigured network.

[SebastiaanGeus]

I set the latency to 10ms i've tried to go higher and lower but no difference.
If i go to low i get drop errors in the terminal playing audio. If i stay above 5ms there are no errors. So i guess that should be fine.
I've compiled the project on an intel nuc with no problems. But it would be cool to see if I can get it working on this old tinker board. V1
I suspect it has something to do with the rust crate of usrvclock and compiling that for armv7 32bit.
When compiling it gave an error initially, but I found a patch: https://gitlab.com/lumifaza/usrvclock-rs/-/blob/main/src/lib.rs?ref_type=heads
using this version it compiles. But I guess something breaks.

I also tried both PTPv1 and V2 and both get a clock, but the packets are always late.

Could it be that running on 32 bit mangles the timestamps in some way?

[teodly]

Could it be that running on 32 bit mangles the timestamps in some way?

Good catch! That's what I forgot to include in the automated test.

Probably somewhere usize or isize is used where u64 or i64 should be. We need to trace timestamp's way to the packet_ts variable here:

inferno/inferno_aoip/src/device_server/flows_tx.rs

Line 141 in c4d675b

let packet_ts = flow.next_ts.wrapping_add_signed(self.clock_offset_samples) /* .wrapping_sub(flow.fpp) */; // ???

BTW DC lies about 2000ms latency, actually it is larger (may be years), but 2000 seems to be hardcoded maximum in DC.

[teodly]

Added 32-bit container to the automated test, changed clock in some places to 64-bit. Should work, please retest on 32-bit CPU.