It's taking an awful lot of CPU resource.

Also, quite a lot of RAM being used.

I'm having the same issue. It will max a processor or two and consume like 4GB of memory while it is trying to determine the sample rate, and once it does, it will settle back down again.

I just found this app and was really excited. Unfortunately it doesn't do anything for me but consume resources and spin the beachball. I have to quit the app. Nothing seems to work but I did see it glitch the audio and switch one time before it started spinning again.

Thus far I have not been able to replicate this issue, though judging from the activity monitor screenshots it appears all has run it for a significant amount of time, suggesting its probably related to some kind of memory leak or endless loop.

In my short-term testing, here is what I am seeing with the debugger on:

With each CPU usage spike happening on each track playback.

Does it only happen with over 1 hr of usage?

I do get a ton of CPU usage and it locks up when trying to click the icon for me for about 10 seconds between tracks

For me it happens right after launch. I get no usage at all. This is on a MacBook Pro M1Pro (work machine). I haven't tried it yet on my MacBook Pro M3Max (personal machine). It locks up whenever I try to click the icon.

I do get a ton of CPU usage and it locks up when trying to click the icon for me for about 10 seconds between tracks

@MasterRahool so in your case, it only locks up when the selection menu/panel is open?

For me it happens right after launch. I get no usage at all.

@philip-kennedy Yikes. I am sorry for the poor user experience for you (and others with similar issues) 😢

CPU use spikes on every track change (same album, next track skip, picking another track). My whole system doesn't lock up, but selecting the menu is the only way to directly know the app is locked up since I'm interacting with it.

I normally wouldn't notice since it's just wheezing in the background.

CPU use spikes on every track change

@MasterRahool well yes thats expected behaviour as LS v1.1 starts intensively looking into logs as soon as it receives a track change