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: 1.6 beta 4: visualization is choppy with WASAPI exclusive and fading enabled (Read 6037 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Re: 1.6 beta 4: visualization is choppy with WASAPI exclusive and fading enabled

Reply #25 –
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?
Microsoft Windows: We can't script here, this is bat country.

Re: 1.6 beta 4: visualization is choppy with WASAPI exclusive and fading enabled

Reply #26 –
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.
Microsoft Windows: We can't script here, this is bat country.

Re: 1.6 beta 4: visualization is choppy with WASAPI exclusive and fading enabled

Reply #27 –
Quote from: Peter on
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!

Re: 1.6 beta 4: visualization is choppy with WASAPI exclusive and fading enabled

Reply #28 –
Quote from: Peter on
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.

Re: 1.6 beta 4: visualization is choppy with WASAPI exclusive and fading enabled

Reply #29 –
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.

Re: 1.6 beta 4: visualization is choppy with WASAPI exclusive and fading enabled

Reply #30 –
Quote from: Peter on
Quote from: deus-ex on
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.

Re: 1.6 beta 4: visualization is choppy with WASAPI exclusive and fading enabled

Reply #31 –
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.

Re: 1.6 beta 4: visualization is choppy with WASAPI exclusive and fading enabled

Reply #32 –
Quote from: Case on
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.

Quote from: Case on
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.

Quote from: Case on
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.

Re: 1.6 beta 4: visualization is choppy with WASAPI exclusive and fading enabled

Reply #33 –
Quote from: deus-ex on
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.

Re: 1.6 beta 4: visualization is choppy with WASAPI exclusive and fading enabled

Reply #34 –
The random should only cycle on restarts of the app. It depends on the service load order, or otherwise the priority setting.

Re: 1.6 beta 4: visualization is choppy with WASAPI exclusive and fading enabled

Reply #35 –
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.
Microsoft Windows: We can't script here, this is bat country.

Re: 1.6 beta 4: visualization is choppy with WASAPI exclusive and fading enabled

Reply #36 –
Quote from: Peter on
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?
 

Re: 1.6 beta 4: visualization is choppy with WASAPI exclusive and fading enabled

Reply #37 –
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.
Microsoft Windows: We can't script here, this is bat country.