In receiver_source test recv_timestamp_mapping_remixing the failure was caused by the issue in Depacketizer. As you suggested (after my localization): here:
We should check if Depacketizer correctly handles case when first packet for frame had zero CTS, and second packet for the same frame had non-zero CTS.
I think it's not covered right now.
We need a test for this and maybe a fix.
In sender_sink tests the issue is simple: Resampler backend throw away first n samples (N==latency), which was not properly reflected in test::PacketReader
539
In
receiver_source
testrecv_timestamp_mapping_remixing
the failure was caused by the issue in Depacketizer. As you suggested (after my localization): here:In
sender_sink
tests the issue is simple: Resampler backend throw away first n samples (N==latency), which was not properly reflected intest::PacketReader