The snapshot didn’t solve the problem. After a while (60 minutes or so) the problem reoccured.
I now switched to WASAPI and for the moment no problems. I’ll keep you informed Torben.
(Thanks for the great support btw, really appreciated)
Edit:
Unfortunately the problem occured again after 40 minutes or so. I don’t notice any dropouts or stuttering in the audio playback however.
Switching back to 4.3.9 did solve the problem permanently this weekend, something must have changed somewhere in between these 2 versions I would guess.
I did sent you a bugreport again with WASAPI instead of DirectSound.
I have just upgraded from 4.3.9 to 4.3.10, i have noticed that the synchronization is still slow the software is running at a high cpu still around 50% and now the hour restriction is running slowly when trying to change which hours a track can play on.
I spent the evening investigating and debugging this issue, and I’m still a bit puzzled. Actually, I think we’re talking about two different things here:
Problem #1: Encoder audio output can have extra latency due to the “encoder master clock” and the “output soundcard clock” drifting apart. I have been able to reproduce that, it doesn’t happen all the time but in roughly 50% of the cases. But also in v4.3.9! In other words, I don’t think the changes to the encoder in v4.3.10 made these problems any worse, but not better either. That issue must have been in there ever since we introduced the “exclude microphone from local playback” option. Anyway, I have applied another fix which is in the latest snapshot, b1898. Give it a try.
Problem #2: High CPU load. I have absolutely no idea where this is coming from, and I have never experienced it myself. I suspect that a background thread is going wild.
Lukeman, perhaps the delay you’re experiencing is rather a consequence of problem #2, not problem #1?
To investigate problem #2, can you please do the following:
Run the mAirList main application (not the standalone mAirListDB app), open the DB window from the toolbar, and wait for the CPU to go up.
Run Process Explorer, locate the mAirList.exe process, and double-click it.
The Properties window for the process will pop up - go to the Threads tab. On that tab, you see the list of threads (think of them as “sub-processes”), and their current CPU utilization - see attached screenshot.
Check which thread is consuming the CPU, and note its Thread ID (TID).
Go to the mAirList main window, and send a bug report from the About menu (click the arrow next to the “mAirList” button in the toolbar). Write the TID down in the comments (“In which situation did the error occur?”)
The bug report will contain a list of all active threads, along with their IDs and their call stacks (what they are doing right now). I can look up the thread with the TID you reported and see what it’s doing.
Very important: The thread IDs change everytime you close and re-open mAirList, so make sure to send the bug report immediately after you looked up the TID.
Please find enclosed a screenshot with the requested information. The moment the DB-window is opened one of the threads goes from 7% to 47% of CPU usage.
This is done with version 4.3.9 however, for some reason I can’t download the new snapshot tonight. I will give it another try tomorrow.
I also submitted a bugreport straight away as asked.
Hope this helps Torben. I’m sorry I disrupted your evening off yesterday
Edit: The setup files for the latest snapshot seem to be corrupted. Could you have a look at this?
Never mind about the evening I spent, that’s what you get for turning your hobby into your job.
Thanks for your detailed report. It’s the main GUI thread that is going wild. I suspect it’s related to a change I made in October (between 4.3.7 and 4.3.8), something about the Save button in the playlist editor toolbar, and the “Playlist has changed…” confirmation dialog.
I have just uploaded another snapshot, build 1901. Does that one fix the problem?
Just installed 1901 on the PC at work (which is more powerful than at home) and according to Process Explorer the CPU usage is at around 3%. No matter if the DB is open or not. Synchronizing is very fast again!
Looks like this solved the problem Torben! I’ll install the snapshot at home tonight and will keep you informed. ;D
Problem solved Torben!
1901 has been running for over a day now, synchronizing is still fast, no problems with the encoder or with audio and visuals out of sync. CPU usage stays low.
Thanks again!
