If output mode is WASAPI exclusive (with official component) and Fading (on Output page settings) is enabled, visualization becomes choppy. It especially noticeable on Spectrogram. And it is even more noticeable with 3rd part component foo_musical_spectrum (https://wiki.hydrogenaud.io/index.php?title=Foobar2000:Components/Musical_Spectrum_(foo_musical_spectrum))
Another problem: if Fading is disabled during active playback with WASAPI exclusive output, it results in error "Device in use". Is this expected behavior?
Should be fixed in beta 5, thanks for reporting.
Hi Peter, I find the issue reported by Rollin (OP) is not fixed with the latest beta 5. I'm on Windows 10 64-bit build 2004.
Furthermore I just noticed that the visual representation, for example with UIE Vis Channel Spectrum, is quite different using the new default WASAPI output, which presumably implies that the sound output is different (and perhaps of lower volume?). Whereas comparing the old official WASAPI output plugin v3.3 with the WASAPI shared plugin v0.6.12 by Case, both of these provide the same sound output and visual representation. Currently I'm sticking with WASAPIS by Case.
Please let me know if you need any further details or perhaps require my assistance to investigate the issue further.
The issues (see previous post) remain valid with recent beta 6.
I don't see any problems in beta 5 and 6. Although i never used UIE Vis Channel Spectrum. Maybe it is just too outdated to work correctly with last fb2k?
What makes you think UIE Vis Channel Spectrum does not work correctly with current foobar2000 just because of its release date?
I said that the visual representation of UIE Vis Channel Spectrum is the same both with the old exclusive WASAPI output plugin and the WASAPIS output plugin by Case. Only when using the new internal WASAPI shared output the visual representation is different. It shows a lower global volume and a more dense frequency range, i.e. the very high frequencies shown to the far right of the spectrum appear to be non-existent.
Also choppy output with smooth seeking, pause and volume changes enabled using the old WASAPI output or the WASAPIS plugin is still a issue in beta 6.
Sounds like it's hooking into the output stream rather than the visualization subsystem. I don't know what sample rate the visualization subsystem operates on, but it appears that visualizer is showing the output of the resampler pass before the audio goes to the output device.
Of course when you upsample the output sharply, perhaps to 96kHz or higher, the frequencies are going to look more bunched together, as it's showing frequency bands all the way up to 48kHz, instead of whatever your file may actually be.
The fact that it's also showing a lower volume level, appears to indicate it's getting the audio after the playback and output chain has reduced the volume to account for the ReplayGain correction level and/or the configured playback volume level, which are also applied before output.
Neither of these should be affecting visualization, though. So either there's something funny with the visualization system, or there's something funny with the way this component collects that data.
Choppiness could be due to the increased sample rate of the audio it's processing. The visualization subsystem allows components to sample PCM and optionally FFT data at any interval they desire, limited only by the CPU usage incurred by the FFT process on the audio.
Please do report whether this visual anomaly also affects the player's bundled visualizations, and not just this third party component.
Of course when you upsample the output sharply, perhaps to 96kHz or higher, the frequencies are going to look more bunched together, as it's showing frequency bands all the way up to 48kHz, instead of whatever your file may actually be.
I'm outputting sound in Foobar2000 via WASAPI with no additional upsampling (like to 96 kHz). The native output rate of my soundcard Soundblaster ZXR is 24-bit 48 kHz. The soundcard speaker output is configured to Stereo Direct, which means no additional soundprocessing takes place, like Crystalyzer, Surround, Enhanced Bass etc.
Choppiness could be due to the increased sample rate of the audio it's processing. The visualization subsystem allows components to sample PCM and optionally FFT data at any interval they desire, limited only by the CPU usage incurred by the FFT process on the audio.
I just rechecked that issue with foobar2000s default UI, as I'm normally using ColumnsUI. The choppiness issue remains the same. Again, it ONLY appears when activating the "smooth" option in the output section and using either the WASAPI exclusive output plugin or the WASPIS plugin by Case. The choppiness is NOT affected by any visual output plugin, as I checked that with no visual output plugin enabled!
Please do report whether this visual anomaly also affects the player's bundled visualizations, and not just this third party component.
The internal Spectrum view shows similar behavior (lowered volume, denser spectrum range) with the internal WASAPI output, while with the old WASAPI plugin or WASPIS by Case the visual appears identical with no such issues.
I'm outputting sound in Foobar2000 via WASAPI with no additional upsampling (like to 96 kHz).
If you use new Default (WASAPI shared) then fb2k will automatically resample to the samplerate which is set for sound card in Windows' sound settings.
If you use new Default (WASAPI shared) then fb2k will automatically resample to the samplerate which is set for sound card in Windows' sound settings.
Thanks for noting, Rollin, it is set to my soundcard default 24 bit 48 kHz. I wonder how come there are no such issues using Case WASAPIS plugin, which also uses shared WASAPI mode?
I wonder how come there are no such issues using Case WASAPIS plugin, which also uses shared WASAPI mode?
Different implementation of wasapi plugin, explained here (https://hydrogenaud.io/index.php?topic=116739.msg984876#msg984876).
Hi Vicas. Yeah, that's true. Then again, the output of the old WASPI exclusive plugin by Peter and the WASAPIS shared plugin by Case appear acoustically and visually the same. Why would foobar2000s new internal WASAPI solution differ that obviously?
I don't know but hope it will get fixed.
I wonder how come there are no such issues using Case WASAPIS plugin, which also uses shared WASAPI mode?
ObviouslyProbably, because it does not resample automatically to the samplerate which is set for sound card in Windows' sound settings or maybe resampling is done later in signal path.
Hi Rollin, I think it's not quite like that. Check this post from Case regarding the inner details of his WASAPIS plugin: https://hydrogenaud.io/index.php?topic=116739.msg963522#msg963522
Maybe related issue, lyrics display doesn't look smooth here with WASAPI Exclusive and fading enabled
Hi Rollin, I think it's not quite like that. Check this post from Case regarding the inner details of his WASAPIS plugin: https://hydrogenaud.io/index.php?topic=116739.msg963522#msg963522
"if needed" in relation to Case's component actually means "if samplerate is not supported by sound card (or windows' mixer)".
The reported issues all remain unresolved with recent beta 10. I wonder why this thread does not get more attention by the developer(s)? If any more details or assistance is required in order to fix the problems, I'm glad to help.
I saw jerky playback progress indication in earlier betas. Waveform seekbars weren't running smoothly but instead the position cursor was jumping. This was fixed.
And I see the difference in visualization spectrums - this is because the new default output injects an invisible resampler to the playback chain. My component uses resampler internally without affecting core DSP chain.
But I can't see any choppiness with Channel Spectrum panel visualization. I thought it runs at my monitors 144 Hz rate but recording seems to indicate it runs at ~60 fps. Either way it looks very smooth. Please provide a video showing the issue as currently there's nothing Peter can do.
I saw jerky playback progress indication in earlier betas. Waveform seekbars weren't running smoothly but instead the position cursor was jumping. This was fixed.
If that should also apply to the UIE Wave Seekbar, that one was never jerky for me.
And I see the difference in visualization spectrums - this is because the new default output injects an invisible resampler to the playback chain. My component uses resampler internally without affecting core DSP chain.
Thank you for sharing some inside view on this. That's one question down.
But I can't see any choppiness with Channel Spectrum panel visualization. I thought it runs at my monitors 144 Hz rate but recording seems to indicate it runs at ~60 fps. Either way it looks very smooth. Please provide a video showing the issue as currently there's nothing Peter can do.
Attached are example videos I recorded using Windows' internal Xbox Game bar feature. Note that the "WASAPI exclusive" video does not carry any recorded sound due to being exclusive to foobar2000, obviously. Both WASAPI exclusive and your WASAPIS plugin produce the same output visually and acoustically and are equally affected by the "smooth fade" output option. Personally I don't mind this issue much as I'm using your WASAPIS plugin which does not require the smooth fading enabled.
The waveform playback progress cursor doesn't seem to move smoothly in any of the videos. Are you perhaps using the GDI render mode? That would explain why you didn't see a problem with that as it doesn't have subpixel rendering.
The smooth mixer enabled recording shows also audio glitching, is that accurate? Which resampler does the console report as being used? Could you check foobar2000 process CPU usage? Those large visuals must be quite demanding. I believe smooth mixer runs with much smaller output buffers to be able to do its fades in near-realtime.
The waveform playback progress cursor doesn't seem to move smoothly in any of the videos. Are you perhaps using the GDI render mode? That would explain why you didn't see a problem with that as it doesn't have subpixel rendering.
Now that you mention it I can confirm that the waveform doesn't progress smoothly either. I didn't notice it as it is rather subtle to see. I witnessed a general increased system burden after the last two major Windows updates, the system does not run as smooth as it used to. And yes, I use the GDI renderer of Zao's waveform plugin, as this is the only one which allows me to get the visual result you see.
The smooth mixer enabled recording shows also audio glitching, is that accurate?
Yes, with smooth fading enabled there are audio glitches, indeed, but only with WASAPI exclusiv and WASAPIS, not with the new internal WASAPI.
Which resampler does the console report as being used?
According to the console the PPHS resampler is called automatically (screenshot 1), but I don't know why it does this. In my DSP chain I have configured the SOX resampler to take action on any audio data which is not 44 kHz. The sample rate of the used test sample is 44 kHz.
EDIT: It appears that foobar2000 does not necessarily obey to your DSP chain configuration. I have the SOX renderer set to 44 kHz, but often the internal PPHS renderer is used instead. I cannot detect a foolproof pattern why this happens. I have changed the SOX renderer to 48 kHz now, so it is not triggered when using WASAPIS output. This seems to have ended automatic calling of the PPHS renderer, too. Note that this change does not affect my CPU usage.
Could you check foobar2000 process CPU usage? Those large visuals must be quite demanding. I believe smooth mixer runs with much smaller output buffers to be able to do its fades in near-realtime.
Actually it's not that much of a burden on my system (screenshot 2).
Thanks for all the details.
Can you please test with any other sound device, such as onboard audio? To rule out soundcard (SoundBlaster ZxR, I assume) as a factor.
It appears that foobar2000 does not necessarily obey to your DSP chain configuration. I have the SOX renderer set to 44 kHz, but often the internal PPHS renderer is used instead.
It's not replacing one resampler with another. Additional resampler is put at the end of the chain to ensure that the correct sample rate is sent to the output. If another resampler did the job before, it's does nothing and just passes unaltered data thru.
Can you please test with any other sound device, such as onboard audio? To rule out soundcard (SoundBlaster ZxR, I assume) as a factor.
Sorry, I can't as my mainboard does not have a regular onboard sound chip installed. It comes with an optional extension card which houses some old Soundblaster XiFi-ish solution which I never had installed/used.
For completeness I just checked all available speaker output options of my Soundblaster ZxR (5.1 Surround, Stereo 2.0/2.1, Stereo Direct) but that does not affect the "smooth fading" choppiness issue. If I can assist with any additional info/details or by running a foobar2000 debug version/output driver of some sorts, please let me know.
I don't seem to get this bug on anything that I have hooked up right now. I'll try some old Creative cards later.
Regarding audio glitches-
The old WASAPI-exclusive plugin has some buffering settings in Preferences / Advanced / Playback / WASAPI, do any of these make any difference? Also which mode did you use with WASAPI exclusive, Push or Event?
What about default output with fading enabled? Are visuals choppy or good then?
There's a reason why it may work better than default output without fading in the current build.
The old WASAPI-exclusive plugin has some buffering settings in Preferences / Advanced / Playback / WASAPI, do any of these make any difference? Also which mode did you use with WASAPI exclusive, Push or Event?
Now we are getting somewhere because of your comments! I completely overlooked the main buffer length slider which appears to be available for every output option (WASAPI exclusive, WASAPIS, internal WASAPI). I had it set down to the lowest 50 ms to achieve the lowest possible delay for visual plugins. I had it like this since many years (~10+) without any issues. The choppiness issues are gone for every output option when setting the buffer to 100 ms.
When using your WASAPI exclusive plugin I always choose event mode, according to WASAPI information found on the net this option is to be preferred if your sound card driver does support it.
So it appears, the root cause is because the main output buffer length was set to low. The output option dialog already has a warning text for not setting the buffer to low, and I read it back then when I altered the setting. Probably this warning should be made more prominent (larger font, bold letters) and/or change the warning text color to red when the slider is below the 100 ms gauge?
Thank you, Peter, Case and all other participants very much for your valuable input, it helped a lot to solve the issue!
What about default output with fading enabled? Are visuals choppy or good then?
There's a reason why it may work better than default output without fading in the current build.
As I already wrote previously, your new default output never produced any choppiness issues, regardless if fading is enabled/disabled. I only had choppiness issues when using any of the the external WASAPI output plugins WITH fading enabled.
Actually my main concern is/was, that you get a different visual representation when using your internal output (as can be seen in my videos posted above). I.e. the range of frequencies appears to be more dens, with the frequencies shown at the far right corner (high frequencies) to be missing. As Case explained above this is due some to internal mixing of our new internal output.
EDIT: I found the answer as to why I get a different frequency imagery with the new internal WASAPI output plugin. Using either WASAPI exclusive or WASAPIS by Case with the SOX-Resampler set to target rate 48 kHz instead of 44 kHz, the visual representation is almost the same.
Hi all!
Are you noticed in beta 1.6 that Spectrogram draws picture scaled to soundcard's output sample rate? My DSP list is empty. In version 1.5 or with "WASAPI shared output by Case" everything is OK.
It appears that foobar2000 does not necessarily obey to your DSP chain configuration. I have the SOX renderer set to 44 kHz, but often the internal PPHS renderer is used instead.
It's not replacing one resampler with another. Additional resampler is put at the end of the chain to ensure that the correct sample rate is sent to the output. If another resampler did the job before, it's does nothing and just passes unaltered data thru.
Today I witnessed that same issue again, so I retested more thoroughly with several audio files. For each audio file in the test run the preconditions were the same:
1. foobar2000 is not running
2. start foobar2000 with an audio file via file manager
3. open foobar2000's console to check which resampler is in use
4. close foobar2000
The result is that for the same audio file sometimes my pre-configured resampler SOX gets used, sometimes the internal PPHS resampler is called instead (screenshot). I think that should not happen.
The new WASAPI output always injects a resampler to the DSP chain regardless if it's needed when playback starts or not. Pretty sure Peter made it this way for simplicity. No need to track source signal changes, no need for multiple buffers and no need for separate code paths for resampled and direct outputs.
Remember that resamplers don't do anything when the source and target sample rates match - the audio passes straight through them untouched.
You may wish to visit Preferences -> Advanced -> Tools and enter "Resampler (SoX)" as a parameter for "Automatic resampling preference". That way all components that need to call a resampler will use SoX.
The new WASAPI output always injects a resampler to the DSP chain regardless if it's needed when playback starts or not. Pretty sure Peter made it this way for simplicity. No need to track source signal changes, no need for multiple buffers and no need for separate code paths for resampled and direct outputs.
Peter wrote "Additional resampler is put at the end of the chain...", but according to the console output the resampler is always called before the audio file is opened.
Remember that resamplers don't do anything when the source and target sample rates match - the audio passes straight through them untouched.
I know, but if it is required it should use the one I have pre-configured and not pick one by chance.
You may wish to visit Preferences -> Advanced -> Tools and enter "Resampler (SoX)" as a parameter for "Automatic resampling preference". That way all components that need to call a resampler will use SoX.
Thanks for the hint, I just did that now. The existence of this setting implies that without knowing/using it the choice of the resampler is indeed random, which it should not.
The existence of this setting implies that without knowing/using it the choice of the resampler is indeed random, which it should not.
Wow, indeed, it is random. Good finding.
The random should only cycle on restarts of the app. It depends on the service load order, or otherwise the priority setting.
Random resampler preference is unacceptable, thanks for pointing this out. It will be addressed shortly.
Edit:
Resampler merit system is used to determine the best one, but if two of them return the same priority value, order is indeed random, which is unacceptable. From now on, default SSRC will be used unless overridden.
Resampler merit system is used to determine the best one, but if two of them return the same priority value, order is indeed random, which is unacceptable.
How do you determine which resampler is the best one? What are the requirements or properties a resampler has to have to pass that test?
There is a floating-point priority value returned by each resampler. Of course nobody really paid attention to this until now so many of them return the same value. Also, some resamplers (PPHS) support only a subset of possible sample rate conversions, not allowing arbitrary conversions, so if even if they have a higher merit, they are not always used.
Anyway, merit is now disregarded, SSRC is used unless requested otherwise by user.