SoundQueues

[raidho36]

And there we go. It's an extension of Source class functionality and it works exactly as you'd expect. I've created a pull request, so hopefully it (or something equivalent) makes it into next version. Meanwhile, you can check it out at my bitbucket page and see how it compares to other implementations.

https://bitbucket.org/rcoaxil/love

https://bitbucket.org/rcoaxil/love/wiki/Home

[zorg]

And there we go. It's an extension of Source class functionality and it works exactly as you'd expect. I've created a pull request, so hopefully it (or something equivalent) makes it into next version. Meanwhile, you can check it out at my bitbucket page and see how it compares to other implementations.
https://bitbucket.org/rcoaxil/love
https://bitbucket.org/rcoaxil/love/wiki/Home

Can you link a windows binary though? If you'd be so kind, i'd appreciate it

[raidho36]

No, sorry. I use Linux so I can't give you my binaries, and chances are my Windows cross-build won't work since I never bothered to set it up properly and the only way I could test it is over (not an) emulator which may or may not represent real system, you'll have to build it yourself. Good thing it's a very simple and straightforward process - once you set up your tool chain of course, it's a bit of a pain in Windows.

[Nixola]

I managed to set everything up (finally), here's my build:
32bit: 7z, tgz
64bit: 7z, tgz

[zorg]

First demo app to use them:

raidhodemo.love

(1.63 KiB) Downloaded 89 times

No window, just a console, generating a sine wave. Bohr-ing.
Edit: some stats:

Code: Select all

-- benchmark: smp is buffer size in samplepoints (not ms!), leftmost number is the averaged time taken by OpenAL to accept new buffers.
0.0316 -- 256smp  8bit  8000Hz 1Ch sine -- ~32ms, probably could go way lower, FFI implementation didn't underflow with 32smp/4ms.
0.0058 -- 256smp 16bit 44100Hz 1Ch sine -- ~5.8ms
0.0029 -- 128smp 16bit 44100Hz 1Ch sine -- ~2.9ms

[raidho36]

Functions in Source.cpp file have "Atomic" suffix because they are called when mutex is locked, providing thread safety. "Atomic" in threading is used in literal sense - "indivisible" - because computer couldn't do anything else with locked data while atomic operation is in progress.

Also, I think there might be something wrong with the test you used - to me, it loads some odd 800 samples in thereabouts of 5 microseconds. Maybe you're measuring sine generator performance? Or maybe you're using "ms" but you really mean "µs" (or "us"), that makes most sense.

[zorg]

The demo i posted uses a mono buffer with length of 128 samplepoints.
One buffer's (naively calculated) latency is 128 smp / 44100 Hz = 0.0029 seconds * 1000 = 2.9 milliseconds.
Based on the accumulated dt-s in my table (the first values), this calculation works.

That said, maybe :setSample has a gigantic overhead, or my logging to console might have slowed it down; still, even with the shortcomings, it's on par with lpghatguy's FFI implementation, which is nice.
Edit: also, your project crashes for me: xmp.lua:3: cannot load module './libxmp.dll' module not found.
Edit2: moving it into the löve folder including your changes gives the message that the dll is not a win32 application.
Edit3: getting the 64bit version and moving the dll there gives: "xmp.lua:421: cannot resolve symbol 'errno': Given procedure not found"

[raidho36]

Oh, now I see. You said "leftmost number is the averaged time taken by OpenAL to accept new buffers" so I thought that's how long Source:queueData() takes to execute, but that's just buffer length in milliseconds. Coincidentally (and fairly obviously), that's how long it takes for playing source to become queueable again after its queue have been completely filled. But that has nothing to do with framework performance.

Edit: also, your project crashes for me: xmp.lua:3: cannot load module './libxmp.dll' module not found.
Edit2: moving it into the löve folder including your changes gives the message that the dll is not a win32 application.
Edit3: getting the 64bit version and moving the dll there gives: "xmp.lua:421: cannot resolve symbol 'errno': Given procedure not found"

Yes that's precisely what I referred to when I said "chances are it won't work".

[zorg]

-> But that has nothing to do with framework performance.
Sure, but lowering the buffer size will make it underflow; even if this isn't (strictly) related to the framework's performance (cpu utilization is though, which i did mention that it seemed to use less than the ffi version for the same test, so that's good)

Also, I assumed you meant only your fork of löve, with the Queue subtype added to sources, not the actual project you wanted to show; you know, as before, me assuming that the whole point of this was to have something that worked on all platforms supported by löve.

[raidho36]

Well I got that feature working on all platforms (I assume anyway, since it has no platform-specific code), so there's that.

libxmp doesn't work because it's a cross-build to Windows target which I never bothered to set up properly, and of course never tested. It builds, but it doesn't work.

Short buffers will underflow because source runs through them faster than you can push them, this will happen with any implementation - your buffer just have to be long enough for you to keep up with them playing. Say your buffer is 32 samples at 44kHz, 0.7 milliseconds. 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. 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.