Skip to main content

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: foo_input_sacd Component (Read 1650 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

foo_input_sacd Component

Good evening.
I use foobar for a long time with much satisfaction.

I often encountered a problem with foo_input_sacd that engages the 100% CPU.

Does anyone have any news or solutions?

Re: foo_input_sacd Component

Reply #1
Decompressing DST (a lossless compression of DSD) is a CPU intensive process (it wasn't designed for general purpose processors.)

This problem can be exacerbated if you are using foo_wave_seekbar since it often will be doing the work as fast as possible to build the wave display.

Re: foo_input_sacd Component

Reply #2

Thank you for the reply.

I know that in DST we need computing power.
The problem continues even if playback is stopped.

And though I close foobar and then re-open it. CPU is still 100%.

Re: foo_input_sacd Component

Reply #3
Delete and restore the components one by one inside user-components folder, each time you delete one restart foobar2000 to see which one gives you trouble.

 

Re: foo_input_sacd Component

Reply #4

Only by removing foo_input_sacd the CPU returns very low.

Also removing foo_wave_seekbar resolves but you can not do without these two components.

Re: foo_input_sacd Component

Reply #5
Oops, if you can't live without both of those components, looks like you're destined to have a bad time. Unless maybe you:

1) Remove DST compression from your SACD rips.

or

2) Transcode the SACD rips to WavPack DSD, which decompresses with way less processing power on general purpose processors, and decompresses to high resolution PCM on playback, or decompresses back to DSD if you use the decompressor tool.


The problem here is, DST decompression in foo_input_sacd uses as many processor cores as you have available to decode a single file at a time. foo_wave_seekbar tries to decode as many files as it can in the background using multiple processor cores. So there you have two things fighting each other for the whole processor. And there's no way to tell Wave Seekbar to stop processing, other than quitting the player.

DST requires 4 or more threads to decompress in real time on most processors. WavPack DSD requires a good chunk of... one thread only. Possibly even works on mobile platforms that have updated their WavPack libraries and have the processing power to spare.

Re: foo_input_sacd Component

Reply #6
One other option is to just let foo_wave_seekbar finish scanning it's current to-do list and then force a scan of the rest of the DST files sometime when you don't really need the computer for a while so that it doesn't have do it the first time you play a DST.  I usually do a seekbar scan of all DSD files when I first add a new SACD or album to my library...

Re: foo_input_sacd Component

Reply #7
Many thanks for the valuable advice.

Indeed, the problem occurs when first scanning DST files and also DSD.
At this moment I will follow the advice of forcing DST scans.

One question: Is there a seekbar component that does not scan the file?