Fix unsigned underflow in AudioEntry.audioDataLengthBytes()

[romansorochak]

Problem

AudioEntry.audioDataLengthBytes() subtracts the parsed data offset from the source length as UInt:

func audioDataLengthBytes() -> UInt {
    if let byteCount = audioStreamState.dataByteCount {
        return UInt(byteCount)
    }
    guard source.length > 0 else { return 0 }
    return UInt(source.length) - UInt(audioStreamState.dataOffset)
}

When dataOffset > source.length, the subtraction underflows and Swift traps (SIGTRAP). This happens on live streams whose reported length is smaller than the header offset the file-stream parser found. duration() reaches it through calculatedBitrate(), which becomes non-zero as soon as packets have been processed, so the crash hits during normal playback, not at the edges.

For context: in a radio app built on AudioStreaming, AudioEntry.duration() → audioDataLengthBytes() was the top fatal crash on iOS, 45 installs in a month across four app versions.

Fix

Compare before subtracting, and return 0 when dataOffset >= length. duration() already returns 0 for a stream of unknown length, so callers see the same value they get for any live stream. The explicit dataByteCount path is unchanged.

Tests

AudioEntryTests, a new file with five tests that use a fixed-length CoreAudioStreamSource stub:

• dataOffset > length → 0. Against the current main this test does not fail, it takes the test runner down: xctest … exited with unexpected signal code 5.
• dataOffset == length → 0.
• the normal case, length - dataOffset.
• an explicit dataByteCount still wins.
• duration() is 0 when the offset exceeds the length, with a bitrate set.

With the fix, the full suite passes: swift test → Executed 59 tests, with 0 failures.

Notes

The PR also carries one small, separate test-only commit. The first CI run failed in DispatchTimerSourceTests.test_HandlerIsExecuted_On_The_Specified_Queue, which this change does not touch: API violation - multiple calls made to -[XCTestExpectation fulfill]. The timer repeats every 100 ms, and on a slow runner with --parallel it can fire again before wait returns. The test now sets assertForOverFulfill = false. Happy to drop that commit if you prefer it separately.

The change is confined to AudioEntry.audioDataLengthBytes(); there are no public API changes. Our next app release, now in App Review, carries this fix from our fork. Thanks for merging #138 and releasing it in 1.4.5 — this is the last patch we carry on top of upstream.

[dimitris-c]

Thank you for this fix, looks good