Not quite.
- We are not providing a virtual audio device available to other applications in Microsoft Windows - This is going to be platform independent, available to applications that need to do low latency media processing. On 3/21/07, Medhavi Bhatia <[EMAIL PROTECTED]> wrote:
I am not too familiar with the sipXmedia architecture yet, but a lot of this sounds like what may be implemented by "Virtual Audio Cable" (http://software.muzychenko.net/eng/vac.html ). Are we planning a superset of this functionality or something totally different here? On 3/21/07, Alexander Chemeris < [EMAIL PROTECTED]> wrote: > Hello, > > As you may see we're working on new audio input/output framework for > sipXmediaLib. Audio input part of new framwork is at the middle of > design and > already partially implemented. Now it's the time for audio output part. > Here > I'll present first draft of its design. > > So, the key idea and the most exciting goal of new framework is support > of > multiple input and output devices, multiple connections to them and > support > switch of audio devices in runtime. Each device either input or output > is > presented with separate object with unified interface. Device objects > are > not accessed directly, but incapsulated to so called connecions to > enable > concurrent access from several flowgraphs. Connections, in turn, are > incapsulated to device managers, which provide multi-thread > synchronization > and hide device management complexity. > > Audio output framework is similar to audio input framework, but have > some > significant differences. Each audio output driver could work in two > modes: > direct write mode and non direct write (mixer) mode. In direct write > mode > data is pushed to device as soon as it become available. In mixer mode > data > will be buffered and then pulled by device itself. Direct write mode > have less > latency, but could be fed by one source only. If two sources will try to > push > data, only one will succeed. In opposite to direct write mode, mixer > mode is > supposed to accept several sreams and mix them. In this mode device > should > pull data when needed, as device manager do not have clocks and do not > know > the time to push next frame. > > In mixer mode device have simple circular buffer of samples associated > with it. > This buffer is driven by respective AudioOutputConnection, which is > responsible > for mixing incoming data and handling of all exception situations. In > this mode > device driver should provide timing for pulling data, so callback or > thread > mode are appropriate. In direct write mode data passed to > AudioOutputConnetion > is simply pushed to device, so device driver might work in any mode, but > > asynchronous write mode seems native in this case. > > Further, I have some doubts on synchronization scheme we've selected. > Now we have all synchronization done in MpOutputDeviceManager and > AudioOutputConnection do not provide synchronization at all. This leads > to > exposing pullFrame() interface, intended to device driver only, to > anyone > access. I prefer to hide such methods and do not expose them to end > user. > Natural place for pullFrame() is AudioOutputConnection, but it could not > be > put there while AudioOutputConnection is not thread safe. There is one > more > problem with exposing pullFrame() on MpOutputDeviceManager level - it > will > block waiting for other MpOutputDeviceManager methods to finish, while > this > call should be realtime. > > PS Draft1 version of MpOutputDeviceDriver and MpOutputDeviceManager > interfaces was checked in at revision 9121 to sipXtapi svn branch. > > -- > 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/ > > _______________________________________________ sipxtapi-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipxtapi-dev/
-- 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/
