SoundQueues

[raidho36]

Well it's better simply because it's a (would-be) LÖVE feature rather than a hack. I really don't like the idea of interfering with its inner workings to get the results you want - user implementation shouldn't intersect with its functionality and ideally the framework itself should be capable of doing it. That way you don't have to yourself implement it and, more importantly, it's integrated into the rest of the system and not standing alone.

[zorg]

raidho36: Then please make sure to implement every feature one would want support for, that's feasible Or at least consider the input of others. (me for instance )
Again, i can only point you to the already existing FFI implementation i use, and the examples that i created.

[raidho36]

How do you extract a memory pointer from LuaJIT cdata<void*> on LUA stack? I have everything working in the AL department and it works flawlessly with SoundData objects but I can't figure out how to load data by FFI pointers, which is to say, how to load a FFI pointer into a variable at all.

[zorg]

raidho36: I thought you weren't gonna use the FFI?
(or are you confusing the lua C api with FFI?)

[raidho36]

Here's what I have, and it doesn't work. Which is to say, it works as long as the 2nd argument is a lightuserdata (such as from SoundSource:getPointer), but not when it's FFI cdata - which kinda makes sense, but then also kinda doesn't. I've tried pulling it as userdata but cdata looks opaque from there and I can't get meaningful value out of it.

Code: Select all

int w_Source_queueBuffer(lua_State *L)
{
	Source *t = luax_checksource(L, 1);
	luax_catchexcept(L, [&]() {
		if (luax_istype(L, 2, SOUND_SOUND_DATA_ID))
			t->queueBuffer(luax_totype<love::sound::SoundData>(L, 2, SOUND_SOUND_DATA_ID));
		else if (lua_isnumber(L, 3))
			t->queueBuffer(lua_touserdata(L, 2), (int)lua_tonumber(L, 3));
	});
}

[slime]

LuaJIT intentionally doesn't allow conversions from a FFI pointer to lightuserdata. The Lua C API can't be used to get FFI pointer data.

[raidho36]

So then what, we're shit out of luck with getting SoundSource to buffer from memory pointed by FFI pointer? I find it terribly inconsistent if it can load from a pointer obtained from some objects but not from others. I know that for ctype data, there's an 8 byte header followed by payload which contains the pointer in question, but again that's creeping into hacking territory.

Having that said, LÖVE never supported loading data from FFI buffers as far as I'm aware so if I remove that bit of [broken] functionality it's not gonna hurt. You will still be able to load data from SoundData objects, as well as by LUA pointer (i.e. lightuserdata).

[zorg]

i still don't get why you wanted to work with FFI (even as an option) when QueuableSource.lua already works through FFI, but your whole intent was to imlpement them without FFI. I'm confused.

[raidho36]

i still don't get why you wanted to work with FFI (even as an option) when QueuableSource.lua already works through FFI, but your whole intent was to imlpement them without FFI. I'm confused.

An actual framework implementation and QueuableSource.lua are not nearly the same, most notably that latter doesn't honors LOVE's approach to handling AL sources, and has no way to. I suggest you browse audio/openal/Source.cpp and Pool.cpp yourself just to appreciate the difference between what's a native feature and what's a hack. Don't get wrong idea, I'm not shitting on anyone or anything here - I myself have cranked out a specialized FFI AL implementation similar to that one - but it simply doesn't compares. So much in fact that I thought it's a better use of my effort to patch the whole framework module (I literally had to patch almost all files in there) than to work around that small limitation.

You insisted that I only use SoundData and not FFI pointers - and you win! LuaJIT doesn't provides a way to dig into its cdata objects, so that's just not meant to be.

To answer your question, I have a very specific use-case: libxmp, when playing modules, renders sound into its own buffers. In plain openal it's trivial to send these buffers directly to a source: you just tell AL to load whatever's at the pointer. But since it works via FFI, you get a cdata pointer when you ask for one. And since you work over a framework, it had to read the pointer from that cdata - which is not at all trivial and I suspect is discouraged. So now I have to memcpy from libxmp to SoundData before I can send it to queue, instead just doing it directly. Then again, it's the libxmp at fault, for not rendering into user-provided buffer and using its own instead.

[zorg]

raidho36: Okay, so i think i finally get what you are doing, so this post will probably contradict some of what i previously said.

An actual framework implementation and QueuableSource.lua are not nearly the same, most notably that latter doesn't honors LOVE's approach to handling AL sources, and has no way to.

It indeed doesn't implement most methods that Löve's own Source objects have. It's just a proof of concept for the microphone implementation (which is a proof-of-concept in itself... unless the creator wishes to contradict me on this.)

I suggest you browse audio/openal/Source.cpp and Pool.cpp yourself just to appreciate the difference between what's a native feature and what's a hack.

I'd call both two separate implementations, since neither resort to undocumented features or anything that i'd call hackish, then again, i just skimmed Löve's sources...

You insisted that I only use SoundData and not FFI pointers - and you win! LuaJIT doesn't provides a way to dig into its cdata objects, so that's just not meant to be.

I don't care about winning or not, i was just curious why you wanted to support them... for which i got the answer:

I have a very specific use-case: libxmp; when playing modules, renders sound into its own buffers.

Okay, so libxmp only renders modules... which libmodplug does as well, that Löve already includes. I'm guessing you have an issue with playback accuracy then? Careful, libOpenMPT is a contender for such things you know

In plain openal it's trivial to send these buffers directly to a source: you just tell AL to load whatever's at the pointer.

Yes, that's technically how QueuableSource.lua worked, by telling OpenAL to load the data through a SoundData's pointer.

But since it works via FFI, you get a cdata pointer when you ask for one. And since you work over a framework, it had to read the pointer from that cdata - which is not at all trivial and I suspect is discouraged. So now I have to memcpy from libxmp to SoundData before I can send it to queue, instead just doing it directly. Then again, it's the libxmp at fault, for not rendering into user-provided buffer and using its own instead.

Yeah, i get it. Well, still, an additional memcpy is still faster than if you had to copy values samplepoint-per-samplepoint, so it shouldn't be that slow.