Track position not respecting time scale DSP

[SKProCH]

Since lavaplayer now maintained by lavalink team I thought that reopen this issue on this repo is a good idea.

Problem description

Lavalink is a standalone audio sending node based on Lavaplayer and JDA-Audio. Bot developers can play audio using distributed lavalink nodes across different programming languages and bot frameworks.

Lavalink reports a state for each player about every five seconds, containing the current UNIX timestamp when the player update was created and a relative track position. Based on this information, the track's position can be computed. As lavaplayer now has a timescale filter, it is possible to alter the track speed and rate. The position of the track reported by lavaplayer does not respect the actual speed of the track. Calculating the position of the track on the client-side would be possible but would come with a higher error rate because of network latencies, filter jitter (the client does not know the exact time when the filter becomes active), ... (There are some times where the client has to interpolate the position of the track, which corresponds to the time difference between the current host machine time and the time of the last update, which error rate should be ignorable [e.g., errors because of different clock times due to NTP synchronization errors]).

The client state is generated in Lavalink, which you can see at the following: https://github.com/freyacodes/Lavalink/blob/85a54966218094bc06a4f1506003c55523462b04/LavalinkServer/src/main/java/lavalink/server/player/Player.java#L131 There you can see a call to lavaplayer, which requests the current track position.

When using the timescale filter, lavaplayer reports a wrong track position (it uses the position as if the timescale filter has not been applied).

Proposal

I would propose that the code for calculating/tracking the track position should be fitted to report a correct track position.

Additional info

All additional info can be found here: https://github.com/sedmelluq/lavaplayer/issues/667

[devoxin]

I don't think this is fixable without a major refactor. Timescale works by altering the sample rate, which Lavaplayer would need to be aware of "further up the chain" to correctly calculate the position. The way it works currently is by using the declared sample rate of the track.

I'll leave the issue open for the time being to avoid duplicate issues, but this most likely won't be fixed any time soon.

[SKProCH]

Yes, I tried to look at the code and think what could be done with it.

I think that since we know the declared sample rate and the "current sample number", then from this information we can calculate the correct current position in the track at least?

[devoxin]

Lavaplayer isn't really "aware" of filters applied to it. It can make a few assumptions based on what details are provided in the filter interfaces but there's no setter or facility to allow notifying Lavaplayer of the updated sample rate so this isn't really feasible. It would need a large internal refactor to facilitate these changes

[SKProCH]

No, I'm not talking about telling lavaplayer information about filters, I mean something a little different.

Lavaplayer initially knows the default sample rate of the track, for example 48,000 Hz. Those, per second it will give 48000 samples (in chunks actually, but anyway). But if we apply, for example, a 1.5x speed filter, actual output sample rate will increase to 72000 samples. Those. in theory, based on how many samples it sent from the beginning of the track and knowing the initial sampling rate, lavaplayer can at any time calculate how much time has passed since the beginning of the track including applied filters (i.e. the current position). Yes, in fact, he doesn’t really know at what speed (and with which filers) the track is currently being played, but at least he can find out what the current playback position is.

Also, probably, if initial sample rate is known, and actual outputting sample rate is also known, lavaplayer can determine approximate speed of current track playing. Actually this is not ideal, i understand this, so even if lavaplayer can give out a proper info about track position (based on number of samples outputted) it already will be fine.

Also, i want notice, I don't know much about this and I may be talking complete nonsense, so please don't take it too seriously.

[devoxin]

lavaplayer can at any time calculate how much time has passed since the beginning of the track including applied filters

No, I'm not talking about telling lavaplayer information about filters

And how do you propose we do that if we can't tell Lavaplayer about those filters? Timescale is not built into Lavaplayer so it cannot be aware of it more than what the base Filter interface allows. There is also no provision to allow filters to update the sampling rate within Lavaplayer.

Therefore,

but at least he can find out what the current playback position is.

this is not possible.