Topic: BASS_Mixer_ChannelGetPosition reporting incorrect time at a single moment

[Salman Ahmed]

Hello,

I'm a developer in osu!(lazer), and for some time now we've been repeatedly seeing reports of what is essentially BASS reporting incorrect time from the mixer for a single moment/frame.

To be more specific, we have a mixer and we add a stream to it, then we call BASS_Mixer_ChannelGetPosition every frame to know at which point are we in the mixer/stream, then, at a very random occurrence, the mixer reports a time that is roughly 11-12 seconds backwards from the current time for only a single frame.

Here's a snippet from our logs showing this:

Code: [Select]

2024-08-08 16:34:47 [verbose]: TrackBass.UpdateState(): current time = 99776.35416666666
2024-08-08 16:34:47 [verbose]: TrackBass.UpdateState(): current time = 99777.52083333333
2024-08-08 16:34:47 [verbose]: TrackBass.UpdateState(): current time = 88916.60416666667
2024-08-08 16:34:47 [verbose]: TrackBass.UpdateState(): current time = 99779.85416666667
2024-08-08 16:34:47 [verbose]: TrackBass.UpdateState(): current time = 99781.02083333333


[Ian @ un4seen]

That's strange. Please confirm what platform that's on, and what BASS and BASSmix versions you're currently using (with BASS_GetVersion and BASS_Mixer_GetVersion). And then also give these latest builds a try (if Windows) and see if you still have the problem with them:

   www.un4seen.com/stuff/bass.zip
   www.un4seen.com/stuff/bassmix.zip

[Salman Ahmed]

• We've been seeing this across Windows, macOS, Linux, and Android.
• We're using BASS 2.4.17.0 and BASSmix 2.4.12.0. In case it's helpful, we also apply BASS_FX_TempoCreate and BASS_FX_ReverseCreate on top of the stream we play.
• It's hard for me to test on Windows, am I able to use https://www.un4seen.com/stuff/bass-osx.zip and https://www.un4seen.com/stuff/bassmix-osx.zip to test on macOS instead? I'll give those a try anyway.

[Ian @ un4seen]

Yes, you can get the latest macOS builds at those URLs. BASSmix wasn't available but I have added that now too. There's also a BASS_FX update that you can try:

   www.un4seen.com/stuff/bass_fx-osx.zip

Please see if the problem still happens when using them. If it does, to narrow it down, can you try disabling the BASS_FX stuff (ie. skip BASS_FX_TempoCreate and BASS_FX_ReverseCreate) to see if it still happens then?

[ppy]

Reporting back on Salman's behalf that we are now on the beta version but still seeing this issue occur. We have not yet tried bypassing `BASS_FX` streams yet, so consider this an intermediate update.

[Ian @ un4seen]

When you tried the beta version(s), did that include the BASS_FX build above, as well as the BASS and BASSmix builds? I ask because the BASS_FX update does include some position reporting/syncing changes.

[ppy]

Sorry it turns out we didn't properly include the DLLs in the last update >_<.

We'll try again and report back.

[ppy]

After updating to the beta versions we're seeing unexpected shifts in reported time which result in very weird issues (like time jittering after seeks). I haven't yet had a chance to investigate further, nor check whether – ignoring this – our original issue has improved or not, but due to the new issues we can't easily deploy this to a larger user-base for testing.

Sorry to not provide more specifics, just a heads up to let you know that things are weird.

[Ian @ un4seen]

That doesn't sound good. To narrow down where the problem is, would it be possible to try disabling the BASS_FX tempo and reverse stuff, and see if it still happens then? Please also confirm whether BASSmix splitters (BASS_Split_StreamCreate) are involved, or only mixers (BASS_Mixer_StreamCreate)?

[Wieku]

Hi! I think it may be indeed BASS_FX at fault.

Recently I got some reports that seeking is broken with .ogg files (seeking during the silent portion was desyncing playback and getposition, basically get position was counting from requested seek but playback always started after the silence). I decided to check if new BASS version (was using 2.4.16.1, mix 2.4.10 and fx 2.4.12.1) fixes it and it does! But, at the same time, I started getting the same time issue as ppy mentions.

Current versions:

Code: [Select]

BASS Version:        2.4.17.38
BASS FX Version:     2.4.12.11
BASS Mix Version:    2.4.12.4

I've removed bass_fx from the pipeline and after 10 tests on a 40s ogg I didn't encounter a single backwards time report.

As another step, I decided to downgrade bass_fx to the version I had before (2.4.12.1) and the issue still seems to be fixed.

Given that osu! uses bass_fx 2.4.12.6 it seems that something broke between .1 and .6

[Ian @ un4seen]

Interesting. Is the reported position (from BASS_Mixer_ChannelGetPosition?) actually going backwards sometimes or is it just not advancing at the expected/consistent rate? And did you have tempo and reverse effects set at the time? If so, could you repeat your tests with only the reverse effect set, and again with only the tempo effect set, to identify which is causing the problem?

The tempo effect processes its source at a slightly variable rate, and the BASS_FX update tries to take consideration of that to give the exact position that's currently being heard, while I believe the previous versions gave a more consistent but possible inaccurate position. So this may explain the position not advancing at the expected rate, if that is the issue you're having. It's also possible there's a bug in it if the position is actually going backwards without the reverse effect enabled.

[Wieku]

In my case I'm not using the reverse stream. Tempo and pitch were set to default values so it was a base stream being played with BASSFX:

channel := C.BASS_StreamCreateFile(0, unsafe.Pointer(&wFile[0]), 0, 0, C.DWORD(C.BASS_STREAM_DECODE|C.BASS_STREAM_PRESCAN|C.BASS_UNICODE))
channel = C.BASS_FX_TempoCreate(channel, C.BASS_FX_FREESOURCE|C.BASS_STREAM_DECODE)

C.BASS_ChannelSetAttribute(channel, C.BASS_ATTRIB_TEMPO_OPTION_USE_QUICKALGO, 1)
C.BASS_ChannelSetAttribute(channel, C.BASS_ATTRIB_TEMPO_OPTION_OVERLAP_MS, C.float(4.0))
C.BASS_ChannelSetAttribute(channel, C.BASS_ATTRIB_TEMPO_OPTION_SEQUENCE_MS, C.float(30.0))

C.BASS_Mixer_StreamAddChannel(masterMixer, channel, C.BASS_MIXER_CHAN_NORAMPIN|C.BASS_MIXER_CHAN_BUFFER)

C.BASS_ChannelSetAttribute(channel, C.BASS_ATTRIB_TEMPO, C.float(0))
C.BASS_ChannelSetAttribute(channel, C.BASS_ATTRIB_TEMPO_PITCH, C.float(0))

var freq C.float
C.BASS_ChannelGetAttribute(player.channel, C.BASS_ATTRIB_FREQ, &freq)

//In update loop:

pos := float64(C.BASS_ChannelBytes2Seconds(channel, C.BASS_Mixer_ChannelGetPosition(channel, C.BASS_POS_BYTE)))

C.BASS_Mixer_ChannelGetData(channel, unsafe.Pointer(&fft[0]), C.BASS_DATA_FFT1024)
C.BASS_ChannelSetAttribute(channel, C.BASS_ATTRIB_TEMPO, C.float(0)) // dynamic value, 0 during the test
C.BASS_ChannelSetAttribute(channel, C.BASS_ATTRIB_TEMPO_PITCH, C.float(0)) // dynamic value, 0 during the test
C.BASS_ChannelSetAttribute(channel, C.BASS_ATTRIB_FREQ, C.float(1 * freq)) // dynamic value, freq during the test

Yes, it is actually going backwards:

BACKWARDS! Old pos: 20015.729166666668 new pos: 9200
JUMP! Old pos: 9200 new pos: 20016.145833333332

2 readings were made ~300us from each other.

[Ian @ un4seen]

Ah! I think see what's causing the problem now. Here's a BASS_FX update for you to try:

   www.un4seen.com/stuff/bass_fx.zip

Let me know if you still see the problem happening with that, or if you need it for a different platform.