Incorrect averager updates at start

[pavhofman]

If target_level is larger than chunk, then playback will initially sleep for several chunk times (corresponding to the target_level time). Meanwhile the chunks queue up between Processing and Playback. When playback wakes up, it will correctly write several of the queued chunks to the device buffer without sleeping in between, because there is enough avail. However, every write the averager gets updated with the momentary delays which are not relevant at that moment yet. As a result the initial values in the averager distort the average, IMO. Here is a relevant trace log, grepped for the trace message:

2025-01-16 12:48:52.488090 TRACE [src/countertimer.rs:153] Averager: added value 2048, nb. 1
2025-01-16 12:48:52.488458 TRACE [src/countertimer.rs:153] Averager: added value 4096, nb. 2
2025-01-16 12:48:52.489908 TRACE [src/countertimer.rs:153] Averager: added value 6144, nb. 3
2025-01-16 12:48:52.529865 TRACE [src/countertimer.rs:153] Averager: added value 6144, nb. 4
2025-01-16 12:48:52.571786 TRACE [src/countertimer.rs:153] Averager: added value 6144, nb. 5

Perhaps values should start being added to the averager after the incoming queue is empty, i.e. after the initial "flood" of chunks is written somehow? Thanks for considering.

[HEnquist]

I plan to add the frames of any waiting chunk to the buffer level calculation. That should take care of this. And it should also help when using a target_level close to the buffer size.

[pavhofman]

Thanks, that sounds like a good way. Just IMO only the chunks which will fit into the buffer in the sequence of writes before the soundcard goes to sleep should be counted, because those will be part of the buffer fill after that sequence.

[HEnquist]

The case when the playback device goes to sleep isn't very well handled now, and won't really be improved by the changes I have in mind here. It would need some logic of it's own, to drop the old chunks in the queue when waking up.

[HEnquist]

See #391