Found bug in component "ASIO Output" foo_out_asio v2.2.4

2025-01-15 18:40:21

I found a bug in the above. Looks like Peter himself is the author of this component.

How can i report this bug to him?  Looks to me he does not have any contact options ...

Re: Found bug in component "ASIO Output" foo_out_asio v2.2.4

Reply #1 – 2025-01-15 19:53:39

You report problems best by reporting them here on the forums. If it is a good report so that the problem can be verified, people will make sure Peter sees it.
I for one expected to read details about a bug when I opened this thread.

Re: Found bug in component "ASIO Output" foo_out_asio v2.2.4

Reply #2 – 2025-01-15 21:58:22

I recently updated foobar from an old v1.x install from 2022 to latest 2.x with latest components.  For reasons i cannot detail here i use foobar2000/asio together with a DAW (Reaper) that will use the same audiocard via ASIO aswell.  I have to use different samplerates all the time - 44, 48, 88, 96 and even 192k.  Occasionally i have to switch to Reaper and back/forth while playing some audio through foobar.  Since Reaper also access the audiointerface via ASIO directly, it thereby sets "its" project-samplerate as soon as i click into Reaper. That is no problem as long as its between 44/48k (of course foobar's replay-speeds changes).  But as soon as foobar samplerate was at 88k or higher and then switching back to Reaper which is at 48k for ex., foobar goes into deadlock and needs to be killed via TaskMgr!
In my previous v1.x install this "ASIO samplerate-switching" has worked nicely... but with new the version no more.  Is this actually a bug? Not fully sure - but it has worked before without any deadlock to foobar. Unfortunately i don't know which version of foo_out_asio component i had before and which v1.x version of foobar

Re: Found bug in component "ASIO Output" foo_out_asio v2.2.4

Reply #3 – 2025-01-17 16:34:17

Finally had a chance to test this and I can't seem to be able to replicate the problem. With Ifi drivers foobar playback stops progressing and seekbar starts wobbling, but once Reaper is on the background and releases ASIO, hitting Stop and playing again allows everything to work. With an ASIO2WASAPI wrapper locking the device for exclusive use made Reaper crash when it tried to access the driver. With shared mode both operated fine simultaneously at their respective sampling rates and ASIO driver resampled things transparently.

Re: Found bug in component "ASIO Output" foo_out_asio v2.2.4

Reply #4 – 2025-01-19 11:28:07

As audiointerface I use an RME's  "ADI-2 PRO FS-R Black Edition".  I'm quite sure ASIO2WASAPI is not involved here, also no resampling on the driver level is done.   The the sole reason why i use foo_out_asio component is that is actually *changes* the samplerate of the soundcard itself to the one of the PCM (linear) .wav audio that i play.   I do *not* want any resampling to be done!
In other words:  when i toggle between the DAW and foobar, the internal samplerate of my audiointerfaces will change each time.  This change goes well as long as the switch is between 44.1k and 48k samplerate.  But as soon as this happens between e.g.  44.1k(Reaper) and  96k(foobar), foobar goes into deadlock.  I would guess that the source of the issue is somewhere within this foo_out_asio component as it loooks to me foobar cannot change the samplerate back up to 96k again (Reaper itself always does the ASIO samplerate change in every direction properly, no matter what).  If i then kill foobar via TaskMgr and click on the 96k PCM file to playback, foobar will change the samplerate from 44.1k to 96k as expected and plays the file properly.   (Sorry if i had not been clear on this subject the first time)

Re: Found bug in component "ASIO Output" foo_out_asio v2.2.4

Reply #5 – 2025-01-19 12:15:11

You were very clear. I'm simply stating that under no circumstances did I manage to replicate foobar2000 locking up requiring its task to be killed.

I'm not claiming the foobar2000 ASIO component to be perfect. I don't know if the freezing playback that requires hitting Stop is a bug in ASIO drivers or a bug in the component. How certain are you that the only solution to your freeze is task manager and killing foobar2000? Did you actually try pressing Stop? The entire reason foobar2000 uses the ASIOHost exes for ASIO is to circumvent buggy ASIO drivers and keep foobar2000 stable despite any possible issues in them.

Are you using latest ASIO drivers for your device? It sounds scary and weird to me that a device that pretends to lock its output to a certain sample rate would allow another outside process to alter the frequency and ruin all output. Imagine using that device for professional purposes, like recording a live performance, and suddenly sample rate changed in the middle of the act.