We already have a heartbeat for the media task, it probably would not be difficult to send the heartbeat (i.e. OsMsg) to multiple consumers (e.g. the MpOutputDeviceManager).
--- Alexander Chemeris <[EMAIL PROTECTED]> wrote: > Hello, > > On 3/21/07, Daniel Petrie <[EMAIL PROTECTED]> wrote: > > I am wondering if we can solve the mixing requirement in a way that > > does not require two different modes or driver behaviors. I would > > rather have a little more complexity in the manager and simplify > the > > driver implementation. One option that comes to mind is that if > the > > manager knows ahead of time how many resources are going to > contribute > > push a frame to be mixed before given to the driver, then the > manager > > or connection could know that it was being given the last frame to > mix > > and actually push the mixed frame to the driver. This is a little > bit > > ugly or complicated in that the manager has to know who is going to > > contribute ahead of time, but in this way we can design the drivers > to > > always get a frame pushed as soon as it is ready. > > I dislike this approach, as it may lead to blocking of all streams > due to > delay/hang of one flowgraph. I could propose other way, I'm thinking > of > a while. Device could provide heartbeat timer interface, which will > call > AudioOutputConnection callback. This call back will in turn push > frame > to device or do other fancy thing, e.g. start processing of next > frame in > flowgraph. Under Linux we have separate thread for flowgraph timing > and > under Windows we depend on WOM_DONE messages in speaker thread. We > should > consider the way to provide timing in new device framework if we want > to remove old one. > > -- > Regards, > Alexander Chemeris. > > 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/
