API issue: _status not updating, callback not running?
Posted: Fri May 14, 2010 4:35 pmHi,
I've been struggling with some strange behavior in the swift engine. I am calling the API functions from a custom C program. The program works fine most of the time, but once in a while I observe the following symptoms:
* user callback isn't run on events. It is run once, immediately after I call swift_port_set_callback(), with event type 'start', but isn't called again for the duration of the synthesis. Event mask is "~SWIFT_EVENT_AUDIO".
* swift_port_status() doesn't update (I have tried passing it the stored backgroundID, as well as SWIFT_ASYNC_CURRENT, and SWIFT_ASYNC_ANY - in every case, it continues to return SWIFT_STATUS_RUNNING after the job is done.)
I know the job runs because I get audio output, but as far as the API will tell me, it hasn't finished. This problem only occurs sporadically; since the user program is being called from a Linux startup script, I suspect there may be some sort of race condition occurring here, but I'm having trouble getting any more insight into what's causing the engine to misbehave like this.
Any suggestions would be greatly appreciated, I've been beating my head against this for weeks now...
I've been struggling with some strange behavior in the swift engine. I am calling the API functions from a custom C program. The program works fine most of the time, but once in a while I observe the following symptoms:
* user callback isn't run on events. It is run once, immediately after I call swift_port_set_callback(), with event type 'start', but isn't called again for the duration of the synthesis. Event mask is "~SWIFT_EVENT_AUDIO".
* swift_port_status() doesn't update (I have tried passing it the stored backgroundID, as well as SWIFT_ASYNC_CURRENT, and SWIFT_ASYNC_ANY - in every case, it continues to return SWIFT_STATUS_RUNNING after the job is done.)
I know the job runs because I get audio output, but as far as the API will tell me, it hasn't finished. This problem only occurs sporadically; since the user program is being called from a Linux startup script, I suspect there may be some sort of race condition occurring here, but I'm having trouble getting any more insight into what's causing the engine to misbehave like this.
Any suggestions would be greatly appreciated, I've been beating my head against this for weeks now...