Hello,
I use FB2K 1.3.17 in ASIO mode with a playlist containing songs with different sample rates (sr).
When the sr is different between 2 songs a sr switch occurs.
However during this sr switch little audio cutoffs can be heard, and samples are lost.
I first thank it comes from my soundcard (Focusrite Clarett 8Pre), but if I use Reaper or Audacity instead (in ASIO mode as well), these cutoffs do not occur.
After some googling, I found this page which talk about this issue https://www.head-fi.org/threads/foobar-2k-and-sample-rate-switches-leaves-audio-cut-off-after-switch.673550/ (https://www.head-fi.org/threads/foobar-2k-and-sample-rate-switches-leaves-audio-cut-off-after-switch.673550/)
Is it possible to fix this ?
Regards,
AF.
It may be possible to switch sample rates and formats with ASIO quickly, but I think those apps are simply picking one high rate and resampling to it. Try adding a resampler to your DSP chain, picking a target rate like 48000Hz, or 96000Hz if you really want to please the neighborhood bats and possibly destroy your tweeters.
I first thank it comes from my soundcard (Focusrite Clarett 8Pre), but if I use Reaper or Audacity instead (in ASIO mode as well), these cutoffs do not occur
Are you sure that samplerate switching really happens in your sound card when you use Reaper or Audacity? Can you see real current samplerate of soundcard somewhere?
You can try foo_dsp_pregap (http://www.saunalahti.fi/~cse/foobar2000/?changes=foo_dsp_pregap) to mitigate problem.
Hi,
Yes, the sr switch really occur.
I use the Focusrite Control to observe the sr change.
https://support.focusrite.com/hc/en-gb/articles/115004431669-Focusrite-Control-Tutorial-I-Understanding-Focusrite-Control
As a repro step :
- I take for example a 48k content
- In Reaper or Audacity project, I set sr to 48k (sr of the content)
- I set sr of the soundcard to 44.1k
- I then hit "play" and observe the sr switch
==> what I can observe is that the switch process takes slightly more time with FB2K than with Reaper or Audacity
Then sound is heard but beginning samples have been dropped (buffer timing issue ?).
Will try with the foo_dsp_pregap to see what happens...
Regards,
AF.
Hi,
Just tried foo_dsp_pregap. Same issue occurs.
Is there a kind Foobar developer in the vicinity ? :)
I didn't compile my own Audacity to get ASIO support so I tested REAPER instead. Granted I'm a total newbie with the program but I didn't see any option there to alter sample rate on the fly. The rate set in preferences was always used for playback and audio is resampled as required.
I tested my Asus soundcard's native ASIO and ASIO4ALL with the integrated sound chip on the motherboard (using Windows' driver). With REAPER I always lost the first samples on both sound devices and I tested WASAPI too and the same happened there. It also didn't matter if I used 44.1 kHz/48 kHz test file or 44.1 kHz/48 kHz samples. All combinations produced same results. And I did disable the fade effects from the file and the mixer showed action, just nothing came out of speakers.
With foobar2000 the native Asus ASIO drivers ate beginning of the samples when samplerate switched at track change. With ASIO4ALL beginning wasn't missing on either sound device.
But the very end of the previous track gets cut off with both ASIO implementations when samplerate changes. Same thing also happens with WASAPI event. WASAPI event over here allows hearing the very first samples of the next track though.
WASAPI push doesn't cut off the last samples on track change but it on the other hand snips away the beginning of the next track.
It seems like sound API/driver is doing the decision whether to play old buffered samples when stream format changes and just ignore new data until then or to drop buffered samples and start playing the new stream. It can't do both without something adding a delay.
Best solution to this problem is of course to use the DirectSound output method and utilize the existing resampler in Windows mixer. That way no samples will be missing in any situation. Another option is to use a resampler DSP so that DAC doesn't need to reinitialize itself in the middle of the playback.
Thank for the answer, interesting :)
For Reaper : I set the Reaper's project sample rate (in Project Settings tab) according to the sample rate of the content. This way Reaper forces soundcard sr switch, if needed.
Indeed if a resampler dsp is used, there will be obviously no sr switch... but it's no more the originial content.
Will try with ASIO4all to see if it changes something.
I also tried with Winyl and observed the same behavior than Foobar (cutoffs).
The Pregap DSP you tested wasn't previously equipped to deal with your problem but I uploaded a new version that should be able to help. Version compatible with foobar2000 v1.3.7 can be downloaded here (http://www.saunalahti.fi/~cse/foobar2000/v1.1/?changes=foo_dsp_pregap).
Since you are not using resampling or DS output you need to enable the "Add silence if audio format changes" setting in preferences.
Edit: the above setting also adds silence to the end of previous stream to prevent the end from getting cut off during sound card initializations. The end padding is currently hardcoded to 100 ms which was sufficient at least with WASAPI outputs at default settings.
Hi Case,
Thanks.
However it seems the plugin stills in 1.0 on the download page.
Both uploaded component files are verified to be v1.0.2. A redownload should solve any potential caching problem you saw.
Hi,
Humm.
When I try this link :
http://www.saunalahti.fi/~cse/foobar2000/v1.1/foo_dsp_pregap.fb2k-component
==> There is a dll inside, but its date is 08/05/2016 (1.0 version)
Something causes you to get cached results. I'll attach the file here temporarily.
Hello Case,
Thank you for your support. In the meanwhile I get the right files and made some tests.
However, even with your pregap DSP enabled (with the checkbox enabled), the behavior is the same : I have cutoffs when sr is switching.
The issue should be located somewhere else.
Is there in FB2K a debug mode/logging ?
Regards,
AF.
Use DS output, that's your solution.
Indeed if a resampler dsp is used, there will be obviously no sr switch... but it's no more the originial content.
It doesn't matter, proper resampling is transparent. Let Windows take care of that.
However, even with your pregap DSP enabled (with the checkbox enabled), the behavior is the same : I have cutoffs when sr is switching.
Do you use some DSP to remove silence or something similar? I don't see how that's possible otherwise. When samplerate changes your sound device is set to the new format instantly and the component feeds it X milliseconds of silence to make sure the device is ready when the actual samples start pouring in. Some optical links may require noise instead of silence to do the synchronization but the component has an option for that too.
The issue should be located somewhere else.
Is there in FB2K a debug mode/logging ?
There is only the console where the core and components report any info they wish.
It sounds like you still think foobar2000 is doing something wrong. It opens the sound device, feeds it all the samples of a track, then informs that the next track has these properties and switches the output into that mode. It can't know how much time each sound device may need before they have completed their synchronization or initialization, it will just start playing samples instantly.
I didn't see the samplerate switch delay, which is in milliseconds, cause any problem with normal music playback. I had to make special samples that were nothing but silence and had single sample peaks either as the first sample or the last sample to test the problem. Personally I prefer nice smooth playback with resampling over artificially added delays between track changes.
PS. Windows mixer's resampling has at least 114 dB signal to noise ratio, that's how well my analog sound card performed and Windows resampling couldn't lower its performance. Secret Rabbit code resampler has 144 dB SNR and I think SoX has the same if not more. There is no way a human ear can hear problems with modern resampling.