Author Topic: Potential play back timing issue  (Read 346 times)

Chris Oakley

  • Posts: 201
Potential play back timing issue
« on: 28 Jul '22 - 19:05 »
Hi, I'm not sure if I'm missing something, but is there a possible scenario that an audio file could play back ever so slightly slower so that if you timed it against a stopwatch it would show that the file, despite saying it was 3 minutes long, would actually be 3 minutes and 100 milliseconds?

I know this is an odd question but I'm trying to figure out why a bunch of 30 files, when I play them back to back, play for longer than the calculated run time by around 10 seconds.

I get the length of each file from BASS itself and add that together. The code that goes from one file to another on playback has no lag, and even if it did, to get a gain of 10 seconds, it would be a noticeable lag.

I've thought about variable bit rate files and tested with CBRs to make sure but that makes no difference.

Could it be something in the audio drivers, the buffer, the audio clock, or is it just something really obvious that I could be missing?

It is almost like the files physically play back a little longer than they should, to the point you wouldn't audibly hear it, but en masse it become apparant.

Ian @ un4seen

  • Administrator
  • Posts: 24589
Re: Potential play back timing issue
« Reply #1 on: 29 Jul '22 - 14:13 »
It is possible that a soundcard will output at slightly off the specified rate but I don't think it should get as far off as you describe, eg. 100ms in 3 mins. Is that happening with all files (including WAV) or only particular files?

When playing the 30 files back to back, how are you ensuring that there's no gap between them, eg. are you using a mixer? If you're playing them as individual streams via BASS_ChannelPlay then there could be small delays/gaps introduced by that. If you are using a mixer then you could try setting a WAV writer on it (via BASS_Encode_Start with BASS_ENCODE_PCM) to confirm the total length and check for any gaps in a sample editor.

Chris Oakley

  • Posts: 201
Re: Potential play back timing issue
« Reply #2 on: 29 Jul '22 - 15:20 »
The current test is using Flac files.

What I do is start with a date and time then take the files, see how long each one is and add the milliseconds to the start date time. With each file this then gives you when each one would start. What happens though is as the play goes on something that should start at say 00:30:12 is started at 00:30:13. This then has a knock on effect with the rest of the times and you end up with later files that should play at 00:40:00 for example starting at 00:40:02 and so on.

It's like a really slow build up, but the code that determines when to play the next file is instant, no delay, certainly not one that would cause this sort of build up.

There is a mixer involved, but we've seen this without using a mixer and playing files direct to a device.

We've even got instances where the total runtime ends up being less, not more, than calculated which is why I'm starting to think it could be hardware / driver related, and what I can do to either stop it or mitigate this.

Ian @ un4seen

  • Administrator
  • Posts: 24589
Re: Potential play back timing issue
« Reply #3 on: 1 Aug '22 - 13:16 »
To confirm whether the issue is hardware-related, can you run the same tests on another system and/or soundcard?

Also, here's a BASSmix update (prerelease of the upcoming BASSmix 2.4.12) for you to try, with a couple of new features that I think could help simplify your code (and perhaps in doing so remove problems):

   www.un4seen.com/stuff/bassmix.zip

It adds a new BASS_MIXER_QUEUE flag to create a queued mixer, which plays its sources one after another gaplessly. It also adds support for mixer length retrieval based on the mixer's current sources. For example, to play a bunch of files in sequence and get the total length, you could do something like this:

Code: [Select]
mixer = BASS_Mixer_StreamCreate(freq, chans, BASS_MIXER_QUEUE | BASS_MIXER_END); // create a queued mixer
for (int n = 0; n < files; n++) {
decoder = BASS_StreamCreateFile(false, filenames[n], 0, 0, BASS_STREAM_DECODE | BASS_STREAM_PRESCAN); // open n'th file
BASS_Mixer_StreamAddChannel(mixer, decoder, BASS_STREAM_AUTOFREE); // plug it into the mixer
}
estlength = BASS_ChannelGetLength(mixer, BASS_POS_BYTE); // get a total length estimate
BASS_ChannelPlay(mixer, false); // start playing

while (BASS_ChannelIsActive(mixer)) Sleep(100); // wait for playback to finish

finlength = BASS_ChannelGetPosition(mixer, BASS_POS_BYTE); // get the actual total length

Check that the "estlength" and "finlength" values match, and that they match what you calculated for the same files in your old test, and check if playback actually took that long.

From your previous posts, it looks like you're using BASS.Net with VB.Net. If so, I think you can access the new BASS_MIXER_QUEUE flag like this:

Code: [Select]
mixer = BassMix.BASS_Mixer_StreamCreate(freq, chans, CType(&H8000, BASSFlag) Or BASSFlag.BASS_MIXER_END) ' create a queued mixer (&H8000 = BASS_MIXER_QUEUE)

Chris Oakley

  • Posts: 201
Re: Potential play back timing issue
« Reply #4 on: 2 Aug '22 - 12:43 »
Thanks Ian, I'll give this a go with the timing to see what's happening. Interesting the new flag too.