Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Huge latency on Windows #221

Open
liquidev opened this issue Oct 1, 2019 · 6 comments
Open

Huge latency on Windows #221

liquidev opened this issue Oct 1, 2019 · 6 comments

Comments

@liquidev
Copy link

liquidev commented Oct 1, 2019

I'm having a bit of an issue with libsoundio. For some reason, on Linux, the library works perfectly OK—I set the latency to a very small value (like 0.001), and as expected, it works perfectly. However, when I try to set the latency on Windows, the effective latency is huge (up to 8s), and this was reproduced by multiple users on multiple different machines.

Here's my bit of code where I instantiate the device, set the write callback, etc.

https://github.com/liquid600pgm/rapid/blob/master/src/rapid/audio/device.nim

Is there anything I'm doing wrong, or is this an issue with soundio?

@shangjiaxuan
Copy link

It seems the library defaults to 4 second buffer time on wasapi with shared device. I remember there was spec stating that on backend that support variable length buffering, the min_frame and max_frame in the callback is set to 0 and maximum value the backend buffer can hold.

Modifying the library source code can result in shorter maximum buffer size, but it may be better to restrict your own rendering to use whatever size you want. The shared stream typically has a os audio engine refresh time of 10ms, thus anything less than 10ms making it do extra callback every time is not really a good idea (you may look at exclusive device if you want less latency).

Also, it seems that from windows 10, the sdk exposes the IAudioClient3 interface where you can query the update modes available. Also there's support for event based shared stream, so there can be less to do on the audio thread event loop.

(I was looking at the docs recently and trying to add a separate code path where when IAudioClient3 interface is available, use that extension for shared rendering. Don't know when there will be a pull request or if it would be merged... Currently things seems to work fine on my specific setup currently.)

@shangjiaxuan
Copy link

shangjiaxuan commented Feb 15, 2020

Just created a pr here (#231), you can see if the patch works out for you (only supporting lower latency output for now). (Use it and modify it any way you like, but I'm not absolutely sure if it will work on all circumstances.)

For a much cleaner fix, just change the 4 second to 20ms. This should work well on most cases (10ms will have dropouts probably due to padding needed by the os).

@wegylexy
Copy link
Contributor

Will the original author add collaborators? There are so many forks and open pull requests.

@Swyter
Copy link

Swyter commented Mar 6, 2021

CC @andrewrk. Yeah, it's a bit sad seeing all this great work bottlenecked by a lack of maintainers. I understand that there are other priorities, and that you can't accept things willy-nilly. Hopefully this can be delegated to someone else. Maybe collaborators like @cgutman or the others want to step up.

I'm just evaluating the pros and cons of using it, but it's something worth discussing. I think.

@mdsitton
Copy link

The dev is too busy focused on zig https://github.com/ziglang/zig these days to care about this library anymore. I would suggest using https://github.com/mozilla/cubeb as an alternative.

@wegylexy
Copy link
Contributor

Never mind, we decided to migrate to .NET 6.0 and use NAudio.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants