Hi Alex:
Thank you for puting together this proposal for the output device
management and driver framework. You have done a nice job of
explaining the requirements and proposed solution.
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.
This approach also means that there is no need to make a public method
for the device driver to invoke on the manager (the manager will invoke
a method on the device to push the frame). There is still locking
required on the manager and connection. However this can be made
fairly granular to avoid cross device blocking using the following
approach:
take lock on the manager
take the lock on the connection/device,
release the manager lock
invoke the frame push to the driver
take lock on the manager
release the lock on the connection/device,
release the manager lock
This approach takes the large scoped lock on the manager for a short
period of time only long enough to take the lock on the specific
connection/device. If the connection/device lock is not available, the
manager lock is released and you wait or poll to re-attempt to take the
connection/device using the prior process. We actually use this
locking pattern in any places in sipX, most recently in the
MpInputDeviceManager.
Cheers,
Dan
--- 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
>
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/
