LÖVE

raidho36 wrote:Maximum queued buffers right now is defined as 8, that means maximum buffered sound length would be just under 6 milliseconds, and you'll need to run at least as fast as ~170 updates per second just to keep the buffer filled.

The FFI one had a limit of 16 (on my pc, and a few others, anyway), though for what it's worth, i'm fairly certain i saw something like a loop trying to add buffers until it errors or something, somewhere in the codebase... it might have been something else.

raidho36 wrote:You probably haven't paid attention to that but many audio software have buffer length adjustable and it's usually in tens to hundreds of milliseconds long, and those that don't expose such option have a sensible default in thereabouts of same figures.

I know they are adjustable, though people prefer buffer sizes as small as possible... and to be fair, without heavy computational load, the 2.9 ms of buffer filling is still so fast it approaches the fast-end of ASIO latencies.

If you want smaller latency you'll just have to run at a faster update rate. If you can make source's update loop run at 1000 fps, you can have buffer length as low as 1 ms. It's probably more than doable using threads but don't quote me on that.

raidho36 wrote:If you want smaller latency you'll just have to run at a faster update rate. If you can make source's update loop run at 1000 fps, you can have buffer length as low as 1 ms. It's probably more than doable using threads but don't quote me on that.

Nix on irc is trying the latter, but my premise was already not using vsync and having an "atomic" update callback that basically ran as fast as it could... everything i said before, i meant it with those rates.

Well yea making main loop run at 1000 fps is one option, but it's probably a smarter idea to use threads: you'll have to put game logic and rendering in there somewhere, while even tiniest hiccup will result in buffer underrun at that buffer length.

This is my threaded demo! It uses a fast loop anyway though, since it's meant to be played and I want responsive input.
Github repo

Nixola wrote:This is my threaded demo! It uses a fast loop anyway though, since it's meant to be played and I want responsive input.
Github repo

This demo doesn't produce any sound for me (0.11). I assume that's what it's meant to do when the keyboard is pressed?

Dr. Peeps wrote:

Nixola wrote:This is my threaded demo! It uses a fast loop anyway though, since it's meant to be played and I want responsive input.
Github repo

This demo doesn't produce any sound for me (0.11). I assume that's what it's meant to do when the keyboard is pressed?

I know you wrote 0.11, but just to make sure, 0.11 is not yet released, the latest löve release is 0.10.2, so if you do have 0.11, the only ways you could have it is if you either built it from source yourself, or have checked out one of the nightlies.

Now, even if you do have a nightly, it may be old (or new) enough for that code to not work anymore.

...And lo, and behold, i just tried it out with my 0.11 nightly, which is quite recent, and it's silent here as well.

So basically, nixola didn't update his code to a later nightly that changed something he was using.
OR, he started to refactor, pushed, and now it's in a limbo state where it doesn't produce sound, without löve changing anything under the hood, that'd have been relevant.

zorg wrote:

Dr. Peeps wrote:This demo doesn't produce any sound for me (0.11). I assume that's what it's meant to do when the keyboard is pressed?

I know you wrote 0.11, but just to make sure, 0.11 is not yet released, the latest löve release is 0.10.2, so if you do have 0.11, the only ways you could have it is if you either built it from source yourself, or have checked out one of the nightlies.

Yep, I'm using a nightly build from yesterday. I understand the risks involved.

zorg wrote:...And lo, and behold, i just tried it out with my 0.11 nightly, which is quite recent, and it's silent here as well.

Great! It's not just me then. Thanks for checking.

Speaking of nightly builds, I noticed today that the Windows one now says 0.10.2, when yesterday it was 0.11. What's going on there?

Dr. Peeps wrote:Speaking of nightly builds, I noticed today that the Windows one now says 0.10.2, when yesterday it was 0.11. What's going on there?

LOVE's source repository has two branches: one for the current release cycle (0.10.x right now), and one for the next major version (0.11). The latter will be merged into the former once we're sure we don't plan to have more releases in the current cycle, but for now there are two branches.

The absolute latest build from appveyor might be from either one of those branches depending on whether the most recent commit to the repository was in the 0.10.x branch (named 'default') or the 0.11 branch (named 'minor').

There are branch-specific appveyor URLs so you can just get the latest build from a specific branch though.

default (0.10.x): https://ci.appveyor.com/project/AlexSzp ... /artifacts
minor (0.11): https://ci.appveyor.com/project/AlexSzp ... /artifacts

The URL at https://love2d.org/builds/ points to the default (0.10.x) branch.

That was my fault. I kind of pushed in the middle of a small refactor and I did not notice I didn't include another change. It should work now.