 |
Description  |
|
|
FIELD OF THE INVENTION
This invention relates to the field of data processing, and, more
particularly, to a personal computer based multimedia system in which data
streaming occurs in a continuous, real-time fashion under the control of a
multitasking operating system.
RELATED APPLICATION
The present application is related to application Ser. No. 07/815,652, now
U.S. Pat. No. 5,333,299, filed on even date herewith, for "SYNCHRONIZATION
TECHNIQUES FOR MULTIMEDIA DATA STREAMS" M. Koval et. al, and assigned to
the assignee of the present application.
BACKGROUND OF THE INVENTION
A multimedia system is designed to present various multimedia materials in
various combinations of text, graphics, video, image, animation, sound,
etc. Such a system is a combination of hardware and software. The hardware
includes a personal computer to which various multimedia devices can be
attached. The hardware runs under the control of an operating system and
multimedia application programs.
Multimedia applications impose heavy demands on the operating system to
move large amounts of data from device to device, from system memory to a
device, or vice-versa, in a continuous, real-time manner. Multimedia
systems must support a flexible yet consistent means for transporting
these large data objects, and control this activity accurately in real
time. Adding new multimedia devices and data types should require minimal,
if any, new system extension code. The total real memory requirements at
run time must be minimized, so that system performance is not degraded.
Also, support for complex data types and devices that manipulate
interleaved data objects, must be provided. Finally, it must be possible
to implement each multimedia data transport control means at the most
appropriate system privilege level.
Operating system extensions that support multimedia data types and devices
must provide the ability to control the many different multimedia I/O
devices and to transport, or stream, large multimedia data objects within
real-time constraints.
Multimedia applications control the input and output of large amounts of
data, including the continual display of bitmaps, output of digitized
audio waveforms or MIDI audio sequences, input of digitized audio from an
analog microphone or line source, etc. The application controls all this
data flow in the context of a real-time clock: certain events under
program control must occur at explicitly defined points in time, and these
times are defined very accurately (e.g., in milliseconds).
Given only the OS/2 control program services (DOS calls, or similar
services in other operating systems such as AIX or UNIX), controlling this
level of function at the application programming interface would require
highly complex, device-specific, data transport control modules. Even if
such modules were created, there would be no guarantee that the threads
controlling each I/O operation would execute within its required time
interval. To address this problem, the application would need to add
sophisticated semaphore logic and make the I/O control threads time
critical. The nature of multitasking operating systems, combined with the
high data throughput load common to multimedia applications, will at times
prevent data being delivered to the destination device within the allotted
time interval. Failing to meet these real-time requirements will result in
visible or audible defects in the multimedia presentation.
The real-time, continuous, high-volume data transport requirements present
a set of interdependent problems that a generalized transport mechanism
must solve:
1. Throughput-intensive Applications With Very Heavy Data I/O Demands
Uncompressed, digital motion video at 640.times.480.times.16 resolution
requires approximately 3 Mb/sec. Even highly compressed, a digital motion
video data stream can require transferring 60 Kb/sec. Adding 8 or 16-bit
digital audio waveform data transfer into the scenario can increase the
throughput load to 80 Kb/sec or greater. Supporting this throughput load
continually while the multitasking system also performs other application
functions such as file I/O and keyboard/mouse device control is the most
important requirement for a generalized data streaming mechanism. But
because the multimedia data presentations at the user interface (auditory
and visual) are real-time dependant, these data transfers must occur
within very tight real-time constraints.
2. Control of Multiple Different Hardware I/O Devices
Multimedia applications typically control a variety of I/O devices to
manage presentations in the audio and video domains of the user interface.
Audio devices that support waveform capture and playback, digital audio
compact disc playback, Musical Instrument Digital Interface (MIDI) I/O,
and voice-generation may be involved. Similarly, video devices that
support NTSC (or PAL) video digitization, compression/decompression, and
capture are routinely involved in multimedia presentation and/or authoring
scenarios. The generalized data streaming mechanism must support these and
future multimedia devices in a flexible manner, without requiring major
modifications of the multimedia system extensions.
3. Provide Consistent Control Services Across Devices and Data Types
The data streaming mechanism must be controlled through services that are
consistent across the different devices and data types involved in
multimedia authoring and presentation scenarios. When new data types are
introduced, as multimedia data standards evolve, this generalized
streaming mechanism must not be substantially impacted. The control
services must provide for easily incorporating new data types into
existing applications. Likewise, these services must allow for seamlessly
adding new I/O device types and capabilities, without impacting existing
applications or requiring major revisions of the multimedia extensions.
4. Provide Identical Control Services at Multiple System Privilege Levels
Multimedia data objects may originate (or terminate) at a hardware I/O
device, or in system (or application) memory. Where data streaming
originates or terminates with a hardware device, the transport mechanism
must be able to control behavior of the hardware device indirectly, rather
than taking on direct control of the device, and thereby becoming
device-specific itself. However, the nature of operating systems that
support multiple privilege (or protection) levels--a common practice in
modern operating systems--requires that for optimal performance the
transport mechanism ("stream handler") should be attached to the device's
native physical device driver at the highest system privilege level. This
is the execution level where hardware device drivers typically run.
Although it is desirable, for performance reasons, to create device driver
level stream handlers, the stream handler device driver must not become
hardware dependent itself. All hardware-specific code must be encapsulated
in the device's native physical device driver. Alternatively, where no
physical device is involved as the source or destination of the data
stream, the stream handler may be implemented at a lower privilege level
and still achieve optimal performance. Because the data transport
mechanism is thus distributed across multiple privilege layers, identical
stream control services must be provided at any level where the stream
handlers execute. Multiple entry points at different privilege levels
should be provided without incorporating redundant code.
5. Ability to Extend to New Devices/Data Types With Minimal Impact
New multimedia data standards and device types are being created almost
continually. As this situation will persist for the indefinite future, the
data transport mechanism must be able to easily and seamlessly adapt to
support the new devices and data types.
6. Requirements for Physical Memory During Streaming Must be Kept to a
Minimum
Despite the heavy throughput load imposed by multimedia applications, there
should be conservation of memory resources at all times when data
streaming is underway. Buffer management services should be provided so
that applications do not need to become physical memory managers. However,
since some applications create multimedia data objects in memory, these
applications may need to have direct control over the memory buffers. This
capability should be seamlessly supported by the data streaming mechanism
and its control services.
7. CPU Loading Must be Kept to a Minimum During Streaming
Just as memory is a scarce resource that must be carefully managed, CPU
cycles are another critical resource that cannot be squandered during
multimedia application execution. The data streaming mechanism must keep
CPU loads to a minimum by exploiting any direct hardware-to-hardware data
transport capabilities (e.g., bus master data transfers). In addition,
interrupt-driven device I/O should be exploited wherever possible to
reduce CPU load, rather than allowing the data transport mechanism to
control devices using device-polling techniques.
The following definitions are provided to establish a framework within
which the present invention can be described:
Data Stream--A software means for data transfer through a data channel, in
a continuous manner, from a source device (or memory address) to a target
device (or memory address).
Dynamic Link Library (DLL)--In the OS/2 architecture, a 16-bit or 32-bit
executable module that executes at privilege levels 2 or 3, and is loaded
into memory in order to resolve the external references of another
executable (e.g., .EXE) module. A DLL can execute only in a task context.
Physical Device Driver (PDD)--In the OS/2 architecture, a 16-bit executable
module which executes at privilege level 0 (ring 0) and typically controls
the operations of an I/O device. A PDD can execute in either a task
context or a hardware interrupt context.
Stream--To continuously transfer data from a source to a destination (or
target).
SUMMARY OF THE INVENTION
The invention provides an improved, generalized, data streaming, multimedia
data transport mechanism between various I/O devices, application memory,
and system memory that is designed to solve the problems and satisfy the
requirements noted above. The transport mechanism is embodied within
extensions to a multitasking operating system which incorporates multiple
execution privilege levels. The mechanism supports continuous, real-time,
data transfer referred to as data streaming.
DRAWINGS
Other objects and advantages of the invention will be apparent from the
following description taken in connection with the accompanying drawings
wherein:
FIG. 1 is a block diagram of a data processing system embodying the
invention;
FIG. 2 is a block diagram of sync/stream subsystem architecture embodied in
the system shown in FIG. 1;
FIG. 3 is a block diagram illustrating a generalized model of data
streaming;
FIG. 4 is a flow chart of source stream handler operations:
FIG. 5 is a flow chart of one type of target stream handling operations;
FIG. 6 is a flow chart of another type of target stream handling
operations;
FIG. 7 is a diagram illustrating unified and split data buffering;
FIG. 8 is a diagram of buffering data structures;
FIGS. 9-19 are flow charts of interlocking sync/stream buffer management
operations;
FIG. 20 is a flow chart of sync/stream manager create stream operations;
FIG. 21 is a flow chart of sync/stream manager start stream operations;
FIG. 22 is a diagram of event data structures;
FIG. 23 is a flow chart of event enabling operations;
FIG. 24 is a flow chart how operations proceed from an application program
to the sync/stream manager; and
FIG. 25 is a flow chart of an example of event detection operations.
DETAILED DESCRIPTION
Multimedia System
Referring now to the drawings, and first to FIG. 1, there is shown an
exemplary data processing system comprising a personal computer 10
operable under a multitasking operating system such as OS/2 Version 2.0,
to execute application programs. Computer 10 comprises a microprocessor 12
connected to a local bus 14 which, in turn, is connected to a bus
interface controller (BIC) 16, a math coprocessor 18, and a small computer
system interface (SCSI) adapter 20. Microprocessor 12 is preferably one of
the family of 80xxx microprocessors, such as an 80386 or a 80486
microprocessor, and local bus 14 includes conventional data, address, and
control lines conforming to the architecture of such processor. Adapter 20
is also connected to a SCSI bus 22 which is connected to a SCSI hard drive
(HD) 24 designated as the C:drive, the bus also being connectable to other
SCSI devices (not shown). Adapter 20 is also connected to a NVRAM 30 and
to a read only memory (ROM) 32.
BIC 16 performs two primary functions, one being that of a memory
controller for accessing a main memory 36 and a ROM 38. Main memory 16 is
a dynamic random access memory (RAM) that comprises stores data and
programs for execution by microprocessor 12 and math coprocessor 18. ROM
38 stores a POST program 40 and a BIOS 42. POST program 40 performs a
standard power-on, self-test of the system when computer 10 is started by
turning the power on or by a keyboard reset. An address and control bus 37
connects BIC 16 with memory 36 and ROM 38. A data bus 39 connects memory
36 and ROM 38 with a data buffer 41 that is further connected to data bus
14D of bus 14. Control lines 45 interconnect BIC 16 and data buffer 41.
The other primary function of BIC 16 is to interface between bus 14 and an
I/O bus 44 designed in conformance with Micro Channel (MC) architecture.
Bus 44 is further connected to an input/output controller (IOC) 46, a
video signal processor (VSP) 48, a digital signal processor (DSP) 49, and
a plurality of expansion connectors (EC) or slots 50. VSP 48 is further
connected to a video RAM (VRAM) 60 and a multiplexor (MUX) 62. VRAM 60
stores text and graphic information for controlling what appears on the
screen of a monitor 68. MUX 62 is further connected to a digital to analog
converter (DAC) 68 and to a connector or terminal 70 that is connectable
to a video feature bus (VFB). DAC 66 is connected to monitor 68 that
provides a conventional output screen or display for viewing by a user.
IOC 46 controls operation of plurality of I/O devices including a floppy
disc drive 72 designated as the A:drive, a printer 74, and a keyboard 76.
Drive 72 comprises a controller (not shown) and a removable floppy disc or
diskette 73. IOC 46 also is connected to a mouse connector 78, a serial
port connector 80, and a speaker connector 82 which allow various optional
devices to be connected into the system.
DSP 49 is further connected to an instruction RAM 84, a data RAM 96, an
analog interface controller (AIC) 88, and an audio controller (90). RAMS
84 and 86 respectively hold instructions and data used by DSP 49 for
processing signals. Audio controller 90 controls various audio inputs and
outputs and is connected to a plurality of connectors 92 by which various
devices can be connected to the system. Such devices include a headphone,
a microphone, a speaker, a musical instrument digitizing interface (MIDI),
and devices requiring an audio line-in and line-out functions. Various
other multimedia devices (MMD) 96 can be also attached to the system
through an EC 50 and adapter card 94.
Memory 36 stores various programs for execution in the system, which
programs include application programs 100, including multimedia
application programs (MMAP) 102, and an operating system 98 having
extensions thereto including a sync/stream sub-system (S/SS) 104. It is to
be noted that while FIG. 1 illustrates an exemplary multimedia system, the
operating system is general purpose and is designed to run or control data
processing systems having configurations that are different from the one
shown in FIG. 1. The invention is embodied primarily in S/SS 104 and its
interaction with operating system 100, which will now be described.
Sync/Stream Sub-System
Referring to FIG. 2, multimedia application programs 102 execute at a layer
above operating system 98 and communicate through multimedia control
interface (MCI) by sending MCI commands for controlling devices in the
multimedia environment. Some of the basic commands are pause, play,
record, resume, seek, save, set, stop, etc. Such commands are routed by
the operating system 98 to a media device manager (MDM) 106. The
application programming model for MMAPs is a logical extension of the OS/2
Presentation Manager programming model, incorporating both object oriented
messaging constructs and procedural (call and return) programming
interfaces. The MCI provides a view to application developers and users
similar to that of a video and audio home entertainment system. Operations
are performed by controlling the processors of media information known as
media devices. Media devices can be internal or external hardware devices,
or they can be software libraries that perform a defined set of operations
by manipulating lower-level hardware components and system software
functions. Multiple media devices may be included in a scenario, and they
can be allocated and controlled as a group for the purpose of synchronized
playback.
Multimedia applications must control two aspects of real time system
behavior, the transfer of large amounts of data from one device to another
and the synchronization of events that are related. Events under the
control of the program must be perceived to be under the direct control of
the user, and the underlying system functions facilitate and ensure that
these events occur in a predictable, real-time manner. Multimedia
application authors should write programs that operate on a real-time
clock basis, rather than an approximate clock that could allow events to
occur within windows of probability.
The MCI has two levels of dynamic link libraries (DLLs) comprising MDM 106
and media drivers including an audio media driver 108 and a MIDI media
driver 110. MDM 106 provides resource management for media devices. It
resolves contention for access to media devices and provides the
application developer a view of resources that is independent of hardware.
The media drivers are dynamic link libraries that implement the
functionality of media devices. Media drivers invoke the services of
hardware devices or software to implement their functionality. The media
drivers do not directly control the hardware devices. Instead, they pass
commands to S/SS 104 through a stream programming interface (SPI) 112 to a
sync/stream manager (SSM) 114 which controls synchronization and streaming
activities. SSM 114 performs two primary functions, the first being to
control data streaming to provide continuous, real-time data streaming the
inventive aspects of which are the subject of this present application.
The second primary function involves synchronizing data streams and
details of such function are covered by the above-identified related
application.
Stream handlers are required at both the system kernel level and the
application level. Some data streams are best controlled by a direct
connection between a stream handler and the physical device driver at the
Ring 0 priority level Such stream handler communicates with the PDD using
a common interface based on OS/2 Interdevice Driver Communication (IDC).
Other data streams are not associated with a data source or target that
can be mapped to a specific physical device and can be controlled at the
Ring 3 priority level by a DLL. Dotted line 113 generally indicates which
items operate at the different priority levels. Within SSM 114, some
routines operate at one level and other routines operate at the other
level, as appropriate to the task at hand.
Each stream handler is programmable and is capable of streaming according
to stream protocols. From the perspective of SSM 114, all stream handlers
have similar responsibilities. Each handler is designed to be the source
or target for one or more data streams where each data stream moves data
independently, Manager 114 is responsible for connecting a stream source
to an appropriate stream target, for maintaining data flow, and cleaning
up the various resources when the stream has ended. Further, the stream
handlers are not device dependent modules. Although each stream handler
supports streaming data of specific predefined types, data is passed form
one handler to the next without any knowledge of hardware behavior. Also,
audio stream handler 134 can communicate with any compatible audio device
PDD in a completely hardware independent manner. To be compatible, the PDD
must conform to the IDC interface as well as to the standard audio device
driver interface IOCTL. Thus as shown, stream manager 114 interacts with a
plurality of stream handler dynamic link libraries (DLL) 116-126 which
respectively are MIDI mapper, CD/DA, memory, split stream, CD-ROM/XA, and
file system, stream handlers. File system stream handler DLL 128 calls a
multimedia I/O (MMIO) manager for accessing a file system 130.
Stream manager 114 also interacts through stream manager helpers 133 with
an audio stream handler physical device driver (PDD) 134 that selectively
accesses physical devices through a stream handler/PDD interface 136 and a
plurality of PDDs 138-144. Stream manager 114 can also interact with
interface 136 through inter-device communication (IDC) interfaces 146.
FIG. 3 is a generalized model of data streaming operations the details of
which are discussed relative to the flow charts and data structures in the
remaining figures. FIG. 3 shows generally a single data stream 151 and how
data flows or is transported under the control of stream manager 114, and
source and target stream handlers 152 and 154. A plurality of stream
buffers 156 are allocated in memory for use in streaming. Buffers 156 are
filled with stream data from a source device 158 and are emptied of stream
data by transmitting the data to a target device 160. Data stream 151
comprises two portions, source stream data 153 and target stream data 155.
The data path for the source stream data is from source 16, through source
PDD 162, and through stream handler 152 to buffers 156. The data path for
the target stream data 155 is from buffers 156, through target stream
handler 154, through target PDD 164, and to target device 160. Source
stream handler 152 actuates a source PDD 162 which in turn controls
operation of the source device. Target stream handler 154 actuates a
target PDD 164 which controls target device 160. The general objective is
for the source stream handler 152 to fill at least two of stream buffers
156 before the target device is started, and, once the target device has
started, to thereafter keep ahead of the target device by filling buffers,
until the complete source data has been transferred. After the buffers ar
filled, the target stream handler can then obtain target data therefrom
and transfer it to the target device.
Media driver 108 interacts with SPI interface 112 by sending SPI functions
or calls and receiving stream event notifications. Manager 114 interprets
the SPI calls and in response thereto performs the desired functions by
interacting with the stream handlers by sending system helper commands
SHCs to the handlers and receiving stream manager helpers SMH calls from
the handlers. Media driver 108 can also directly control PDD 164 by
issuing control functions defined by standard IOCTL commands. The
principal SPI calls related to the invention are SpiCreateSream and
SpiStartStream which respectively setup up the desired stream(s) and then
start the data streaming, as discussed in more detail below with reference
to FIGS. 20 and 21. Should there be plural streams that must be
synchronized, a SpiEnableSync call is made, as more fully discussed in the
related application.
FIG. 4 illustrates what happens when a stream handler command SHC.CREATE is
executed. However, before describing that, it might be useful to
understand how that point is reached relative to an application program.
First the MMAP issues an MCI call to create a data stream. Such call is
analyzed by the OS in 98 which sends information to media device manager
106. This manager then selects the appropriate media driver that sends an
SpiCreateStream call to sync/stream manager 114 which then issues the
SHC.CREATE command to the appropriate stream handler.
FIG. 4 illustrates what happens when the SHC.CREATE command is executed by
a DLL source stream handler 152. First, step 201 creates a thread under
the OS which will be controlled by the multitasking features of the OS.
Step 202 assigns a priority level to the thread as appropriate to the task
to be performed, and then the thread is blocked on a semaphore in step 203
and goes to "sleep". The priority level may be used to control the rate at
which the OS dispatches and executes the thread. If discontinuities arise,
priority levels may be adjusted.
It is to be noted that in accordance with the standard operation of OS/2,
the threads are treated as individual tasks, and control returns to the OS
when the threads are blocked, when calls are made, when returns are made,
etc. This allows the operating system to execute other tasks in the system
and to return to the streaming threads, on a multitasking basis. It should
also be noted that several connectors appear in the drawings, the
connectors including a circled numeral along with arrows indicating the
direction of program flow. For example, connector 1 appears in both FIG. 4
and FIG. 20. In FIG. 20 the connector includes both call and return
arrows, whereas the connector 1 in FIG. 4 includes only a call arrow
indicating the routine is being called elsewhere. The other connectors can
be interpreted in the same manner.
In response to the start command being made in the application program,
manager 114 sends a SHC.START command first to the source thread handler
in 206 (FIG. 4) and then to the target stream handler. The source stream
handler needs to be started first to fill stream buffers before the target
handler can use the data being transferred thereto. In response to such
command, the source stream handler in step 208 unblocks the source thread.
In response to being unblocked or awakened, source thread then requests,
in step 216, an empty buffer from manager 114. If a buffer is not
available, as determined in step 218, step 220 then blocks the thread
again. If an empty buffer is available, then step 222 reads data from the
source device and fills the buffer. Step 224 then returns the filled
buffer to manager 114. Step 226 decides if any more buffers need filling.
If so, a branch is made back to step 216 and a loop is formed from steps
216-226 which loop is broken when step 226 decides no more buffers need
filling. Then, the thread is blocked. Once the streaming operation has
been started, buffer filling process repeats until the end of the source
file is reached at which point the source thread quiesces. Event detection
can be inserted in the sequence of operation at any of the points
indicated with an asterisk in FIG. 4, e.g., using cue point detection to
keep track of time where time is determined by the rate of data
transferred. Event detection can also be used in many of the routines that
follow.
FIG. 5 illustrates operating the a DLL target stream handler at ring 3
priority level. Target stream handler receives from manager 114 an
SHC.CREATE to also create a target data stream and it first creates a
target stream thread in step 230, assigns a priority to the thread in step
232, and blocks the target thread on a semaphore in step 234. When the
target thread is awakened by manager 114 issuing a SHC.START command in
step 236, the target thread is unblocked in step 238 to awaken the thread
in step 240. Step 242 attempts to get a full buffer from the data stream.
Step 244 checks to see if a buffer is obtained, and, if not, step 246
blocks the target thread. If a full buffer was obtained, step 248 writes
the data in the buffer to the target device and then returns an empty
buffer in step 250 to manager 114. Step 252 checks to see if the buffer is
the last buffer in the data stream i.e. has the EOS been reached. If not,
a branch is made back to step 242 to repeat the process of getting a full
buffer. The loop repeats until the end of stream is detected, whereupon
step 244 ends the thread.
FIG. 6, to which reference is now directed, shows a target stream handler
implemented in a physical device driver at a ring 0 priority level. When
an SHC.CREATE command is received in step 256, step 258 sets up the stream
data structures and step 260 initializes the target device. A return is
made in step 261. When the stream is started in step 262, a request for a
full buffer is made in step 264 to manager 114. Step 266 determines if a
buffer was given. If so, step 268 initiates a Write I/O and a return is
made by step 270. If no buffer was returned as a result of step 272
determining there was an error underrun, step 274 reports the error and
then a return is made.
When the I/O operation is completed by writing and emptying the buffer,
step 272 then make an interrupt which is handled by an interrupt handler
in step 274. If the I/O operation was done without error, step 278 then
returns the empty buffer to manager 114, and a branch is made to step 264
to repeat the process. If an error occurred during the I/O operation, step
280 reports the error and a return is made in step 282. A source stream
handler operating a Ring 0 priority level performs operations the same as
shown in FIG. 6 except that it gets an empty buffer and returns a full
buffer.
There are two types of data files and streams which can be used, a unified
or non-interleaved stream and a split or interleaved stream. A unified
data stream and file contains data of only one type, e.g., only audio
data. A split stream contains data of more than one type, e.g, both audio
data and video data. An example is the type of file commonly created for
CD-ROM devices. FIG. 7 shows examples illustrating the different types.
File 286 represents a unified file containing only audio data of a given
type. Such file is read into a plurality of buffers B1-B3, by filling
buffer B1 with a first section of the audio data, then B2 is filled with
the next section of audio data, etc. File 288 is a split or interleaved
file having a plurality of sections of interleaved audio and video data.
The sections are paired so that the audio corresponds to the video being
presented. When such data is transferred into associated buffers B4-B6, it
is done so as records. Thus, the first audio section A1 becomes audio
record AR1 in B4, the first video section V1 becomes video record VR1, in
B4, and the second audio section A@ becomes AR2 in B4. Next, sections V2,
A3, and V3 are transferred to buffer B5 as records VR2, AR3, and VR3.
Buffer B6 is similarly filled with AR4 and VR4. Quite obviously, in this
example, the buffers B4-B6 are each of a size to hold three records.
When streams are created by manager 114, a plurality of buffers are
allocated to each stream and, data structures are formed containing data
used to manage the streams. Referring to FIG. 8, for each stream, a buffer
directory structure BDS is created which is added to a linked list of BDSs
of other streams. A chain of buffer control blocks is created for each
stream, there being one BCB for each buffer allocated to the stream. As
shown, BDS1 is created for stream #1 is chained to three RCBs RCB1-RCB3
which respectively are associated with and point to three buffers B1-B3
allocated to stream #1.
Each BDS contains a plurality of fields for storing information on the
number of buffers allocated to the stream, the state of the stream, the
number of records in a buffer (for split streams), a pointer 200 to the
RCB of the first full buffer, a pointer 202 to the RCB of an empty buffer,
and a pointer 204 to the next BDS in the list. The different states of a
stream include, running, stopped, paused, and prerolled or primed. The
latter is an option which allows for quick starts by filling all of the
buffers from the source prior to starting the target device. Each BCB
stores information including the number of bytes in the buffer, the number
of records in a split stream buffer, a pointer 206 to the buffer, and
pointer 208 to the next BCB in the chain, and pointers to the head and
tail of the RCB chain.
Streams #3 and #4 illustrate buffering data structures for split streams
using the example in FIG. 7. A BDS is set up for each data type in the
split stream. BDS3 is setup for audio data and BDS4 is set up for the
video data. As buffer B4 is filled with the three records, two record
control blocks RCB1 and RCB2 are created and filled to indicate the
offsets into B1 of audio records AR1 and AR2, and the lengths thereof.
BCB4 is set to indicated there are two records in buffer B1. Concurrently,
RCB3 is also created to indicated the offset into buffer B1 of video
record VR1 and the length thereof. The number of records field in BCB7 is
set to one corresponding to only one video record being stored therein.
Additional BCBs and RCBs are similarly created and filled for the
remaining buffers allocated to the split stream. Also for a split stream,
one BDS is designated owner and any remaining BDS is considered a user.
The linked lists contains pointers 210 from each user BDS to the
associated owner BDS. Further there are the following pointers: a pointer
212 from a user BCB to the owner BCB; and pointers 214 from a BCB to RCBs
chained thereto.
SSM 114 is called from the stream handlers using stream manager helpers
(SMHs). Referring to FIG. 9, when manager 114 receives a SMH.NOTIFY call
at 220 to get or return a buffer or a record, the call parameters are
verified in step 222, and step 224 determines whether the caller is a
source stream handler or a target stream handler. If it is a source system
handler, step 226 determines if the user or application is supplying
buffers. If so, step 228 calls the GiveBuf routine and upon being returned
to in step 228, step 230 returns to the caller. If step 226 results in a
negative determination, step 232 decides if the a full buffer is being
returned. If so, step 234 then calls ReturnFull routine and upon its
return, a return is made through step 230 when a full buffer is returned
or step 236 is executed to determine if the request is for an empty
buffer. Step 236 is also executed when step 232 determines the request is
not for a full buffer. If 236 makes a positive determination, step 238
then calls the GetEmpty routine and returns via 230
If step 224 indicates the caller is not a source stream handler, meaning it
must be a target one, step 240 determines if an empty buffer is being
returned. If so, step 242 the calls ReturnEmpty routine and step 244
determines if the request is for a full buffer. If not, a return is made
via 230. If so, step 246 calls the GetFull routine before returning via
230. If step 240 results in a negative determination, step 248 checks to
see if the end of the stream has been reached. If not, step 244 proceeds
as before. If so, step 250 resets the buffers, and step 252 reports an end
of stream event to the application before passing to step 244.
FIG. 10 shows the GiveBuf routine 228 in which step 554 checks to see if
there is any remaining buffer to give. If not, a return is made in step
256. If there is such a buffer, step 257 checks to see if an empty pointer
points to an empty BCB. If one is pointed to, step 258 calls MapUserBuffer
routine 258. Afterward, step 260 checks for errors. If none occurred, step
262 saves buffer attributes and step 264 checks to see if the end of the
stream has been reached. If not, step 266 checks to see if a
Target.is.waiting flag is set. If not, a loop is made back to step 254. If
step 256 produces a "no" answer, step 268 sets Source.is.waiting flag on
and step 270 calls a CheckPreroll routine. Step 272 checks for error. If
none, control passes to step 254. If an error is noted in 272, step 274
sets error flag indicating too many buffers and a return is made by 256.
If step 264 answers positive, step 276 calls check-preroll routine and
then goes to step 254. If step 266 is positive, step 278 sends a helper
command to start the target stream handler.
Referring to FIG. 11, when the ReturnFull routine is called to obtain a
full buffer, step 280 first checks to see if there are any full buffers
available. If none is, a return 282 is made. Is there is a full buffer,
step 284 searches the chain of BCBs for the full buffer address and step
286 checks if a full buffer is found and if the source owns it. If not,
step 288 sets error flag to indicate invalid buffer returned, and then
return 282 is made. If step 286 is positive, step 290 determines if a
buffer or a record is being returned. If it is a buffer, step 292 saves
the buffer attributes and step 294 checks to see if there is a pending
discard stop. If so, step 300 calls the CheckStopPending routine. Step 296
follows 300 or 294 and determines if the end of stream has been reached.
If so, step 302 calls the CheckPreroll routine. If the end of stream is
reached, step 298 checks to see if the target stream handler is waiting to
be started. If so, step 299 calls the SHC.START routine to start target.
If step 298 is negative, a loop to step 280 is made.
If step 290 determines a record is to be returned, step 304 validates that
the record is in the buffer. Step 306 determines if the record pointer is
ok. If not, step 308 sets an error flag indicating an invalid record has
been returned, and step 282 then returns. If step 306 is positive, step
310 saves record attributes, allocates an RCB and adds it to BCB list.
Then, step 312 checks for end of stream and last record for the buffer
conditions, and step 294 follows.
At the start of the GetEmpty routine shown in FIG. 12, step 314 determines
if there are more buffers to get. If not, a return is made in 316. If so,
step 318 checks if an empty pointer points to an empty BCB. If so, step
320 gets the buffer attributes and the loops back to 314. If step 318 is
negative, step 322 turns on a Source.is.waiting flag indicating no buffer
is available. Step 324 then calls the CheckPreroll routine. Step 326
checks for error. If none, a loop to step 314 is made. If there is an
error, an error flag is set to indicate no buffer is available and a
return is made by 316.
Referring to FIG. 13, ReturnEmpty routine begins with step 330 which checks
to see if there are more buffers to return. If not, step 332 returns. If
there are buffers, step 334 searches the chain of buffer BCBs for buffer
address. Step 336 sees if buffer is found and if the target stream handler
owns it. If not, step sets an error flag indicating an invalid buffer is
returned. If step 336 is positive, step 340 determines if a record or a
buffer is being returned. If it is a buffer, step 342 marks the buffer as
empty, and step 346 sees if the source stream handler is waiting. If not,
step 348 is skipped. If so, step 348 calls the source SHC.START routine.
If step 344 is positive, step 350 then calls the CheckStopPending routine.
Step 330 then follows either step 348 or 350. If a record is returned as
determined in 340, step 352 removes the associated RCB from the RCB list
and check 354 determines if all records have been returned empty. If so,
step 356 marks the buffer as empty and step 344 then follows either step
354 or 356.
In the GetFull routine (FIG. 14), step 358 determines if there are more
buffers to get. If not, return 360 occurs. If so, step 362 sees if the
full pointer points to a full buffer. If not, no buffer is available, and
step 370 sets the Target.waiting flag on and returns via 3360. If 362 is
positive, step 364 determines the type of stream, normal (unified) or
interleaved. If unified, step 366 gets the buffer attributes, step 368
sets the end of stream condition (EOS) when it is last buffer, and then
returns via 360. For an interleaved or split stream, step 372 searches for
a full record in the buffer. If one is found, as checked by 374, step 376
gets the record attributes and step 378 checks for last record in buffer
before returning via 360.
Referring to FIG. 15, the CheckStopPending routine checks in step 380 to
see if all buffers have been returned. If not, a return is made by step
384. If so, step 386 calls the routine SMH. | | |
