We have encountered an issue with the Aircheck Recorder in mAirlist v8.0.8
When the playout software is running multiple days there is an increasing delay between the audio capture in the Aircheck recorder and the actual device input. This delay gets worse over time (multiple seconds).
We notice the same issue across 2 studios, which use a different soundcard (Dante Virtual Soundcard in one studio, a regular USB ASIO driver in the other). Both studios use ASIO.
We automatically start/stop the Aircheck recorder when a microphone is active/inactive.
So is only start/stop delayed (and the audio is preserved, so that in effect the timestamp is wrong) or does it actually cut the audio at one end (in this case, which one)?
The start/stop is not delayed (it instantly starts & stops recording).
It’s the actual audio that is delayed. Talking into the microphone takes 2-3 seconds before it’s actually visible in the VU meter/recording file.
A restart of mAirlist fixed the issue, but that isn’t a solution for the problem (our studios are permanently online and I don’t want to reboot them daily to solve the issue).
I did more testing in our other studio and found out the encoder audio is also delayed around the same amount of time (clearly visible in the VU meters).
If the delay builds up over time, there must either small gaps/dropouts in the recordings, or a timestretch (noticable by a slight difference in pitch).
Dropouts are more likely in my experience.
Have you tried to increase the buffer size? Aircheck and streaming doesn’t require such a super-low latency (and thus, buffer size), so you can easily use a high value such as 2048 samples.
I tried bumping the ASIO sample rate to the value you recommended (it was at 512) but the effect is still there. We didn’t notice any dropouts. Audio, both from the encoder as the aircheck recorder, was perfect without any crackle or dropouts. CPU usage is also only around 10-15%.
We had been running our previous playout software in both studios on these settings and we didn’t encounter this issue.
Weird thing is that it appears to be only the output (encoder / aircheck recorder). The audio inputs, which use the same DVS or USB ASIO device don’t have this issue.
This introduces 2 problems for us:
We automatically start/stop the Aircheck recorder from a script when a microphone is enabled/disabled. Because there is latency over time, the end of the recording is cut off. (We can’t use “Sleep”, because that blocks the entire script)
Changeovers between studios and our main playout system (we use the Stream Monitor) are unpredictable, because the delay can vary over time.
I remember we had something similar in previous versions. Where even the peakmeter gets delayed a lot, so you can see this visually.
To me that seems to be some kind of clock drifting or buffer stacking up?
So I’m curious could that happen if there is a playback Soundcard configured in the encoder?
However on our virtual Server (Win11) on mairlist version 6.3. that does not have any hardware clock reference available nor does it have playback configured on the encoder, I have never seen such problems. Except the latency that is clearly caused by Anydesk.
If the recorded audio file has a duration of 1 hour, but appears to have less than one hour of content (so last few (milli-)seconds end up in the next file, building up the delay), there must be dropouts somewhere. Maybe just small and almost unnoticable - MP3 tends to interpolate them.
@MaartenVN Can you try to adjust this setting here, e.g. set it to 100ms? And then restart?
It will increase the internal buffer, making it less likely that small dropouts are produced if the sound card can’t keep up with the processing pace.
I have been checking multiple buffer sizes and pre-buffer lengths over the last couple of days, but none of them have made any impact towards this issue.
I double checked the sample rates as well: both the encoder, ASIO driver & mAirlist ASIO settings are configured at 48kHz.
It’s really weird, because no dropouts on the encoder or the aircheck are noticeable at all.
It appears to describe similar increasing latency on the encoder, but using WASAPI instead of ASIO, so the same problem appears to occur for different audio driver technologies.
Also the same visual increasing latency in the peak meters of the encoder (and in my case also the Aircheck recorder), as described by this comment:
