declares and callbacks on windows OS

General
1

Hi,
I’m developing a sort of internet radio application, using bass libraries.
It essentially plays a list of audio files, converting them in mp3 128 Kb, and send the stream to an icecast server
All is working fine on OS X, but i need a Windows version too, but I’m blocked on a callback issue:
Now, when playing a BASS channel ( a file opened and streamed), you can set a ‘SYNC’ for it, that’s a way to call a method when an event occurs ( in my case, when a file has finished playing ), something like this:

synccorrente2 = BASS_ChannelSetSync(audiocorrente2, BASS_SYNC_END, 0, AddressOf aggiungiPlayer1, 0)

as I said in OS X it works, and my method ( aggiungiPlayer1 ) is called, and after an audio has finished I can start the next, but on windows the app simply crashes.

in my method I have put at the beginning

#Pragma X86CallingConvention StdCall
#pragma stackOverflowChecking false
#pragma DisableBackgroundTasks

I have removed all the code from it ( now it simply sets a global variable, and a timer takes care to start the following audio )

I have moved it from a module method to a window method, but no success… it crashes on windows, the first audio file starts playing and the streaming to icecast works fine, but when it finishes it crashes…

any suggestions?

I have seen an old post about a similar problem, but it seems without solutions, somebody was talking about postin a message to the window using windows declares, but I have not clear how to do it…

Should external dll callbacks work on windows or not?

thanks,

 Giulio
2

Hi Giulio,
from what you are reporting the library create threads that executes independently from Xojo.

I’m unable able to get an “asynchronous” callback in Xojo.
I don’t know how different are the implementation details between OS X and Windows.
I suspect that the fundamental single thread execution model it is the root cause of the problem.
You get a framework unable to perform async execution of Xojo code (at least on Windows) but we don’t have anything to “get in sync” with the framework.

I hope that someone may help us: maybe a solution exist.

Regards.

3

Grazie Maurizio, thanks for your reply.
It would be such a shame don’t being able to use such such useful externals on Windows, and all the things makes me worry that some kind of unpredictable problem could occur also on Mac ( didn’t do an extensive testing on it, letting it play for a long long time )

I’m still exploring for windows the possibility to use another declare to send a message to the window, in such case it shouldn’t be xojo code executed on the callback function, I hope…

G
4

Are you sure the aggiungiPlayer1 prototype is completely correct? The Xojo app is 32-bit but perhaps whats being sent back are 64-bit integers, if you are running 64-bit Windows and the bass libraries are doing 64-bit and that’s the way they work.

Just a thought - I do think the threading thing is more likely the answer. With audio often there is threading involved and I can’t see why this would be any different.

5

Hi Dough,
in reality the callback method isn’t receiving nothing, when it is called is simply a notification that the current playing song is finished, then the app simply chooses the next file and plays it

thanks

 Giulio
6

Up to now I have done a thing that seems complicated but, for my knowledge, it is what I considered a viable solution.

The notification gets redirected to an custom made dll that notify to the application using a socket.
This way the application does not need to do polling and the notification get received “asynchronously” by the app.

Again, it seems complicated but I’m not aware of other solutions.

Regards.

7

Hi Maurizio,
your solution seems really interesting if it takes a more stable approach to all this stuff…
shame on me, but I have just discovered some code I have written and forgotten about more than a year ago, always on bass libraries, and it seems that I did already use some callbacks, and it seems they are actually working on windows too, ( at a fast test, don’t know if anyway they could give some problem randomly )
I’ digging more to discover why on this new code I have always a crash…

8

Callback methods cannot be normal class methods. They must either be global methods (i.e. in a module) or shared class methods. Basically, callback methods must never go out of scope and never be moved to a different memory location, which is pretty good description for shared and global (module) methods.

9

Hi Andrew,
I’m effectively using global methods in a module.
But I’m beginning to believe that the problem is more related to the DLL itself, because using its callbacks in a different way I haveno crashes, at least not at a fast test…