Author Topic: WPF application callbacks might block BASS and cause sampling  (Read 100 times)

CvMaRTY

  • Posts: 14
Hi there,
I host a very large WPF application with a lot of windows/classes/controls etc. It is quite big. Its main purpose though is playing audio (using bass+bass.net). My problems started though when I needed to introduce callbacks into the program, for using ASIO or use the DSP_PeakLevelMeter Class (generally whatever would need a callback in managed code).  If for some reason, the garbage collector is called, this might cause an application wide (all threads) stop of 80 to 190ms. This application-wide pause might also be introduced when loading (or unloading) a very heavy window (with controls/grids/graphics etc). So in this 80-190ms pause of the app, i will have sampling/stuttering of the audio - ONLY if a callback is beeing used. This is because I suppose that the garbage collector pauses everything application wide and this means that delegate procs also pause on this matter - blocking BASS from continuing its work. When using only bass working by its own threads, this is not an issue. So how can I be able to do my DSP processing or send to my ASIO without being afraid that a garbage collector or an exception (yes an exception-even handled one can cause application wide pauses too - especially in large applications - or WPF binding issues etc) wont block the playback of bass even for some milliseconds leading to a playback catastrophe?

Until now, the only thing I found was someone suggesting making this work in an unmanaged c++ dll with support to managed code and referencing it to the .net application, and handling callback stuff. Another approach is making a service or a different lightweight exe and intercommunicating with the main program and doing all the playback work. As the biggest problem here is WPF that makes the GC so heavy to work, but I find this very prone to other problems, and needing to re-write alot of stuff, setting aside all the intercommunication problems back and forth...

Any suggestions?

radio42

  • Posts: 4574
The only fully reliable solution is to either increase the buffer (so that the GC run finishes within the time the buffer is good for; but this increases the latency of course) or to use a mixed mode assembly.
Please see these 2 posts on explaining it:
http://www.un4seen.com/forum/?topic=4932.msg60318#msg60318

http://www.un4seen.com/forum/?topic=4932.msg60399#msg60399

CvMaRTY

  • Posts: 14
radio42 thanks, for the prompt reply,
the description in your linked post was exactly my problem,

although I have no experience in c++, in less than an hour I managed compiling, referencing and testing the example you expose successfully. Although this means that I will have to make all the auto stuff BassAsioHandler does in the c++ section. This will take some time until I figure out some things you automatically do in BassAsioHandler. It would be appreciated if I had some more abstract examples of this stuff especially in the unmanaged section.

radio42

  • Posts: 4574
I am afraid, that my time is too limited to come up with a concrete and complete BassAsioHandler wrapper as a mixed mode assembly... but may be someone here in the comunity might jump in?