Author Topic: Performance regression in the latest version of BASSMIDI  (Read 1096 times)

Zenxia

  • Posts: 132
Here's an update that should get the note event processing performance back to the same as in BASSMIDI 2.4.12 (perhaps even a bit faster) while still optimizing duplicates:

   www.un4seen.com/stuff/bassmidi.zip

Let me know if it still seems slower in your tests.

About the idea of processing the events in batch, I can't do that because that would reduce the precision of the notes and introduce "choppiness" (Like when you use a really high buffer size in ASIO, 1024+).
I want the notes to be played as fast as possible, one by one, and using StreamEvent is the only way to achieve that.

I don't think it should affect precision if you don't wait to fill a batch. For example, if you use a 16 element BASS_MIDI_EVENT array to batch the events, but you only have 4 events to play, then you would just send those 4 events instead of waiting for 12 more. It probably won't make a massive difference but could be worth trying if you're ever bored :)
It is still noticeably slower, yeah...

I added the temporary ability to OM to switch DLLs on the fly, to compare the two in real-time.
Here's the video: https://www.youtube.com/watch?v=-DNr4swsWeI

Bassmidi blackmidi optimization maybe affect to normal midi ringtone/music playback.
« Last Edit: 7 Jul '21 - 12:25 by Zenxia »

Ian @ un4seen

  • Administrator
  • Posts: 23890
I tried the flag, and I hear no difference. ???

Did you definitely set the BASS_CONFIG_INUPDATE value in the same thread as the BASS_MIDI_StreamEvent calls? It's a thread-specific setting, so won't have any effect on those calls if set in a different thread. If you're unsure, you can use BASS_GetConfig to check the value before a BASS_MIDI_StreamEvent call.

It is still noticeably slower, yeah...

I added the temporary ability to OM to switch DLLs on the fly, to compare the two in real-time.
Here's the video: https://www.youtube.com/watch?v=-DNr4swsWeI

It may be useful to compare the "active voices" and "rendering time" numbers in each case but unfortunately they're very blurry in this video. I guess it's because the bitrate is too low for all of the action in the player's window. Can you use a higher bitrate, or perhaps move the player window so that the flashing is off screen?

Anyway, to try to narrow down what's causing the issue, please try these other 2.4.12.x versions and see which (if any) it happens with:

   www.un4seen.com/stuff/bassmidi.2.4.12.12.zip
   www.un4seen.com/stuff/bassmidi.2.4.12.17.zip
   www.un4seen.com/stuff/bassmidi.2.4.12.22.zip
   www.un4seen.com/stuff/bassmidi.2.4.12.25.zip
   www.un4seen.com/stuff/bassmidi.2.4.12.26.zip
   www.un4seen.com/stuff/bassmidi.2.4.12.29.zip

Please use the latest BASS version in all of the tests (including with BASSMIDI 2.4.12.10) to avoid adding an extra variable to the mix. Also confirm what BASS_ATTRIB_MIDI_CPU setting you're using (if any) and that it's the same in all of the tests.

bree

  • Posts: 230
I tried the flag, and I hear no difference. ???

Did you definitely set the BASS_CONFIG_INUPDATE value in the same thread as the BASS_MIDI_StreamEvent calls? It's a thread-specific setting, so won't have any effect on those calls if set in a different thread. If you're unsure, you can use BASS_GetConfig to check the value before a BASS_MIDI_StreamEvent call.
I clearly remember setting BASS_CONFIG_INUPDATE to 4 in any thread using StreamEvent, yes.

It is still noticeably slower, yeah...

I added the temporary ability to OM to switch DLLs on the fly, to compare the two in real-time.
Here's the video: https://www.youtube.com/watch?v=-DNr4swsWeI

It may be useful to compare the "active voices" and "rendering time" numbers in each case but unfortunately they're very blurry in this video. I guess it's because the bitrate is too low for all of the action in the player's window. Can you use a higher bitrate, or perhaps move the player window so that the flashing is off screen?

Anyway, to try to narrow down what's causing the issue, please try these other 2.4.12.x versions and see which (if any) it happens with:

   www.un4seen.com/stuff/bassmidi.2.4.12.12.zip
   www.un4seen.com/stuff/bassmidi.2.4.12.17.zip
   www.un4seen.com/stuff/bassmidi.2.4.12.22.zip
   www.un4seen.com/stuff/bassmidi.2.4.12.25.zip
   www.un4seen.com/stuff/bassmidi.2.4.12.26.zip
   www.un4seen.com/stuff/bassmidi.2.4.12.29.zip

Please use the latest BASS version in all of the tests (including with BASSMIDI 2.4.12.10) to avoid adding an extra variable to the mix. Also confirm what BASS_ATTRIB_MIDI_CPU setting you're using (if any) and that it's the same in all of the tests.
I will record at the highest bitrate, and upload all the videos to a Google Drive folder for you to see.
I'll begin testing each DLL now.

bree

  • Posts: 230
OK, I'm done testing the libraries!
Here's the Google Drive link: https://drive.google.com/file/d/1VEPWsiNdJaYB0CAlsWxZxdnoz_rR1r0i/view?usp=sharing

I tested the baseline twice (2.4.12.10), to make sure it wasn't just a fluke. :(

Ian @ un4seen

  • Administrator
  • Posts: 23890
If I'm hearing it right, it sounds like things got worse already in 2.4.12.12? If so, the main difference between 2.4.12.10 and 2.4.12.12 is that when there are no free voices, the former will only play a new note if it's louder than the quietest voice, while the latter will also play it if it matches the quietest, ie. new notes have priority over old ones. That extra checking shouldn't take much more time but I guess it all adds up when you have 1000s of new notes per tick and 1500 voices to check.

To confirm whether that is what's making the difference, here's an update for you to try that goes back to only playing louder notes:

   www.un4seen.com/stuff/bassmidi.zip

Let me know how it goes.

bree

  • Posts: 230
If I'm hearing it right, it sounds like things got worse already in 2.4.12.12? If so, the main difference between 2.4.12.10 and 2.4.12.12 is that when there are no free voices, the former will only play a new note if it's louder than the quietest voice, while the latter will also play it if it matches the quietest, ie. new notes have priority over old ones. That extra checking shouldn't take much more time but I guess it all adds up when you have 1000s of new notes per tick and 1500 voices to check.

To confirm whether that is what's making the difference, here's an update for you to try that goes back to only playing louder notes:

   www.un4seen.com/stuff/bassmidi.zip

Let me know how it goes.
This fixed the issue! Thank you!
You could make this switchable through a BASS_SetConfig flag.

Ian @ un4seen

  • Administrator
  • Posts: 23890
Great that mystery has been solved! Here now is another little update for you to try, with the quietest voice age checking re-enabled and tweaked a bit:

   www.un4seen.com/stuff/bassmidi.zip

Please let me know whether it still performs OK in your tests.

Zenxia

  • Posts: 132
nice Ian, i see better sound in lastest library that is step closer to timidity++ performance.
« Last Edit: 9 Jul '21 - 09:23 by Zenxia »

rv

  • Posts: 338
I think this optimisation was done because of the long release samples of the salamander.sfz piano that had priority over normal voices

bree

  • Posts: 230
Great that mystery has been solved! Here now is another little update for you to try, with the quietest voice age checking re-enabled and tweaked a bit:

   www.un4seen.com/stuff/bassmidi.zip

Please let me know whether it still performs OK in your tests.
It doesn't seem to perform as good as 2.4.12.10, missing some notes here and there, but it seems to work way better than 2.4.13.17!

I think this optimisation was done because of the long release samples of the salamander.sfz piano that had priority over normal voices
Yeah this is why I asked if this behavior could be changed with a flag in BASS_SetConfig, I don't want my optimization request to interfere with other stuff. :-\

Ian @ un4seen

  • Administrator
  • Posts: 23890
Here's another little tweak for you to try:

   www.un4seen.com/stuff/bassmidi.zip

If it still doesn't match 2.4.12.10, is it better than 2.4.13.18? (the first update I posted in this thread)

bree

  • Posts: 230
Here's another little tweak for you to try:

   www.un4seen.com/stuff/bassmidi.zip

If it still doesn't match 2.4.12.10, is it better than 2.4.13.18? (the first update I posted in this thread)
I can't find 2.4.13.18 in my downloads folder (might have cleaned it, ouch), but it seems to score slightly more notes than .21.
It still can't match 2.4.12.10 at more than 1000 voices though... But it's not a big deal I guess. This is still 20 times better than before! ;D

Zenxia

  • Posts: 132
Here's an update that should get the note event processing performance back to the same as in BASSMIDI 2.4.12 (perhaps even a bit faster) while still optimizing duplicates:

   www.un4seen.com/stuff/bassmidi.zip

Let me know if it still seems slower in your tests.

About the idea of processing the events in batch, I can't do that because that would reduce the precision of the notes and introduce "choppiness" (Like when you use a really high buffer size in ASIO, 1024+).
I want the notes to be played as fast as possible, one by one, and using StreamEvent is the only way to achieve that.

I don't think it should affect precision if you don't wait to fill a batch. For example, if you use a 16 element BASS_MIDI_EVENT array to batch the events, but you only have 4 events to play, then you would just send those 4 events instead of waiting for 12 more. It probably won't make a massive difference but could be worth trying if you're ever bored :)
It is still noticeably slower, yeah...

I added the temporary ability to OM to switch DLLs on the fly, to compare the two in real-time.
Here's the video: https://www.youtube.com/watch?v=-DNr4swsWeI

You have problem with any normal midi?

Ian @ un4seen

  • Administrator
  • Posts: 23890
It seems to be happening randomly, and replacing BASS with the original "Black MIDI proof" version doesn't seem to fix it, so I guess it's something wrong inside BASSMIDI.

Just to be sure, are you referring to the sound/notes issue that you reported in this thread or the heap corruption that the Chikara dev reported? In either case, to narrow it down further, please try the BASSMIDI 2.4.13 release version and see if it happens with that too.
Yeah I was talking about the heap corruption issue, it does not happen with 2.4.13.

I forgot to ask earlier, is the Chikara dev still having that problem with the latest BASSMIDI 2.4.13.22 update?
« Last Edit: 26 Jul '21 - 13:03 by Ian @ un4seen »

bree

  • Posts: 230
It seems to be happening randomly, and replacing BASS with the original "Black MIDI proof" version doesn't seem to fix it, so I guess it's something wrong inside BASSMIDI.

Just to be sure, are you referring to the sound/notes issue that you reported in this thread or the heap corruption that the Chikara dev reported? In either case, to narrow it down further, please try the BASSMIDI 2.4.13 release version and see if it happens with that too.
Yeah I was talking about the heap corruption issue, it does not happen with 2.4.13.

I forgot to ask earlier, is the Chikara dev still having that problem with the latest BASSMIDI 2.4.13.22 update?
He still had some problems, the only fix was to increase the heap size in the MIDI driver.
Downgrading to version 2.4.12.10 of BASSMIDI doesn't require me to increase the heap size, weirdly enough.

Ian @ un4seen

  • Administrator
  • Posts: 23890
He still had some problems, the only fix was to increase the heap size in the MIDI driver.
Downgrading to version 2.4.12.10 of BASSMIDI doesn't require me to increase the heap size, weirdly enough.

That sounds strange. Do you mean the /HEAP linker option? I believe that only has effect in an EXE (not a DLL), but your driver is a DLL? Were you able to reproduce the problem yourself, and if so, was it happening in a particular function call?
« Last Edit: 26 Jul '21 - 13:03 by Ian @ un4seen »

bree

  • Posts: 230
He still had some problems, the only fix was to increase the heap size in the MIDI driver.
Downgrading to version 2.4.12.10 of BASSMIDI doesn't require me to increase the heap size, weirdly enough.

That sounds strange. Do you mean the /HEAP linker option? I believe that only has effect in an EXE (not a DLL), but your driver is a DLL? Were you able to reproduce the problem yourself, and if so, was it happening in a particular function call?
The driver is statically linked, so every memory-related call is handled by its own internal runtime, and not by the host application.
That's why changing the heap does affect the driver.

And honestly I don't know, it seems to be pretty random. Maybe the latest version of BASSMIDI uses more memory than before?
Anyway, increasing the heap fixed it so it's not a big deal.