[CHANGES MADE] High CPU usage when streaming to an Icecast server using dsp_wc

[kobber]

Hello. I'm using wacap + ignorant output + streaming DSP plugin + icecast server on the same computer. That's work fine, but after a couple of days CPU's consumption is about 15% from 1% at the start moment.
If I started two portable wacaps to stream two different playlists, each of them eats 15%, total is a 30, and laptop started a cpu cooling fan, so noisy.
Playlist is about half-thousand mp3+flac files, shuffled.
Is there any thoughts how to log this problem and fix it?

[dro]

What wacup version & build type, Windows version & what skin are you using? Additionally is the local library being used & which streaming source are you using (wacup's or a 3rd party). Also to confirm the stream renders ok when it's showing the problem?

The obvious thing would be to see if the 24960 build from earlier today shows any improvement or not. If not then trying to get a couple of process dumps whilst it's in that odd state via task manager & then send them over to me (they compress well but might need to hosted somewhere temporarily if a few have been generated).

It might also be possible to use something like process explorer to see if it's a single thread or if multiple threads in the process are running at full speed (not that the length of time should make a massive difference unless it's maybe not keeping up or it's not able to send it to the icecast instance as fast as wanted & is having to spin).

[kobber]

Thanx for the answer. I will update to last build and take a look at its behavior

[kobber]

Hello.

1. 24960 32-bit, win10 pro x64 22h2, classic skin
2. Yes, is used playlist with local mp3 and flac-files.
3. It uses Ignorant output and dsp_wc plugin with one streaming source to icecast server
streamig is working fine without gaps, lag etc, but cpu consumption has grown in 5 days to 13%

got some screenshots

[dro]

Were you able to get any dump files from the process when in that state? As the top 2 are the most likely input & output threads the plug-in uses but without a couple of dump files it's hard to tell why they're doing what they are. Also are you keeping the preference window open throughout all of this?

[kobber]

I guess top 2 threads are streaming processes dsp_wc.dll, not input/output. I've done a dump by task manager <got_the_file_link_removed>
it's not very clean for me about preferences window, but if you need some actions and info, i'll do it

[dro]

The two threads showing the high cpu are the input & output processing threads the dsp_wc plug-in uses as I suspected from the earlier screenshots. As it uses two threads so it can take the audio from what's playing & then collates it for the stream encoders to then do their thing when they're ready for it which if not done on threads would basically mean it blocks things & that ends up causing more problems. The other thread shown relates to the ui (i.e. doing the updating of the streaming prefs page) & few other things with the stream handling

I've now had a look at the dump file (I've removed the download link to it) & I think I see what is most likely causing the problem for you with it relating to how title updates are done which over time wasn't correctly cleaning up some internal connection handling making it spin over things that have long since been removed (aka wasting cpu time). There's a change now in place for the next build which I'm hoping will improve the situation though I'm still not 100% that it is the definite reason behind the problem but will have to see from more testing.

[kobber]

thank you for investigation, if needed i could perform more tests, gather additional information or do some testing for new build

[dro]

1.99.55.25130 was uploaded a few days ago with the changes to dsp_wc that I was able to make so hopefully that'll be better behaved for you.

[kobber]

Very nice! Let's see