Thanks for the reply Benny. I have been reading more code and I still don't fully understand why the extra frame(s) is sticking around, but I think I have solved the problem by adding another callback. Here is the idea: 1. get_frame grabs the last bit of data from the WAV player buffer and passes it back to the conference bridge. Even though EOF has been reached, no error code is returned at this point. 2. get_frame is called again, since EOF has been reached and no more data is left in the buffer, I can now call my player_done callback. It returns a status code to the conference bridge, plus a none-frame. I have not thought about the looping playback case yet, but I am wondering what you think of this in general? If I can clean this up a bit, would you be interested in a patch? Thanks again, Mike Benny Prijono wrote: > Hi Michael, > > thanks for the useful report. I could swear that I've fixed > something related to left-over audio but I couldn't find the exact > details for it. I'll try to find it out asap. > > In the mean time, an easy fix is to add few hundreds milliseconds of > silence to your WAV files, if that's at all possible in your app. > > cheers, > -benny > > > Michael Broughton wrote: > >> Hi again, >> >> I have been doing some follow-up experiments going under the assumption >> that I should do less work in the EOF callbacks. This has lead me to a >> different problem: The EOF callback is actually getting called before >> playback is finished, and there appears to be a fraction of a second of >> media left over in a buffer somewhere. For some reason, that extra >> 'blip' is sticking around (even if I destroy or just disconnect the >> current player), without being played, and it is getting mixed in with >> the next player that I start (even if the player is created several >> seconds after the EOF has returned). >> >> Is this a bug? Or am I just using PJSIP incorrectly? I should also point >> out that I don't have the option of using a Playlist instead of multiple >> players because I need to know when individual players have completed. >> >> >> Obviously, the EOF callbacks are not giving the exact behavior that I >> desire. Is there some other way I could find out when playback is >> completely finished? Or at least a point that won't result in >> interference from another player? One player playing at a time, would be >> nice. >> >> Thanks, >> >> Mike >> >> >> >> Michael Broughton wrote: >> >>> Hello, >>> >>> We are having some problems with audio quality in our application. We >>> are using the WAV file player and most of the time it works just fine. >>> However, sometimes the audio will cut out for fractions of a second. >>> This does not appear to be caused by jitter or other networking issues. >>> >>> I have been able to look at the audio waveform in Wireshark, and I can >>> clearly see where the waveform goes flat. Also, I have not been able to >>> identify anything unusual in the log output (level 5). I can post a >>> sample log and tcpdump, if required. >>> >>> As far as I can tell, this isn't anything weird with our configuration. >>> CPU utilization is low. The problem shows up even with small numbers of >>> simultaneous calls. >>> >>> Could this be caused by the WAV file player EOF callback taking too long >>> to return? It is not unusual for our application to destroy the current >>> WAV file player and create a new one from the EOF callback. I may try to >>> revise this by creating all the required players at the start of the call. >>> >>> Any suggestions will be greatly appreciated. Thanks, >>> >>> >>> >> > > > -- Michael Broughton, Advanis Unintended Recipient & Unauthorized Use of E-Mail: This message and attachments may contain confidential or privileged information that is intended only for the named recipient of this e-mail. Any unauthorized use or distribution is not permitted. If you have received this e-mail in error, deleting the e-mail and notifying the sender would be appreciated. Thank you.
