Source:tell on queueable sources

[pgimeno]

I'm trying to make a <2 frame latency audio buffering system, but I'm running into a problem.

My idea was to aim for one buffer per frame, preparing the next buffer's size with just enough data as for it to finish at about when the current frame is predicted to end, plus some extra time to account for frame time variations. To do that:

- I measure the last frame's duration, and assume that the next frame will take approximately the same time (I'm aware this may cause issues if there are micro-stutters, that's not the problem).
- I try to check how many samples are still left to play in the current buffer, in order to account for that time.

The second part is where I'm having issues. The number of samples left to play should equal the playing buffer's size minus the current play position, as reported by Source:tell("samples"). But it turns out that Source:tell is returning 0 every time, and that's screwing up the method, because it always thinks there's still one whole buffer (i.e. about one frame) worth of time to play.

Is that how Source:tell() is supposed to work? The docs say that "[w]ith the queueable source type, this method returns a value based only on the currently playing buffer". That doesn't mean it returns 0, right?

I can think of an alternative, using fixed-length short buffers as quantized time marks, where the number of buffers left in the queue will tell me the approximate duration left to play, but that seems like a somewhat dirty approach, and the limit is 64 buffers total, which makes things a little bit difficult.

[RNavega]

Hi. I don't think that's what the queueable sources are meant to be used for, anyhow. That is, querying information back from them. I see them the same as a streamed source, but managed by the user.
Like a fire-and-forget: you fill (one of the) buffers and queue it to play and then trust that it'll be played as soon as possible.

Since we define the queueable source's samplerate, we know how much time it'll take for that source to consume N samples. So we fill the buffer with as many samples as needed to play for the duration of 2 frames (given the framerate of your LÖVE program), but from what you're saying, you can't verify if it actually took 2 frames to play it. You just need to keep filling the buffers with 2-frames-worth of sound data and queueing them, and hope that it's working.

[zorg]

With queueable sources, Source:tell might be returning 0 due to how short your buffers are; By the time it queries the data, the frame got queued and played completely, and so it returns zero since the playback stopped due to the source running out of unplayed samples or unplayed buffers as well).

Still, from what i remember, :tell is affected by the 50 ms default OALS latency config, so if you have less than that as the buffer size, then you can't really use that function for such purposes.

In any case, some quick maths from me; assuming your sound data has 48 kHz sampling rate, and you want to aim for 60 FPS, then division gives you 800 audio samplepoints per frame, which translates to 1.25 ms per frame... way less than 50 ms.

About the buffer count limit, for a second of audio, 60 would be enough with the above calculations.

[pgimeno]

Still, from what i remember, :tell is affected by the 50 ms default OALS latency config, so if you have less than that as the buffer size, then you can't really use that function for such purposes.

Oh, that might be it, thank you!