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/
