ASIO Output is missing samples and sounding dreadful

[NickHumphries]

I have a simple NAudio music player that works fine with WASAPI (and WaveOut), even oversampling to 176.4 kHz. But when I try to use ASIO, it seems to keep missing samples and sounds choppy or scratchy.
ASIO works fine with other players, like iTunes or AIMP. And I've tried using the ASIO driver that comes with my DAC, as well as ASIO4All.
I'm not sure where to look to adjust buffer sizes, or whatever needs to happen to sort this out.
Any help would be very welcome.
Is there any info I could provide to help investigate this? My code is really simple:

                if (MyAsioOut == null)
                {
                    MyAsioOut = new AsioOut(Settings.Device);
                }

                MyAsioOut.PlaybackStopped += OnPlaybackStopped;
                MyAsioOut.Init(MyResampler);
                MyAsioOut.Play();

I have tried without the resampler, just the AudioFileReader, and it's still bad.

I'm using Windows 10 and 11 (it's the same on both).

[NickHumphries]

Further to the above, when I check in debug, I can see that samples of 88200 bytes are being requested from the source with intervals of about 1.1 seconds. With WASAPI, it is every 835 ms. So, samples are being requested too slowly. But, so far, I can't find out why.
Is noone else having this problem?

[mdcdi1315]

'So, samples are being requested too slowly'

Do you hear the sound through ASIO very 'slow' as well?
If you do not, then this is not the problem.
The drivers just request data later than other ones - this is the driver buffering latency.
For example, on WASAPI you can modify the latency to any value you want.

Instead, I am suspecting that somehing happens with the block alignment on the ASIO interop - usually block alignment causes these issues. Had such in the past while I was porting the Windows Media Resampler interop code to .NET and playing around it. Anyway, I remember that if the processing buffer is not a multiple of the audio format's block alignment, screeches and weird artifacts are heard because the buffer's size is not a multiple of the block alignment.

Try also to play a file with a 48 kHz sample rate in ASIO and tell me if it played without issues.

[NickHumphries]

Thank you, yes samples are being requested too infrequently so the playback is gappy, but not slow. I've tried 48 kHz and the results are the same. Wasapi is perfect. Cheers, Nick.

…

On 25 February 2026 15:23:49 GMT, "N.A." ***@***.***> wrote: 'So, samples are being requested too slowly' Do you hear the sound through ASIO very 'slow' as well? If you do not, then this is not the problem. The drivers just request data later than other ones - this is the driver buffering latency. For example, on WASAPI you can modify the latency to any value you want. Instead, I am suspecting that somehing happens with the block alignment on the ASIO interop - usually block alignment causes these issues. Had such in the past while I was porting the Windows Media Resampler interop code to .NET and playing around it. Anyway, I remember that if the processing buffer is not a multiple of the audio format's block alignment, screeches and weird artifacts are heard due to the buffer's misalignment. Try also to play a file with a 48 kHz sample rate in ASIO and tell me if it played without issues. -- Reply to this email directly or view it on GitHub: #1244 (comment) You are receiving this because you authored the thread. Message ID: ***@***.***>

[mdcdi1315]

Mmm, gappy and infrequent requests. Possibly the math for calculating when the next buffer fetch should be done is incorrect, or there is an obscure driver bug with the ASIO itself - have you checked whether you have the latest version (or if that is the case, maybe an older version)? I have seen many times drivers implemented through one API to work correctly, while on another API to have bugs.

The problem to all this is that the ASIO project would not have been uploaded if there was known that this bug is around, and the problem is that I do not have an ASIO-capable sound card to test this.

There is not something you are doing wrong with the API itself, assuming you convert to the driver's audio format, so it must be something like a race condition or a driver bug.

[NickHumphries]

Hi again,   So, I have tracked the problem down to the MediaFoundationResampler. If I take that out of the playback chain, retaining the ConcatenatingSampleProvider, SampleAggregator and Volume control, it works fine, with a music track (m4a ALAC). If I include the MediaFoundationResampler, it stutters and is gappy. However, without the MediaFoundationResampler, if I play a test track (400 Hz sine, WAV), which is fine with WASAPI, I only get the right-hand channel, which seems odd, but might be a clue.   I have tracked everything through in debug, as far as I can, but can't see anything obvious. However, if the problem is the MediaFoundationResampler, I'm not sure what I can do, but I really need the resampling, as my DAC recommends 176.4 kHz.   BTW, if you don't have an ASIO sound card, the ASIO4All driver works well.   Cheers,   Nick. ------ Original Message ------ From: ***@***.*** To: ***@***.*** Cc: ***@***.***; ***@***.*** Sent: Wednesday, February 25th 2026, 17:36 Subject: Re: [naudio/NAudio] ASIO Output is missing samples and sounding dreadful (Discussion #1244)     Mmm, gappy and infrequent requests. Possibly the math for calculating when the next buffer fetch should be done is incorrect, or there is an obscure driver bug with the ASIO itself - have you checked whether you have the latest version (or if that is the case, maybe an older version)? I have seen many times drivers implemented through one API to work correctly, while on another API to have bugs. The problem to all this is that the ASIO project would not have been uploaded if there was known that this bug is around, and the problem is that I do not have an ASIO-capable sound card to test this. — Reply to this email directly, view it on GitHub <#1244 (comment)> , or unsubscribe <https://github.com/notifications/unsubscribe-auth/AFTJF4VZHSFU5WF5REBYNLD4NXMRBAVCNFSM6AAAAACVQ4NYIWVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTKOJSGU3TOMY> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[mdcdi1315]

So we do return to my original assumption that something with the incorrect buffer size is happening. Also, somehow the issue further spans to the fact that the IMFSample does not get it's attributes cleaned (Resampler)... (But it somehow it works without it for small kHz sample rates)

Wait until tomorrow to adapt my own interop'ed version of the Resampler to work with NAudio and you can test it then.

But if you point to it yes it is that for sure, because I have faced this issue as well. So it is not ASIO, it is the Resampler.

Until then you can see the patches I have done for the Resampler to properly work here.
Primarily we are interested for lines 225, 274 and 172, which are missing from the NAudio implementation.
Note also the NAudio resampler implementation leaks buffers.

So, it is the Resampler (But never imagined that the bug also exhibits with a large target sample rate).

Note also that we need to create an issue ticket for this.

[mdcdi1315]

Well I have adapted some parts of my own interop'ed version of the Resampler to be compatible with NAudio.

Note that this might not work well it can have bugs, primarily if you see AccessViolationException it will be possibly be because I do not do something correctly with the COM objects..

Well, the attached zip file contains two source files, add them to your project, then, just replace YourNamespace with any namespace you like and it should probably work and resolve your issue. It might also leak buffers as the original implementation does.

The zip:
MediaFoundationResamplerModified.zip

If you couldn't use it (compilation errors or anything else) tell me to to take all the time to port the entire version of the Resampler interop, which might take some more time.