I noticed nearly all the time when using the phone pad in the SIP soft phone plugin for making a call, the DTMF sounds would audibly play noticably later than when I pressed the number key (in the text field or pushing that number key button.
The attached patch is against the SVN head, r11699 at this time, fixes this DTMF sound playing latencies. It is now possible to type in DTMF tones into the text field as fast as you can type and have the sounds play responsively.
Details:
Some looking into this revealed it was not the action handler stuff taking random long amounts of time to play things, but instead something about that [old] Applet AudioClip facility. where invoking play() apparently takes some random amount of time to actually get around to making a sound. This is all within the Applet / AudioClip API, and of course nothing we can do to fix.
So I re-wrote the DialSoundManager to make use of the javasound API. While in the process, I created a kind of queueing mechanism, so as to allow request to have a DTMF sound played queueud up, and handled by a new internal worker thread inside DialSoundManager.
Where the things that use the DialSoundManager (currently only the PhonePad), should now invoke the “enqueue()” method, instead of the play() methods.
The motivation for this synchronization is currently in the javasound API, their simple player interface that works with AudioStream classes does not have the concept of being able to simply rewind the audio stream (at least how we like to fetch the sound file as an input stream from the resource). Additionally, the javasound API doesn’t appear to have any kind of “onFinish()” event we can hook into. So the technical challenge here is when the stream is played, we need to re-initialize the given stream so that it will be ready to be played the next time it is requsted.
So that DialSoundManager looks a bit more complicated now, as I have just embedded all the logic to make it behave like it did with the Applet sound clip, where the AudioStream is reloaded due to the logic that detects when the stream has ended.
The only consideration now is there would be slightly more file IO to read the DTMF sound file every time, but certainly this is offset due to class loader and/or file the operating system caching. and the experience is likely the same or better than the Applet AudioClip facility that stored the entire clip in memory before.
I am excited to hear your feedback,
Travis.
softphone_dtmf_loagie_fix-r11699.patch.zip (2364 Bytes)