HydrogenAudio

Hosted Forums => foobar2000 => Support - (fb2k) => Topic started by: foofer on 2017-10-23 18:35:06

Title: foo_input_sacd Component
Post by: foofer on 2017-10-23 18:35:06
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?
Title: Re: foo_input_sacd Component
Post by: tedsmith on 2017-10-23 18:39:24
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.
Title: Re: foo_input_sacd Component
Post by: foofer on 2017-10-23 19:06:01

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%.
Title: Re: foo_input_sacd Component
Post by: eahm on 2017-10-23 19:12:27
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.
Title: Re: foo_input_sacd Component
Post by: foofer on 2017-10-23 19:26:34

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.
Title: Re: foo_input_sacd Component
Post by: kode54 on 2017-10-24 00:17:19
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.
Title: Re: foo_input_sacd Component
Post by: tedsmith on 2017-10-24 02:26:51
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...
Title: Re: foo_input_sacd Component
Post by: foofer on 2017-10-25 06:59:59
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?