during the weekend I did some more tests to get information about
the problems with portaudio.
First my system configuration:
- OpenSuse 11.2 64 bit, Java 1.6 64 bit. I did the tests with both Sun and
- AMD dual core processor (may have an effect on thread timing)
Some other results:
Javasound works with the Sun Java environment (not fully tested inside
openJDK). In general no problems using Javasound / Sun Java.
Here the notes regarding the portaudio tests:
When running with ZRTP/SRTP enabled I had no success with portaudio because
of this message:
[java] Expression 'AlsaOpen( &alsaApi->baseHostApiRep, params, streamDir, &self->pcm )' failed in 'src/hostapi/alsa/pa_linux_alsa.c', line: 1186
[java] Expression 'PaAlsaStreamComponent_Initialize( &self->playback, alsaApi, outParams, StreamDirection_Out, NULL != callback )' failed in
'src/hostapi/alsa/pa_linux_alsa.c', line: 1417
[java] Expression 'PaAlsaStream_Initialize( stream, alsaHostApi, inputParameters, outputParameters, sampleRate, framesPerBuffer, callback, streamFlags,
userData )' failed in 'src/hostapi/alsa/pa_linux_alsa.c', line: 1994
[java] 19:17:56.657 SCHWERWIEGEND: impl.neomedia.notify.PortAudioClipImpl.run().153 Cannot open portaudio device for notifications
This gave me some hint: ZRTP plays a notification sound if the handshake was
successful. This notification sound is of course in parallel to the existing
audio data stream.
To overcome this problem I switched of the notification sound. After that
I was able to have _some_ secured calls under very specific circumstances:
- first set up a call to iptel "music" and listen to the fine music for
a short time
- the next call to a Zfone enabled SIP client - I got a secure call
There is no way yet to setup secure calls otherwise, other calls result
in the "device unavailable" error from portaudio C code.
Analysing some more:
When calling iptel's music sets up the audio device with a sample rate
of 8000.0 immediately.
Calling any other SIP client the first setup of the audio device has
a sample rate of 22050.0 (half of 44100 which is a CD sample rate). Only
after receiving the 200 OK the new sample rate 8000.0 is used.
- the main difference here: iptel's music does not send a 180 Ringing but
a 200 OK immediately (no ringing at the server). It seems that 180 Ringing
triggers a device setup already.
Looking at the various exceptions and error messages to me it seems to be a
timing problem (thread execution/race condition?). Some thread blocks resources
(audio resources?) because SC never shuts down gracefully but "forced".
During my tests sometimes the whole Java JVM crashes, sometimes with error log,
sometime without. I attach a dump log to this mail.
hs_err_pid27995.log (94.8 KB)