Page 2 of 7
Re: "Questions that don't deserve their own thread" thread
Posted: Sat Oct 08, 2016 7:25 pm
by slime
raidho36 wrote: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.
Re: "Questions that don't deserve their own thread" thread
Posted: Sat Oct 08, 2016 7:53 pm
by 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!
Re: "Questions that don't deserve their own thread" thread
Posted: Sat Oct 08, 2016 8:03 pm
by 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.
Re: "Questions that don't deserve their own thread" thread
Posted: Sat Oct 08, 2016 8:37 pm
by raidho36
But soundData already is userdata, I don't see where you're going with this :^)
Re: "Questions that don't deserve their own thread" thread
Posted: Sat Oct 08, 2016 8:48 pm
by 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.
Re: "Questions that don't deserve their own thread" thread
Posted: Sat Oct 08, 2016 9:08 pm
by 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.
Re: "Questions that don't deserve their own thread" thread
Posted: Sat Oct 08, 2016 9:37 pm
by 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.
Re: "Questions that don't deserve their own thread" thread
Posted: Sat Oct 08, 2016 9:41 pm
by 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.
Re: "Questions that don't deserve their own thread" thread
Posted: Sun Oct 09, 2016 12:34 pm
by 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.
Re: "Questions that don't deserve their own thread" thread
Posted: Sun Oct 09, 2016 8:12 pm
by zorg
raidho36 wrote: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.