On 5/17/07, Daniel Sigurgeirsson <[EMAIL PROTECTED]> wrote:
>> In my opinion, these events should be fired from the resource that plays the file/buffer. Keith is using on new messaging system, consult him please. Is Keith reading this? My understanding is that MprFromFile takes care of both tasks, and that doProcessFrame is the function which actually copies the data and would therefore know when copying is done. Am I correct? This function does send FLOWGRAPH_STOP_PLAY message (to itself) when playback is complete, which is then handled inside the handleStopToneOrPlay( ) function. But I'm not sure where to go from there (who would receive the notification), and I cannot see any easy way to distinguish from these two types of messages.
Yep, I'm the right person to contact on this. I'm working on a new (direct pointerless) messaging model, and MprFromFile has already been converted to use it. Right now the operation messages (return messages) for MprFromFile are a CF -- there's one to indicate play, and one to indicate stop - that the flowgraph uses, but none seem to work right. If you use the buffer variant to play, the OsProtectedEvent isn't even used - it's set to NULL... so you don't get any that way. I changed that to use instead, a plain OsNotification*, but the logic still is incorrect, and events are not fired correctly. There is one message you can use. Right now it's internal, and meant just for the flowgraph (so it can do some cleanup of it's own)... FLOWGRAPH_STOP_PLAY - which is sent in the doProcessFrame loop of MprFromFile (MprFromFile.cpp:617). I'd recommend against extending this particular message out to the CallLib.. I have initial infrastructure created in the Flowgraph for a Notification dispatcher (look at MpFlowGraphBase). The user of sipXmediaLib creates a dispatcher if it wishes to receive messages back from resources. Any messages that resources set will then be queued up on queues contained in the Notification dispatcher. It is the responsibility of the creator of the dispatcher to read the queue in a timely manner. So, that's the idea.. There's more info on this that I posed on the mailing list about err.. 3 weeks ago or so I think. Now, there's also another, older notification mechanism -- use of OsNotification and OsProtectedEvent (why both were used, I have no idea -- it seems no good reason). It appears that the use of OsNotifications and OsProtectedEvents for sending status has never functioned correctly... Another related thing: Under Linux, I did cause a regression in playFile that I just noticed today -- the new resource messaging isn't propagating correctly and audio isn't being started - I'll be working on that next -- works fine under Windows though. Now, onto what notifications we want to provide. The notification I believe is most needed that we want to provide is: MPRNM_PLAYFILE_STOPPED when a file finishes playing (prematurely from someone telling MprFromFile to stop, or naturally when the clip ends) We may also want to, in the future, provide MPRNM_PLAYFILE_PAUSED - we currently don't support pausing (that I can see). I would contend that we don't need an MPRNM_PLAYFILE_STARTED message, as we should be able to assume that it starts milliseconds after we queue it. Names above are subject to change -- feel free to recommend something better -- the MPRNM means "MP Resource Notification Message" -- Keith Kyzivat SIPez LLC. SIP VoIP, IM and Presence Consulting http://www.SIPez.com tel: +1 (617) 273-4000
_______________________________________________ sipxtapi-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipxtapi-dev/
