SoundQueues

[slime]

As I said elsewhere, I have problem navigating the source. Which files would be the relevant ones?

Source.cpp in modules/audio/openal/ contains most of the OpenAL-specific code for Sources (including streaming in buffer data). The modules/audio/ folder in general contains things like the Source API interface and its Lua bindings as well.

modules/sound/lullaby/ contains the Decoder implementations for various file types / library dependencies. The containing modules/sound/ folder also has the Decoder and SoundData interfaces and Lua binding code.

[raidho36]

OK thank you. I can already see the solution sorta kinda. My c++ has gotten so rusty, I couldn't tell what the code was supposed to be doing without consulting the manual lol!

So basic idea is to overload source constructor to accept audio format description and initialize otherwise blank state, make a function that manually feeds data (userdata) into the source and expose to LUA. There will probably be need for a function that tells number of buffered samples and so on.

I'll get to it once I get home... And get some sleep!

[zorg]

raidho36: You can also look at the lua file i linked before, for ideas.
Also, i do hope you meant SoundData when you said (userdata); there's no reason not to use them.

Edit: Also here: one and two example implementations of a "device" based on the above mentioned lua file... that i've yet to release since i'm curretnly working on a demo/showcase app for it. Feel free to use ideas from them.

[raidho36]

But soundData already is userdata, I don't see where you're going with this :^)

[zorg]

Yes, SoundData is a type of userdata, but any kind of userdata is not always a SoundData.
I'm just saiyan, it'd probably be easier to go with only supporting what's already implemented, instead of supporting arbitrary userdata as input.

[raidho36]

If you got userdata you can put it into audio source, but having to convert your raw buffers to soundData instead of directly feeding it into source doesn't strike me as efficient or even sensible thing to do.

[zorg]

Have you even opened up the examples or the lib chunk i posted?
Also, why would you use raw buffers if you can accomplish the same things with SoundDatas?
- you can get a pointer to the data, hence directly manipulate the samplepoints -> fast.
- löve already uses SD as a buffer type of deal, why not reuse?
- it encapsulates needed data like number of samplepoints, sampling rate, bit depth, channels, etc. extremely useful.
- While OpenAL does expect a simple array of values, as i said before, look here:

Code: Select all

-- https://github.com/LPGhatguy/love-microphone/blob/master/love-microphone/QueueableSource.lua#L126
function QueueableSource:queue(data)
	self:step()
	if (#self._freeBuffers == 0) then
		return nil, "No free buffers were available to playback the given audio."
	end
	local top = table.remove(self._freeBuffers, 1)
	al.alBufferData(top, getALFormat(data), data:getPointer(), data:getSize(), data:getSampleRate())
	al.alSourceQueueBuffers(self._source, 1, ffi.new("ALuint[1]", top))
end

OAL itself copies over the array through a SoundData's pointer.

[raidho36]

As I said, you do that if you already have a soundData object. If you don't have one, but you got a filled buffer, then that's one extra memory copying operation that wasn't necessary to do, plus doing work of assigning all the values that are already assumed to be like that in the target audioSource anyway.

Also, as per OpenAL specs, if alSource has more than one buffer they must all share same format, so that really is just not necessary.

[raidho36]

OK so I had some decent progress with this, added a "queue" type source (also added buffer tracking for stream mode); there's a bunch of off by one errors to solve and as of now streaming AL sources segfault quickly (errors cause buffering routine to read garbage) but I'll get around it once I get back home.

/blogpost

Just to let you know I'm actually working on it and having success with it.

[zorg]

OK so I had some decent progress with this, added a "queue" type source (also added buffer tracking for stream mode); there's a bunch of off by one errors to solve and as of now streaming AL sources segfault quickly (errors cause buffering routine to read garbage) but I'll get around it once I get back home.
/blogpost
Just to let you know I'm actually working on it and having success with it.

Well, don't let my salt ruin your efforts! Do tell when there's an example i could test with, am curious how it compares to the FFI implementation i'm currently using.