| Author |
|
mfitzgerald
Vetran
Joined: June 14 2006
Location: United States
Posts: 142
|
| Posted: August 28 2008 at 5:01pm | IP Logged
|
|
|
We have come across an issue dealing with audio file playback. Am I right to believe the only change from the version we had (5.12.3.30) to the newer version 5.12.8.1 (but not newest) is the addition of the parameter *pBytesPerSample to the OpenWaveFile().
Background
When we first tested the new media engine we were inadvertently running with 5.12.8.1. The transition from 5.12.3.30 to 5.12.8.1 was straightforward, and simple. It was tested in multiple environments with absolutely no adverse effects.
However upon finding out the version we were testing on was not the latest; we copied the LMEVoip.dll patch and necessary redistribution code, and micro code and began testing again.
This time we hit a snag right off the bat. Upon entering the code to play back an audio file the application crashed completely. NOTE: we had already made the one and single modification required to upgrade from 5.12.3.30 to 5.12.8.1. (i.e. the addition of the int parameter for BytesPerSample). No other modifications were made to that code.
Troubleshooting
I have tried several things to track down what happened and then I recalled we tested this in 5.12.8.1 successfully and there had been no changes after that.
I am not pointing fingers, but at first glance it appears there is some bug in LS between version 5.12.8.1 and 5.12.8.7 which causes a catastrophic error when playing an audio file back.
BTW One of the tests performed was to comment out everything just before the OpenWaveFile and the entire if block regarding that functions status. The application was tested with this modification and it worked just as if there had been no problem. (Of course we can not play audio files at this time.) This does indicate the problem is somewhere here.
FYI: we have some logging mechanism, it appears that each time through the code it is successful up to the for loop containing GetWaveBuffer() but, breaks somewhere after that.
The effect is, at times, we can hear part of the audio file before the application dies.
Additional Test
One additional test, just to ensure absolutely nothing had been modified on our application. I completely uninstall LS v 5.12.8.7 from the system, then install 5.12.8.1 from scratch, updated the Microcode and Redistribution codes and ran the test again. It was a success. The audio file played as expected.
Any suggestions?
As always thanks for the quick response.
|
| Back to Top |
|
| |
support
Administrator
Joined: January 26 2005
Location: United States
Posts: 1666
|
| Posted: August 29 2008 at 7:51am | IP Logged
|
|
|
Hi Fitz,
Good post. Lots of info.
Its OK to point fingers – we make our share of mistakes. ;)
Very Important:
Forget what the engineering release notes say. Did you completely rebuild your VOIP app using the v5.12.8.7 release?
For example:
1)
Install v5.12.8.1 on your dev box. Normally you uninstall a previous version and then install the new version.
2)
Get these files from the v5.12.8.7 engineering release:
LMEVoip.dll
LMEVoip.lib
LMEVoipManaged.dll
SipTelephonyApi.h
And replace the v5.12.8.1 installed files of the same name.
3)
Use the LanScapeVME.c module that came with the v5.12.8.7 release.
4)
Completely rebuild your VOIP app. As a rule of thumb - always rebuild your app when receiving a media engine update. It’s the conservative and smart thing to do.
5)
Perform normal testing.
We will be here all day. There should be no problem using wave file playback in the x.x.x.7 release. We will transition this over to voice support if we have to.
Repost back ASAP and we will respond immediately.
Support
|
| Back to Top |
|
| |
mfitzgerald
Vetran
Joined: June 14 2006
Location: United States
Posts: 142
|
| Posted: August 29 2008 at 12:04pm | IP Logged
|
|
|
Very prompt reply as usual.
I just wish other service providers were so quick to assist.
To answer your questions:
1) yes.
2) yes.
3) yes.
4) yes.
5) yes.
I am not quite familiar with the numbering scheme but then it was posted 7:51 am... I am not fully functional till about 10:00 myself.
Just to be certain, knowing everything was uninstalled and verified uninstalled completely before installing 5.12.8.1 from scratch, I again copied all the files and updated the microcode as mentioned above. This time I kept backups of all the modified files to allow us to move back and forth between 5.12.8.7 to 5.12.8.1.
Once all the files were updated from 5.12.8.1 to 5.12.8.7 and revivified, I ran the test again with the same results as the initial post.
Just to be certain there is not some simple misunderstanding I will list the files and timestamps for both versions. It could be as simple as thinking we have put everything in its place only to find it was not the correct file.
5.12.8.1
Code:
8/5/2008 1:42 PM (227,746 bytes) - LanScapeVME.c
2/20/2008 11:14 AM (80,801 bytes)- SipTelephonyApi.h
2/22/2008 6:56 PM (67,204) - LMEVoip.lib
2/22/2008 6:56 PM (5,419,008) - LMEVoip.dll
2/22/2008 7:02 PM (122,880) - LMEVoipManaged.dll
|
|
|
5.12.8.7
Code:
8/5/2008 11:25 AM (227,746 bytes) - LanScapeVME.c
8/11/2008 10:41 AM (89,316 bytes) - SipTelephonyApi.h
8/11/2008 10:41 AM (74,574) - LMEVoip.lib
8/11/2008 10:41 AM (5,525,504) - LMEVoip.dll
8/11/2008 10:41 AM (135,168) - LMEVoipManaged.dll
|
|
|
It strikes me as odd that the LanScapeVME.c file timestamps are in that order. Of course being the MicroCode file, if it were wrong would not that have caused a problem at start time?
Again thanks for your quick response.
|
| Back to Top |
|
| |
support
Administrator
Joined: January 26 2005
Location: United States
Posts: 1666
|
| Posted: August 29 2008 at 12:52pm | IP Logged
|
|
|
Fitz,
Ok, bad numbering on original post. Trying to get too much done before the proper amount of morning coffee ….
Hmm…. Strange. It has to be something dumb.
We need to “shotgun” a bit before we waste too much more time. Replacing files from an engineering release and rebuilding is so simple, it should work without errors every time.
When we updated your support FTP account, we used v5.12.8.7. Since then we have released to a bunch of other customers the v5.12.8.8 image. They have had no problems using the same manual update procedure you are using. Internally we are working on v5.12.8.9 right now.
I think we should dump the x.x.x.7 version, get you the x.x.x.8 version and try again. If that does not work, then we need to dig further. Normally this goes very smooth.
Is there any chance that your app is still accessing an old media engine DLL image because of system PATH?
Search your entire host for LMEVoip.dll and remove all but the version you have built against. Something weird is occurring. Forgive us if we are stating the obvious and if you have already performed these steps.
In the mean time, your support FTP account has been updated with v5.12.8.8. Give it a try and repost. Use the License files from the “Engineering Update v5.12.8.7\License Files” directory.
If we get the same results, then I need a mini dump from you or I need to see how you are calling the offending API.
It should “just work”.
Thanks Fitz,
Support
|
| Back to Top |
|
| |
mfitzgerald
Vetran
Joined: June 14 2006
Location: United States
Posts: 142
|
| Posted: August 29 2008 at 3:47pm | IP Logged
|
|
|
Thanks.
I have followed your suggestion to search for other LMEVoip.dlls through out the host system. This search turned up a few dilapidated (pre-5.12.3.30 versions). They have been removed just to be safe.
To verify further I performed the following check to ensure the dll that was associated with the application was indeed the dll being used. This method should be just as effective.
1) Run the app.
If it runs then you are ok. (tests nothing more than the dll exists)
2) Stop the app
3) Rename or move the LMEVoip.dll that is allegedly being used.
4) Run the app.
If it fails, that is the library being used, check the version. And put it back the way you found it.
Sometimes retesting the obvious or retesting the same steps may solve the problem. Such is the nature of troubleshooting.
I have just run the test with 5.12.8.8. I got the same results. I will re-test and re-check everything Tuesday as I need to leave now. It is possible I missed something in my hast to get home for the three day weekend.
|
| Back to Top |
|
| |
support
Administrator
Joined: January 26 2005
Location: United States
Posts: 1666
|
| Posted: September 02 2008 at 8:55am | IP Logged
|
|
|
Fitz,
Ok. We will be here all day (Tuesday 9-2-08) so ping us when you get a chance.
Support
|
| Back to Top |
|
| |
mfitzgerald
Vetran
Joined: June 14 2006
Location: United States
Posts: 142
|
| Posted: September 02 2008 at 10:56am | IP Logged
|
|
|
Well, I have had the opportunity to revivify the update to 5.12.8.8, double check timestamps, cleaned the build and rebuilt after rebooting the host system.
The application still crashes when attempting to play an audio file with 5.12.8.8.
I found it curious that SipTelephonyApi.h for 5.12.8.8 appears to have a earlier timestamp (8/6/2008 4:34PM) than it does for 5.12.8.7 (8/112008 10:41AM).
|
| Back to Top |
|
| |
support
Administrator
Joined: January 26 2005
Location: United States
Posts: 1666
|
| Posted: September 02 2008 at 11:48am | IP Logged
|
|
|
Fitz,
We need to get this over to voice support. This is taking way too long.
Something dumb is going on. We have apps that use wave file playback to local multimedia hardware and to the Tx IVR phone line outputs that are working fine.
The time stamp for your v5.12.8.8 SipTelephonyApi.h file is OK. The time stamp for the v5.12.8.7 SipTelephonyApi.h is not correct. It should be 5/22/2008 9:41 AM.
Is your FTP client changing file timestamps by chance? Hmm….
1)
If we send you VOIP account information for our phone system, do you have a VOIP phone (using either G729 or iLBC) so that you can configure and use to speak with us?
We will send you voice support numbers via email.
2)
Do you have a stand alone app that we can get and execute here that blows up? We can test here that way.
3)
If we cannot get a stand alone exe of your app here, can you upload a full heap mini dump so we can post mortem look at what is going on?
We are waiting your input. You are top priority at this time.
This does not make sense.
Support
|
| Back to Top |
|
| |
support
Administrator
Joined: January 26 2005
Location: United States
Posts: 1666
|
| Posted: September 02 2008 at 2:39pm | IP Logged
|
|
|
Fitz,
We may have located the problem based on the contents of your mini dump file for v5.12.8.8 media engine.
It looks like a bug in the media engine that occurs only if:
1)
The media engine license file has Integrated DTMF generation/detection enabled.
2)
Integrated DTMF is disabled when the media engine is started.
3)
The VOIP app uses the raw RTP packet access capability and filters RTP media packets from being transmitted.
It appears that under these conditions, the specific phone line RTP transmitter logic can use an un-initialized pointer value that is causing the Access Violation.
Possible Remedies:
1)
Simply enable integrated DTMF capabilities globally when the media engine starts. Your VOIP app then does not have to enable any other DTMF capabilities on a per phone line basis unless your app requires it.
2)
Do not allow the application to filter transmitted RTP media packets when using a license file with integrated DTMF enabled and when internal DTMF is not enabled when starting the media engine.
3)
Allow us to get you an updated v5.12.8.9 engineering release that will resolve the issue. We can still get this done today (9-2-08)
Call us back or repost so we can respond as required,
Thanks,
Support
|
| Back to Top |
|
| |
mfitzgerald
Vetran
Joined: June 14 2006
Location: United States
Posts: 142
|
| Posted: September 02 2008 at 3:34pm | IP Logged
|
|
|
Thank you for your response. We look forward to the updated version.
In the meantime we'll look into the recommendations.
|
| Back to Top |
|
| |
support
Administrator
Joined: January 26 2005
Location: United States
Posts: 1666
|
| Posted: September 02 2008 at 3:44pm | IP Logged
|
|
|
Fitz,
The updated engineering release v5.12.8.9 has been copied to your support FTP account.
You might as well retest your app with this latest image. You will not have to modify your app code. The access violation should no longer occur... unless there is something else related to the issue that we have missed.
Repost as soon as you have updated test results.
Thanks,
Support
|
| Back to Top |
|
| |
mfitzgerald
Vetran
Joined: June 14 2006
Location: United States
Posts: 142
|
| Posted: September 03 2008 at 12:04pm | IP Logged
|
|
|
I've upgraded to 5.12.8.9 and have re-run the tests. It appears that everything is running as expected.
Thanks again.
|
| Back to Top |
|
| |
support
Administrator
Joined: January 26 2005
Location: United States
Posts: 1666
|
| Posted: September 03 2008 at 1:06pm | IP Logged
|
|
|
Hi Fitz,
Thanks for the feedback... bugs are always a pain. It really helps us here to get the mini dumps from you. Good job.
Do not hesitate to post to a new thread if you detect any other misbehavior. Your group has a support agreement with us so your issues are top priority with us.
Thanks,
Support
|
| Back to Top |
|
| |
Active Topics 
Member List 
Search 
Help 
Register 
Login
LanScape Support Forum -> LanScape VOIP Media Engine™ - Technical Support
Topic: Wave File Playback
