Methods and systems for multiple access to a single hardware data stream

Methods for providing simultaneous access to a hardware data stream to multiple applications are disclosed. The first application to access a hardware device is responsible for providing and publishing an application programming interface (API) that provides access to the hardware device's data stream, which other applications can then call to gain access to the data stream. In some examples, the first application may be a server process or daemon dedicated to managing the hardware device data stream and publishing the API. In some further examples, the first application may instead may carry out user functionality unrelated to managing the hardware device.

BACKGROUND

The present disclosure relates generally to the management of data streams generated by computer hardware. In particular, methods and systems enabling the sharing of a single hardware data stream with multiple consuming applications are described.

Modern mobile devices are commonly equipped with hardware such as a camera that can be used by a variety of applications capable of being executed by the mobile device, so as to perform a variety of functions. For example, applications exist that can take pictures and video captured by the camera and manipulate them, edit them, insert them into other media, and/or upload them to online services for further distribution and usage. As the devices equipped with cameras and their associated applications grow in sophistication, the ways in which video streams can be utilized continues to broaden. The nascent field of wearable technology introduces the possibility for device control using gestures, detected by the built-in camera and processed by applications to accomplish a variety of tasks or commands previously clumsily accomplished using historically common means of input, such as a keyboard, pointing device, or voice control. The video feed from a wearable device, when coupled with a display positioned within the wearer's field of vision, also presents the opportunity for providing an augmented reality experience. Where the video stream coincides with the wearer's field of vision, an application can use image recognition techniques on the data stream to detect points of potential interest to the wearer, and provide notification of those points to the wearer by means of a display overlay.

Known implementations of managing data streams from hardware devices are not entirely satisfactory for the range of applications in which they are employed. For example, existing methods for managing the video stream from a camera require that an application be given exclusive control of the camera, effectively denying simultaneous access to the camera's data stream to any other applications that may need it. This is problematic when it is desirable for two applications that require the camera to be running simultaneously, such as in the foregoing example of one application that recognizes and acts upon user gestures made within the camera's field of view, and a second that interprets the camera stream and superimposes augmented reality cues on a transparent screen disposed within the user's field of view. Without simultaneous access to the camera data stream to both applications, it is impossible to present an augmented reality overlay while providing gesture recognition at the same time.

While this limitation could possibly be overcome using a single, monolithic application that provides both gesture recognition and the augmented reality overlay (as well as any other functionality that conceivably could be simultaneously desired), practical limits to the wearable device hardware platform must be recognized. A monolithic application typically imposes a greater memory footprint which, in the context of a wearable device or mobile platform that often has relatively limited working memory capacity when compared to a typical laptop or desktop computer, may result in fewer additional applications being able to run simultaneously. If separate processes for gesture recognition and augmented reality can be utilized, one or more of the applications can be unloaded when not needed (e.g. it may be desirable to have gesture recognition continuously active, but augmented reality overlays are only necessary at selected times), thereby saving working memory for other applications. Furthermore, a multiple process design is generally accepted as a more robust method of implementation as compared to a monolithic design, as a series of smaller modules are easier to debug, and any bugs that survive are isolated to a relatively limited functionality process that can be restarted.

Thus, there exists a need for methods of providing simultaneous access to a hardware data stream to multiple applications, improving upon and advancing the design of known hardware data stream access and sharing methods. Examples of new and useful methods for simultaneous hardware data stream access relevant to the needs existing in the field are discussed below.

SUMMARY

The present disclosure is directed to methods for providing simultaneous access to a hardware data stream to multiple applications. The first application to access a hardware device is responsible for providing and publishing an application programming interface (API) that provides access to the hardware device's data stream, which other applications can then call to gain access to the data stream. In some examples, the first application may be a server process or daemon, possibly included and launched as part of the operating system startup sequence, whose sole purpose is to manage the hardware device data stream and publish the API. In some further examples, the first application may not be a server or daemon, but instead may carry out user functionality unrelated to managing the hardware device, such as a user application.

DETAILED DESCRIPTION

Various disclosed examples may be implemented using electronic circuitry configured to perform one or more functions. For example, with some embodiments of the invention, the disclosed examples may be implemented using one or more application-specific integrated circuits (ASICs). More typically, however, components of various examples of the invention will be implemented using a programmable computing device executing firmware or software instructions, or by some combination of purpose-specific electronic circuitry and firmware or software instructions executing on a programmable computing device.

Accordingly,FIG. 1shows one illustrative example of a computer, computer101, which can be used to implement various embodiments of the invention. Computer101may be incorporated within a variety of consumer electronic devices, such as personal media players, cellular phones, smart phones, personal data assistants, global positioning system devices, and the like.

As seen in this figure, computer101has a computing unit103. Computing unit103typically includes a processing unit105and a system memory107. Processing unit105may be any type of processing device for executing software instructions, but will conventionally be a microprocessor device. System memory107may include both a read-only memory (ROM)109and a random access memory (RAM)111. As will be appreciated by those of ordinary skill in the art, both read-only memory (ROM)109and random access memory (RAM)111may store software instructions to be executed by processing unit105.

Processing unit105and system memory107are connected, either directly or indirectly, through a bus113or alternate communication structure to one or more peripheral devices. For example, processing unit105or system memory107may be directly or indirectly connected to additional memory storage, such as a hard disk drive117, a removable optical disk drive119, a removable magnetic disk drive125, and a flash memory card127. Processing unit105and system memory107also may be directly or indirectly connected to one or more input devices121and one or more output devices123. Input devices121may include, for example, a keyboard, touch screen, a remote control pad, a pointing device (such as a mouse, touchpad, stylus, trackball, or joystick), a scanner, one or more motion sensors, a position sensor such as a GPS receiver, a camera or a microphone. Output devices123may include, for example, a monitor display, an integrated display, television, printer, stereo, or speakers.

Still further, computing unit103will be directly or indirectly connected to one or more network interfaces115for communicating with a network. This type of network interface115is also sometimes referred to as a network adapter or network interface card (NIC). Network interface115translates data and control signals from computing unit103into network messages according to one or more communication protocols, such as the Transmission Control Protocol (TCP), the Internet Protocol (IP), and the User Datagram Protocol (UDP). These protocols are well known in the art, and thus will not be discussed here in more detail. An interface115may employ any suitable connection agent for connecting to a network, including, for example, a wireless transceiver, a power line adapter, a modem, or an Ethernet connection.

It should be appreciated that, in addition to the input, output and storage peripheral devices specifically listed above, the computing device may be connected to a variety of other peripheral devices, including some that may perform input, output and storage functions, or some combination thereof. For example, the computer101may be connected to a digital music player, such as an IPOD® brand digital music player or iOS or Android based smartphone. As known in the art, this type of digital music player can serve as both an output device for a computer (e.g., outputting music from a sound file or pictures from an image file) and a storage device.

In addition to a digital music player, computer101may be connected to or otherwise include one or more other peripheral devices, such as a telephone. The telephone may be, for example, a wireless “smart phone,” such as those featuring the Android or iOS operating systems. As known in the art, this type of telephone communicates through a wireless network using radio frequency transmissions. In addition to simple communication functionality, a “smart phone” may also provide a user with one or more data management functions, such as sending, receiving and viewing electronic messages (e.g., electronic mail messages, SMS text messages, etc.), recording or playing back sound files, recording or playing back image files (e.g., still picture or moving video image files), viewing and editing files with text (e.g., Microsoft Word or Excel files, or Adobe Acrobat files), etc. Because of the data management capability of this type of telephone, a user may connect the telephone with computer101so that their maintained data may be synchronized.

Of course, still other peripheral devices may be included with or otherwise connected to a computer101of the type illustrated inFIG. 1, as is well known in the art. In some cases, a peripheral device may be permanently or semi-permanently connected to computing unit103. For example, with many computers, computing unit103, hard disk drive117, removable optical disk drive119and a display are semi-permanently encased in a single housing.

Still other peripheral devices may be removably connected to computer101, however. Computer101may include, for example, one or more communication ports through which a peripheral device can be connected to computing unit103(either directly or indirectly through bus113). These communication ports may thus include a parallel bus port or a serial bus port, such as a serial bus port using the Universal Serial Bus (USB) standard or the IEEE 1394 High Speed Serial Bus standard (e.g., a Firewire port). Alternately or additionally, computer101may include a wireless data “port,” such as a Bluetooth® interface, a Wi-Fi interface, an infrared data port, or the like.

It should be appreciated that a computing device employed according to the various examples of the invention may include more components than computer101illustrated inFIG. 1, fewer components than computer101, or a different combination of components than computer101. Some implementations of the invention, for example, may employ one or more computing devices that are intended to have a very specific functionality, such as a digital music player or server computer. These computing devices may thus omit unnecessary peripherals, such as the network interface115, removable optical disk drive119, printers, scanners, external hard drives, etc. Some implementations of the invention may alternately or additionally employ computing devices that are intended to be capable of a wide variety of functions, such as a desktop or laptop personal computer. These computing devices may have any combination of peripheral devices or additional components as desired.

In many examples, computers may define mobile electronic devices, such as smartphones, tablet computers, or portable music players, often operating the iOS, Symbian, Windows-based (including Windows Mobile and Windows 8), or Android operating systems.

With reference toFIG. 2, an exemplary mobile device, mobile device200, may include a processor unit203(e.g., CPU) configured to execute instructions and to carry out operations associated with the mobile device. For example, using instructions retrieved from memory, the controller may control the reception and manipulation of input and output data between components of the mobile device. The controller can be implemented on a single chip, multiple chips or multiple electrical components. For example, various architectures can be used for the controller, including dedicated or embedded processor, single purpose processor, controller, ASIC, etc. By way of example, the controller may include microprocessors, DSP, A/D converters, D/A converters, compression, decompression, etc.

In most cases, the controller together with an operating system operates to execute computer code and produce and use data. The operating system may correspond to well-known operating systems such as iOS, Symbian, Windows-based (including Windows Mobile and Windows 8), or Android operating systems, or alternatively to special purpose operating system, such as those used for limited purpose appliance-type devices. The operating system, other computer code and data may reside within a system memory207that is operatively coupled to the controller. System memory207generally provides a place to store computer code and data that are used by the mobile device. By way of example, system memory207may include read-only memory (ROM)209, random-access memory (RAM)211, etc. Further, system memory207may retrieve data from storage units294, which may include a hard disk drive, flash memory, etc. In conjunction with system memory207, storage units294may include a removable storage device such as an optical disc player that receives and plays DVDs, or card slots for receiving mediums such as memory cards (or memory sticks).

Mobile device200also includes input devices221that are operatively coupled to processor unit203. Input devices221are configured to transfer data from the outside world into mobile device200. As shown, input devices221may correspond to both data entry mechanisms and data capture mechanisms. In particular, input devices221may include the following: touch sensing devices232such as touch screens, touch pads and touch sensing surfaces; mechanical actuators234such as button or wheels or hold switches; motion sensing devices236such as accelerometers; location detecting devices238such as global positioning satellite receivers, WiFi based location detection functionality, or cellular radio based location detection functionality; force sensing devices such as force sensitive displays and housings; image sensors; cameras and microphones. Input devices221may also include a clickable display actuator.

Mobile device200also includes various output devices223that are operatively coupled to processor unit203. Output devices223are configured to transfer data from mobile device200to the outside world. Output devices223may include a display unit292such as an LCD, speakers or jacks, audio/tactile feedback devices, light indicators, and the like.

Mobile device200also includes various communication devices246that are operatively coupled to the controller. Communication devices246may, for example, include both an I/O connection247that may be wired or wirelessly connected to selected devices such as through IR, USB, or Firewire protocols, a global positioning satellite receiver248, and a radio receiver250which may be configured to communicate over wireless phone and data connections. Communication devices246may also include a network interface252configured to communicate with a computer network through various means which may include wireless connectivity to a local wireless network, a wireless data connection to a cellular data network, a wired connection to a local or wide area computer network, or other suitable means for transmitting data over a computer network.

Mobile device200also includes a battery254and possibly a charging system. Battery254may be charged through a transformer and power cord or through a host device or through a docking station. In the cases of the docking station, the charging may be transmitted through electrical ports or possibly through an inductance charging means that does not require a physical electrical connection to be made.

The various aspects, features, embodiments or implementations of the invention described above can be used alone or in various combinations. The methods of this invention can be implemented by software, hardware or a combination of hardware and software. The invention can also be embodied as computer readable code on a computer readable medium. The computer readable medium is any data storage device that can store data which can thereafter be read by a computer system, including both transfer and non-transfer devices as defined above. Examples of the computer readable medium include read-only memory, random access memory, CD-ROMs, flash memory cards, DVDs, magnetic tape, optical data storage devices, and carrier waves. The computer readable medium can also be distributed over network-coupled computer systems so that the computer readable code is stored and executed in a distributed fashion.

It will be understood in this disclosure by a person skilled in the relevant art that the terms “application” and “process” may be used interchangeably, as both terms refer to a single program as recognized by an operating system, which includes its own memory space, stack, etc., as appropriate to the system architecture. An application or process may have multiple threads of execution, and can communicate with other applications or processes via well-known interprocess communication techniques, such as calls, message buffers, files, sockets, or any other interprocess communication facility provided by an operating system that is now known or subsequently developed.

With reference toFIGS. 3A-B, a first example of a method and implementing system for multiple access to a hardware data stream, method30for multiple access to a camera data stream will now be described. Method30functions to allow two or more applications to simultaneously access and utilize the data stream from a hardware device. In the example implementation described herein, such a data stream may come from a camera typical of those found on mobile devices such as mobile phones, tablets, and wearable computing devices like Google® Glass. Additionally or alternatively, method30can be used to provide simultaneous access to a data stream from any hardware device that otherwise would be exclusively available to only one application at a time. Other possible sources include audio reception devices such as microphone arrays, wireless receivers such as WiFi or Bluetooth receiver modules, motion sensors such as accelerometers, gyroscopes, magnetic compasses, and GPS receivers, or any other hardware device that can provide a continuous data stream that may be preferably subject to access by multiple applications. The reader is referred to the foregoing discussion of mobile device200and its associated peripherals for a more complete list.

Method30thus addresses many of the shortcomings existing with conventional methods of hardware data stream access. For example, by enabling simultaneous access to a camera, an application that processes the camera data stream to present an augmented reality overlay can analyze the camera feed and supply augmenting information while a second application that processes the data stream and performs gesture recognition is also enabled, and able to provide responses to user gestures and associated application control. The more robust software architecture of multiple independently-running processes can be readily implemented, with its associated advantages of easier debugging and crash isolation, as compared to a monolithic construction, with all possible functionality that may require use of the data stream included in a single process.

InFIG. 3A, method30includes step31, where a first application takes control of a hardware device that outputs a data stream, e.g. a camera. In step32, the first application initializes the hardware device, and begins receiving the device data stream. In step33, the first application establishes and advertises an application programming interface (API), which is made available to other applications. In step34, a second application needing access to the same hardware device accesses the device by interfacing with the API presented by the first application.

As described inFIGS. 3A and 3B, step31is performed by a first application, shown as first application303inFIG. 3B. In typical implementations, the system operating system arbitrates application access to hardware. The application thus receives control of the hardware device from the operating system, if available. Known operating systems keep track of the application that currently has control of a hardware device, and if the device is currently in use, will notify a requesting application of the device unavailability. In an implementation of the present invention, by providing and publishing a device access API, if the device is unavailable, the requesting application can learn the identity of the application presently in control of the requested hardware device from the operating system or other system reference list, and can then go to the controlling application and access the device through the published API, as in step34of method30.

As will be discussed further below, the first application can be implemented as a server daemon that runs with enhanced system privileges, which establishes the device API and then sits idle and provides data stream access to any and all user level applications that require the data stream under control of the server daemon. The server daemon can optionally be implemented as part of an operating system installation package, and be run upon operating system startup and initialization. The server daemon can also be monitored by the operating system, and relaunched if a crash or error is detected to ensure relatively continuous and seamless access to the controlled hardware data stream. Such an implementation has the advantage of keeping the device continually initialized and ready to access, and also can provide enhanced system security and integrity by keeping the API and device data stream walled off to a known system-level service. Thus, user applications implemented by third parties are not required to implement the API, preventing the possibility of inconsistent API implementations, the possibility of the introduction of bugs depending on the application supplying the API, and/or inconsistent device and application behavior depending on the set of applications accessing the device and the order of application launch. However, such a method of implementation does potentially consume more system resources than having each individual application provide the API, as a server daemon will consume its own application resources and impose system overhead (albeit minimal) if kept in a waiting state. Implementing the API at a user application level can potentially save system resources, which may be desirable in some mobile device implementations where system resources and processing power are limited, and acceptable system performance can only be achieved by keeping the running set of applications and services to a minimum. In such a case, the tradeoff between system stability and system performance may dictate user-level application implementation of the API.

For step32, the application either requests that the operating system initialize the hardware device via a device driver or other service, or, depending on the implementing platform and hardware, the application may handle initialization directly. Initialization steps may include changing the device's power state (e.g. from sleep to wake), obtaining information about device capabilities, running any diagnostics and/or self-tests, allocating any supporting system resources, such as memory blocks, buffers, I/O ports, system interrupts, etc., and beginning to receive the device data stream. Actual initialization steps will depend upon the hardware device being utilized. In the example implementation where the hardware device is a camera, initialization steps may include receiving camera information such as camera resolution, pixel aspect ratio, frame rate, compression type (if compression is implemented in camera hardware), data rate, image format, and color space.

In step33, the application publishes and advertises the API for the device, enabling access to the device to any other application by way of calls to the API. The API ideally makes available at least a minimal set of device features necessary for other applications to utilize basic device functionality. Such minimal sets may conform to accepted industry standards for particular types of devices, e.g. TWAIN for scanners, USB specifications for I/O and mass storage. For the example implementation using a camera, API capabilities may include the ability to tell a requesting application about camera information such as the pixel format, image size, and frame rate (if the data stream is a video format), the ability to notify the requesting application of changes to those parameters mid-stream, provisions for receiving the data stream from the camera consistent with the camera parameters specified by the API, and providing a time stamp of the image or video capture. The API can also optionally provide means to request changes to camera specifications if supported; for example, requesting a change in camera resolution or field of view.

Finally, in step34a second application uses this API to access the hardware and the associated data stream via the first application. Provided it is supported by the API, this access may include requests for changes to the device state or controls. The first application responds to API calls and requests as appropriate. If the API supports controlling or changing the device state, the first application may need to arbitrate such requests depending on the first application's device data stream needs, and whether those needs conflict with any other requesting application needs. For example, with a camera device, if resolution or frame rate changes are supported and the first application controlling the camera requires a specific resolution and frame rate, it may be required to accommodate a different requested frame rate or resolution or notify the second requesting application of the unavailability of the requested frame rate or resolution.

ConsideringFIG. 3B, an example system300that implements method30is depicted. System300is comprised of a camera301recognized and in communication with an operating system302. First Application303performs the first application functions as detailed in the above description of method30, including the provisioning of the API304, which is then accessed by one or more second applications, depicted inFIG. 3Bas apps305, apps2through N.

Turning attention toFIG. 4, a second example of a system40implementing a variant on method30above will now be described. System40includes many similar or identical features to a system implementing method30. Thus, for the sake of brevity, each feature of system40will not be redundantly explained. Rather, key distinctions between system40and method30will be described in detail and the reader should reference the discussion above for features substantially similar between the two implementing systems.

As can be seen inFIG. 4, system40includes a camera41, which is recognized by an operating system42. A control process43is in communication with camera41via operating system42. Control process43provides an API44, which in turn is accessed by one or more apps45that need access to the data stream of camera41.

In the example system40, control process43is an application that performs the steps that the first application described above in connection with method30performs, namely, obtaining control of the camera41, performing initialization and data stream management, and API advertising and publishing, described above as steps31-33. In this implementation, control process43is a server daemon as described above; control process43's sole function is the control and management of the camera, and acting as the provider of the API44to apps that require access to the data stream of camera41. In this sense, it differs from the first application303depicted inFIG. 3Binsofar as control process43does not have any functionality unrelated to providing API44, e.g. it does not act separately on the camera data stream to perform functions such as providing an augmented reality overlay or handling gesture recognition. It will be appreciated by a person having skill in the relevant art that the functionality of control process43may, in some implementations, be performed by operating system42, which may obviate the need for control process43to be implemented as a separately running process.

ConsideringFIG. 5, an example implementation of a system where the operating system either does not act as a hardware arbitrator (e.g. similar to implementations of MS-DOS, where applications could freely access hardware directly), the operating system acts as the first application to provide the API, or allows applications to directly talk to device drivers, is depicted.FIG. 5also demonstrates the data flow from device to application once one of the disclosed methods has been initiated. System500is comprised of camera510, which is optionally part of computer520, as might be found in a mobile device200. Data stream530is supplied to first application540, which in turn provides data steam530via the API550. Second and subsequent processes560can in turn access data stream or copies of data stream570via API550.

FIGS. 6A and 6Bdepict methods by which first application540and API550can provide access to data stream530to multiple applications. Due to the nature of multiprocessing systems, multiple applications may not be executing simultaneously, or may not be processing at the same speed. Accordingly, data stream access will not typically be synchronized between accessing applications, and each application will need sequential data stream access to ensure correct processing. In both figures, camera510writes its data stream into a primary buffer610.FIG. 6Ashows a possible implementation where first application540makes primary buffer610directly accessible via API550to all applications utilizing the data stream. First application540and subsequent processes560are all depicted accessing primary buffer610. First application540and subsequent processes560may each be using a slightly different portion of the data stream provided in primary buffer610. In this implementation, API550keeps track of the position in the data stream in primary buffer610for each respective accessing subsequent process560, and returns data from primary buffer610appropriate to the current data stream location associated with each subsequent process560. By using a single shared primary buffer610, memory space is conserved. However, if integrity of the data stream is to be maintained, only camera510can be permitted to write to primary buffer610; first application540and subsequent processes560may only read from primary buffer610. Processing of the data stream that requires writing will necessitate that a copy of the processed data be made from primary buffer610.

FIG. 6Bshows an alternative variation for buffering the data stream between multiple applications. InFIG. 6B, each subsequent process560is accorded its own copy of primary buffer620. Each time a new subsequent process560calls API550and requests access to camera510, API550(and/or first application540) creates a new copy of primary buffer620, and directs camera510to write a copy of the data stream to each of primary buffer610and copy of primary buffer620. As each of first application540and subsequent processes560looks to its own copy of the data stream, each of the primary buffer610and copy of primary buffer620can be read and written to by its associated process.

It will be appreciated by a person skilled in the relevant art that primary buffer610and each copy of primary buffer620can be filled either directly by camera510, if the hardware and device drivers permit architecture such as Direct Memory Access, or by the operating system, or by first application540as part of implementing API550. Each of primary buffer610and copy of primary buffer620can be implemented as a linear buffer that is sequentially filled by the data stream, or a circular buffer, where a fixed segment of memory is successively overwritten by the data stream as it repeatedly reaches the end of the fixed segment of memory, or any other method of hardware buffer implementation now known or later developed in the art. Each of these methods has its advantages and disadvantages: a linear buffer, while allowing access to a growing history of the data stream (useful for scrolling back through video or doing replays, or for performing change analysis of the current state of the data stream relative to its previous condition), is also potentially very memory intensive and, practically speaking, eventually reaches system capacity limits. A circular buffer, in contrast, is memory-efficient, but is limited in its ability to support analysis of the current data stream vis-a-vis historical data. Yet another implementation method may involve something of a hybrid; a flexibly sized buffer can be provided, where the start of the buffer is marked where the hardware is writing the data stream, and the end is where the accessing application is currently reading. As the accessing application reads the data stream, it is deleted, and the space freed up for the hardware to write incoming data. Such an implementation could run into capacity limitations if the reading application fails to keep up with the speed at which the hardware writes the data stream to the buffer.

It will also be appreciated that each application can, if necessary, copy data from primary buffer610or copy of primary buffer620to its own respective memory space to provide for historical data retention, especially where primary buffer610and copies of primary buffer620are implemented as circular buffers.