The plugin that I'm creating seems to return too quickly. I have a simple test that plays a sine wave and waits 5 seconds (using usleep). The problem is that it stops the sine wave and returns in about a half a second (I hear the sine wave but just a blip. And no errors from the external code.) The code works fine outside of Squeak, but not called from Squeak.
The plugin does 2 simple things: * Starts a stream that calls a callback routine (below) * The callback fills a buffer for the sine wave data and then returns After waiting 5secs, the main line cleans up and exits.
Are there any particular issues with callbacks in Squeak? Do I need to compile/link with anything special? It doesn't seem like this should be a problem since Squeak is single-threaded. If anything, I would think that the return would be slower not quicker. BTW, usleep returns w/o error.
Any ideas or pointers much appreciated!
brad
Brad as you know the VM is single threaded so you need to return quickly from a plugin call so the interpreter can continue grinding thru bytecodes. Really the question is how are you doing the async processing of the sound? It's not clear from your description.
On 19-Nov-05, at 6:42 PM, Brad Fuller wrote:
The plugin that I'm creating seems to return too quickly. I have a simple test that plays a sine wave and waits 5 seconds (using usleep). The problem is that it stops the sine wave and returns in about a half a second (I hear the sine wave but just a blip. And no errors from the external code.) The code works fine outside of Squeak, but not called from Squeak.
The plugin does 2 simple things:
- Starts a stream that calls a callback routine (below)
- The callback fills a buffer for the sine wave data and then returns
After waiting 5secs, the main line cleans up and exits.
Are there any particular issues with callbacks in Squeak? Do I need to compile/link with anything special? It doesn't seem like this should be a problem since Squeak is single-threaded. If anything, I would think that the return would be slower not quicker. BTW, usleep returns w/o error.
Any ideas or pointers much appreciated!
brad
-- Brad Fuller (408) 799-6124 ** Sonaural Audio Studios ** (408) 799-6123 West San Jose (408) 799-6124 Cambrian ________________________________ Hear us online: www.Sonaural.com See me on O'Reilly: http://www.oreillynet.com/pub/au/2184
-- ======================================================================== === John M. McIntosh johnmci@smalltalkconsulting.com 1-800-477-2659 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ======================================================================== ===
John M McIntosh wrote:
Brad as you know the VM is single threaded so you need to return quickly from a plugin call so the interpreter can continue grinding thru bytecodes. Really the question is how are you doing the async processing of the sound? It's not clear from your description.
At this point, I'm not worried about Squeak continuing (unless there is something I'm missing). I just want to call the plugin, let it play 5 secs, and return back to Squeak.
brad
On 19-Nov-05, at 6:42 PM, Brad Fuller wrote:
The plugin that I'm creating seems to return too quickly. I have a simple test that plays a sine wave and waits 5 seconds (using usleep). The problem is that it stops the sine wave and returns in about a half a second (I hear the sine wave but just a blip. And no errors from the external code.) The code works fine outside of Squeak, but not called from Squeak.
The plugin does 2 simple things:
- Starts a stream that calls a callback routine (below)
- The callback fills a buffer for the sine wave data and then returns
After waiting 5secs, the main line cleans up and exits.
Are there any particular issues with callbacks in Squeak? Do I need to compile/link with anything special? It doesn't seem like this should be a problem since Squeak is single-threaded. If anything, I would think that the return would be slower not quicker. BTW, usleep returns w/o error.
Any ideas or pointers much appreciated!
brad
Am 20.11.2005 um 03:42 schrieb Brad Fuller:
The plugin that I'm creating seems to return too quickly. I have a simple test that plays a sine wave and waits 5 seconds (using usleep). The problem is that it stops the sine wave and returns in about a half a second (I hear the sine wave but just a blip. And no errors from the external code.) The code works fine outside of Squeak, but not called from Squeak.
The plugin does 2 simple things:
- Starts a stream that calls a callback routine (below)
- The callback fills a buffer for the sine wave data and then returns
After waiting 5secs, the main line cleans up and exits.
Are there any particular issues with callbacks in Squeak? Do I need to compile/link with anything special? It doesn't seem like this should be a problem since Squeak is single-threaded. If anything, I would think that the return would be slower not quicker. BTW, usleep returns w/o error.
Any ideas or pointers much appreciated!
Did you wrap the usleep() into a while loop checking for EINTR?
- Bert -
Bert Freudenberg wrote:
Am 20.11.2005 um 03:42 schrieb Brad Fuller:
The plugin that I'm creating seems to return too quickly. I have a simple test that plays a sine wave and waits 5 seconds (using usleep). The problem is that it stops the sine wave and returns in about a half a second (I hear the sine wave but just a blip. And no errors from the external code.) The code works fine outside of Squeak, but not called from Squeak.
The plugin does 2 simple things:
- Starts a stream that calls a callback routine (below)
- The callback fills a buffer for the sine wave data and then returns
After waiting 5secs, the main line cleans up and exits.
Are there any particular issues with callbacks in Squeak? Do I need to compile/link with anything special? It doesn't seem like this should be a problem since Squeak is single-threaded. If anything, I would think that the return would be slower not quicker. BTW, usleep returns w/o error.
Any ideas or pointers much appreciated!
Did you wrap the usleep() into a while loop checking for EINTR?
googling, I found many instances of usleep to be a problem in multithreading. One place said usleep sets an alarm signal to wait. When it occurs, usleep returns. SIGALRM should not be blocked and if it is, usleep will exit. This was my problem.
I abandoned usleep and instead tried nanosleep. The result was the same - I heard just a blip. So, I wrapped the call to nanosleep with blocking the signals with pthread_sigmask(), called nanosleep and then unblocked the signals. This worked.
But, I don't know why. I still don't understand how this would effect the call to the library from Squeak and not as a standalone. What is different, or added, with Squeak that is not with the standalone test?
brad
Am 21.11.2005 um 02:28 schrieb Brad Fuller:
Bert Freudenberg wrote:
Did you wrap the usleep() into a while loop checking for EINTR?
googling, I found many instances of usleep to be a problem in multithreading. One place said usleep sets an alarm signal to wait. When it occurs, usleep returns. SIGALRM should not be blocked and if it is, usleep will exit. This was my problem.
I abandoned usleep and instead tried nanosleep. The result was the same - I heard just a blip. So, I wrapped the call to nanosleep with blocking the signals with pthread_sigmask(), called nanosleep and then unblocked the signals. This worked.
But, I don't know why. I still don't understand how this would effect the call to the library from Squeak and not as a standalone. What is different, or added, with Squeak that is not with the standalone test?
Squeak uses SIGALARM itself, unless you run the VM with -notimer. Which you should not do unless you do not care about performance.
- Bert -
vm-dev@lists.squeakfoundation.org
-
Bert Freudenberg -
Brad Fuller -
John M McIntosh