Audio events are bursty

[argilo]

Currently, audio events are reported as soon as audio packets are decoded. In the P1 channel, decoding happens one frame at a time, and frames are 1.486 seconds long. This places a heavy burden for buffering on the user of the API.

An alternative would be to have libnrsc5 take on some of the responsibility for buffering. It could store the decoded audio packets and report them gradually as new IQ samples arrive. In fact, this would be necessary if we ever wanted to implement analog blending (#80). The audio PDU header has latency and sequence number fields indicating exactly when audio frames should be played back in relation to the incoming signal.

[awesie]

When I did some experimenting with this awhile ago (012c124), I used a cross correlation to align the analog and digital audio, which worked decently iirc. Something to consider if aligning everything accurately (e.g. after demod and filtering) proves difficult.

[pclov3r]

I know this is an old proposal but I noticed when playing some I/Q files that have fading or bad multipath present decoding can sometimes be not the best and there will be skipping and or pops. Perhaps this issue is more in line with #68 If the signal is strong this is not present.

@argilo curious about your thoughts here.