Multi-instance input device control

Abstract

The present invention combines features of an executable process with the need for multiple application programs to share a single input device. The present invention provides an executable program implemented as a process that allows multiple applications to communicate with a single input device. This is achieved by loading the input device control executable program as a process. The executable program is a server thus allowing multiple application programs to interface with the same input device. The multi-instance input device control (MIIDC) executable program responds to each application program request as if the input device is open for the calling application program. Each application program is thus enabled to communicate with the input device instance without interrupting the operation of other application programs communicating with the input device. The input device instance keeps track of all the connections to it and multiplexes and resolves conflicting requests.

Description

CROSS-REFERENCES TO RELATED APPLICATIONS [0001] This application is a continuation of application Ser. No. 09 / 882,527, filed Jun. 15, 2001, which is a continuation-in-part (“CIP”) of application Ser. No. 09 / 438,012, filed Nov. 10, 1999, which are all incorporated by reference.BACKGROUND OF THE INVENTION [0002] The present invention relates to media source input devices such as microphones and video cameras, and in particular to the interfacing of media source input devices to application programs. [0003] Traditionally, when one application program connects to a media source, all other application programs are prevented from using that media source. In the context of a common personal computer, when an application program calls to communicate with a media source, the application program calls to the driver files or the dynamic link library (DLL or *.dll) files. Typically, a DLL provides one or more particular functions and a program accesses the function by creating a link to the DLL...

AI Technical Summary

Benefits of technology

[0011] MIIDC is implemented so that for each actual hardware input device, the DCOM server creates a single input device instance and connects to the hardware device. When an application program connects with the input device control—which is an executable DCOM server—the DCOM server creates a MIIDC instance (and an interface) through which the application program communicates with the single input device instance. Data is provided for output by the single input device instance for each instance of the input device control, thus allowing simultaneous multiple applications to communicate with a single input device. Global settings are (MIIDC) instance specific. Additionally, the input device instance is protected so that multiple instances of the input device control program cannot perform tasks that would interfere with processing in another instance. Using this new approach, applications can be written which do not need to account for the presence of another application possibly already using the same input device.

[0014] The client-side mechanism under the second approach (i.e. DirectShow approach) takes advantage of the standardized DirectShow modular components called filters. This second client-side mechanism replaces the standard source (media input) filter with a virtual source filter, which communicated directly with the MIIDC server. The virtual source filter is a client to the MIIDC server. With this mechanism, a DirectShow application cannot distinguish between the “real” and the “virtual” source filter. The advantage of this second client-side mechanism is that any application program written to function in a DirectShow environment, will be able to readily share an input device without the need for any additional user-interface programming before being able to communicate with the MIIDC server.

Problems solved by technology

The issues related to conflicts in sharing a media source between multiple application programs is known as contingency issues.

There will be contingency issues, since typical input device drivers only allow one application to use the input device data at any given time.

This is because the video camera driver file has been loaded in the first application program's memory and is not available to be accessed by another calling program.

Presently, no application program even attempts to resolve any of these issues, and therefore if a connection between a calling program and a camera cannot be established, the unexpected application programs errors are resolved by the operating system which issues rather inelegant and undecipherable error messages leaving the ultimate user to only infer that a proper connection could not be established.

Besides growing in complexity and usability, multi-unit application programs have been migrating from single-host sites to multiple host heterogeneous network environments.

Thus, while many computer system operating system suppliers are providing many standardized models for executable programs, even such executable programs can only interface with a media source input device on a one-on-one basis.

Images