..

Event reporting speed?

..

Developer Group

Developer Group
Connect with thousands of other developers to brainstorm ideas, share best practices and tips - or just chat about the latest emerging technologies making noise in the field. And of course, get the most up-to-date service and support news from Dialogic.
Dialogic PowerMedia HMP GlobalCall and R4 API

Event reporting speed?

  • So let me precede this by saying I think this may be an issue on HMP systems too from what I've observed. That being said...

    After some interoperability testing, I've noticed DM3 cards experience a significant (over 100 milliseconds, probably less than 500) pause relative to JCT cards when they send back events to indicate the termination of a function such as playback or digit collection. Is there any way to reduce the time it takes to report these events back?

  • How many channels were running when you did the test?  Also what boards did you use for comparison sake in this case?

    While you may be able to compare timing HMP to that of SR since its completely different architectures and thus the path of communications would be different in messaging between host library and firmware interactions, however, I am not sure things would be slower.

    Regards,

    Jeff

  • I've tested this with a DM/V1200BTEPEQ and a DM/V960A-4T1 against a D/240JCTT1-EW. Most of the testing has been done with only one call, but I've put up to four calls on there while testing.

    I made a quick test program to illustrate the issue:

    https://transfer.sh/%28/rdgj1/dm3_multiplay.wav,/10Yvv/jct.wav,/MZoQh/dm3.wav%29.zip

    In the code being executed with dm3.wav and jct.wav, the software simply plays one prompt before waiting for a TDX_PLAY event to come back and starting playback with something else. With dm3_multiplay.wav, the board plays up to three prompts before returning the event, significantly reducing the pause between them.

  • Ok, what is the SRL programming model being used in this case for event processing? Singel or multi thread app?

    Are you measuring the times with the same exact file played between the two tests? I noticed the JCT and DM3 wave files provided are different in size in this case. One if 29.3345 (jct) vs that of 30.286 (dm3). So the JCT will play quicker in that case.

    Is this just playing by passing the File, or is this using streaming IO interface?  As the block sizes and read/writes used for host library to fwl interaction are different in size between DM3 and JCT, so processing will ultimately by different between the two pending lengths of files played.

    Jeff

  • One note on the DM3 and JCT products.  The DM3/JCT boards were sold to Sangoma Technologies on January 9, 2018.    While the API interfaces are similar between DM3, JCT and HMP products, the underlying internal architecture does differ and event timing may be different based on the architectures.    If there are questions between JCT and DM3 board event processing, it may be best to touch base with Sangoma directly.  

    All that said, the programming choices, buffer sizes, ... etc, that Jeff alluded to may also come into play.

  • This is a single-threaded asynchronous application. In all cases, the file is just being passed. To be honest, no, I'm not doing any sort of measuring other than listening for audible differences in the pauses between the prompts; the ones being chosen are picked randomly. The file size being different is a result of when I decided to stop the tests, since it's designed to run forever.

    I understand why playing random wave files may not seem like the best documentation of the issue. I'll re-run this using tones generated by the DSP.

  • Here's the results of the aforementioned tone test: transfer.sh/.../dm3_tone.wav%29.zip

    In this case, both cards were given a 600 hertz/1000 millisecond tone to generate. Upon reception of a TDX_PLAYTONE event, they were given a 500 hertz/1000 millisecond tone to generate and so on. Aside from the first iteration where it takes considerably longer, the DM3 seems to take ~70 milliseconds longer to respond to the event.

  • Going back to your prior comment:

    "To be honest, no, I'm not doing any sort of measuring other than listening for audible differences in the pauses between the prompts"

    This is not really valid way to check in that case since the dm3 file has 250ms of silence prior to audio within it, as opposed to jct file like 10ms. So of course in that case there will be delay in prompt being played on the dm3 side due to more silence with it. I guess if you are doing this at random you have to consider the content within the files to have accurate measurements.

    Jeff

    Jeff

  • That is true. Is the tone method any more reasonable? That should be much more easily measurable - and reproduceable.

  • Hi

    Ok, the only true way to measure the performance would be to review the log entries between the scenarios (dm3 vs JCT). But that is something the Sangoma team would have to look at now since they own the System release product baseline since it was sold by dialogic beginning of this year (as Dan mentioned above).

    www.sangoma.com

    Jeff