Patent Application
20080005257
In order to describe the manner in which the above-recited and other advantages and features can be obtained, a more particular description of the subject matter briefly described above will be rendered by reference to specific embodiments which are illustrated in the appended drawings. Understanding that these drawings depict only typical embodiments and are not therefore to be considered to be limiting in scope, embodiments will be described and explained with additional specificity and detail through the use of the accompanying drawings in which:
Embodiments herein may comprise a special purpose or general-purpose computer including various computer hardware, as discussed in greater detail below.
One embodiment described herein uses a dual processor system, where the dual processors are interconnected via an interface intended for connection to storage devices such as an IDE interface. IDE interfaces are typically used for storage communication as apposed to processor interconnection. A system may include a specialized media decoder processor which includes specialized hardware for decoding and displaying media data, such as audio, video and/or image data. The decoder processor may be connected via an IDE interface, or other storage based connection, to a network processor that includes functionality for sending and receiving data across a network. By connecting the network processor to the decoder processor through an IDE interface, the network processor can be treated by the decoder processor as an IDE storage device. An emulator can be used to convert storage operations to network operations and vice versa.
The network processor includes an interface for connecting to a network where data can be obtained. For example, the network processor may connect to a server which includes physical storage for storing data. To obtain video or other data, the video decoder processor may send storage device protocol messages across the IDE interface and to the network processor. Typically, the media data is accessed through DMA (direct memory access) data access, while other data such as FAT table data, FAT directory information and the like is accessed manually through software controlled hard drive read commands. This is done in a transparent fashion such that the decoder processor treats the network processor as a storage device. The network processor can then obtain data from a server across a network and provide the data to the decoder processor in a fashion similar to how a storage device provides data across an IDE interface. Because data is being obtained by the network processor across a network, network delays may be introduced into the architecture.
Typically, when implementing an IDE interface, it is assumed that the storage device is local to the processor accessing the storage device and that communications take place fairly quickly. However, the network delays described above may result in various difficulties. For example, one particular method of accessing data across an IDE interface involves sending a DMA request. DMA requests allow data to be retrieved through DMA hardware to avoid burdening the central processing unit. To avoid corruption of data and other difficulties, only a single DMA request should be active at any particular time. When a physical storage device is in near proximity to the processor consuming data from the storage device, there is usually little difficulty due to the speed of the connection between the processor and storage device. Specifically, by the time a following DMA request is made, a previous DMA request will always be completed. However, when network delays are introduced, there may be some difficulty in that longer than expected latencies may exist between the time when a DMA request is issued and when the corresponding data is returned. To counteract these timing difficulties, various techniques are used, including various delays, cancellations of DMA operations, error reporting, streaming file position maintenance, and redundant file characteristic determination.
An additional difficulty not expected by IDE storage busses relates to conditions when no responses are received. When a processor is connected to an IDE device over a network, loss of network connectivity or loss of network devices or services may result in a condition where there is no response whatsoever from a DMA request or other IDE request. For example, if a network service is instantiated and later shut-down, a DMA request may be issued for retrieving data from the network service where no response will be received because the service is not able to send a response of any kind.
Referring now to
The media server 102 is connected through a router 104 to various clients in the network. The clients on the network may include specialized media adapters configured to provide media to users. As will be discussed further herein, the media adapters may include specialized hardware optimized for providing the media to users. For example, the media adapters may include processors that are optimized for decoding compressed audio, video or image data. The media adaptors may be embodied in a number of forms as illustrated in
Each of the examples of media adapters whether embodied in an integrated unit such as with the television 106, or a standalone unit such as the DVD player 108 or self contained media adapter 112, or other media adapter is connected, in this example, through the router 104 to the media server 102. The connections between the media server 102, router 104 and media adapters may be any suitable network connection including hardwired Ethernet connections, wireless wi-fi connections, or any other suitable connection. Notably some embodiments described herein optimize wireless network connections to maintain suitability for transmitting high bit rate media files.
Referring now to
Similar to the decoder processor 202, the network processor 204 has a flash memory 212 and a DRAM memory 214 connected to it. The flash memory 212 and DRAM memory 214 are computer readable media that may include computer executable instructions that can be executed by the network processor 204. In addition, the DRAM memory 214 may store data for delivery to the decoder processor 202. For example, the network processor 204 may receive data from a data store such as a media server, such as the media server 102. This data may be stored in the DRAM memory 214 for delivery to the decoder processor 202. Such data may include for example, media, file information, directory information, or other information. In the example illustrated, the network processor 204 may be connected to a media server through one or more different network connections.
It is useful to notice at this point that the media player is unique in that the two processors, the decoder processor 202 and network processor 204 are connected through an IDE bus 206. This is particularly interesting in light of the fact that ordinarily such communications would take place on a PCI or other type of communication bus. Typically, an IDE bus is used for connecting storage to a processor. However, by using an IDE bus 206 to connect to the decoder processor 202 and network processor 204, several advantages can be realized. For example, typical decoder processors come equipped with a standard IDE bus interface for connecting storage to the decoder processor. However, some decoder processors may not come equipped with network connectivity, and as such may not be suitable on their own for use in a media adapter connectable in a network. By using the IDE bus interface to connect through an IDE bus to a network processor, networking functionality can be added to virtually any media decoder processor.
Additionally, this configuration allows for a smaller operating system, selection of a specialized network processor, easy replacement of the network processor in subsequent designs when additional networking speeds and as functionality become available, easy replacement of the decoder processor in subsequent designs, reduced memory requirements, etc.
Ordinarily, a storage device connected to a host processor through an IDE bus is somewhat passive in nature. In other words, typically the IDE device accepts commands from the host processor, and can be polled by the host processor for information, but does not typically provide data to the host processor without first being prompted. In the example shown in
For example, the network processor 204 may be able to detect various conditions such as a storage device not being connected to one of the network connections 218, 220, or the inoperability of the network. The network processor 204 can thus signal on the hardware line 228 that it has data for the decoder processor. When the decoder processor 202 polls the network processor 204, the network processor 204 can provide the diagnostic information.
The use of the IDE bus for connecting to a network processor which retrieves the content to be decoded from a network store is not without drawbacks. In particular, IDE connections typically have small latencies from when data is requested to when the data is returned. However, network connections are unreliable and can have longer latencies, or in worst case scenarios, resources are not available, due to network congestion, network machine configuration, network server power state, or other networking problems. Wireless Wi-Fi networks in particular are susceptible to RF interference generated by common household appliances such as microwave ovens and cordless phones. As such, IDE interfaces typically do not have error handling capabilities for long latencies. However, some embodiments described herein address these latency mismatches.
Some issues relate to DMA requests. As noted above, typically media data, such as video, audio and image data, is retrieved from the network processor 204 through DMA requests. DMA is a communication mechanism where messages can be sent within a computer system without the messages being passed through the CPU of the computer system. This allows for faster communication, as the CPU does not need to process data sent on the DMA channels to facilitate the transfer of the data. Thus, a state machine in the computer system is used to transfer data. Data may also be transferred manually in a computer system. This involves accessing data by using software computer executable instructions executed by the processor to access the data. As noted previously, file and directory information is generally transferred using manual hard drive access. For example, software executed by the CPU in the decoder processor 202 may cause a hard drive read of a specified number of bytes from the network processor 204.
Generally, media data is transferred by using DMA requests. When the DMA state machine senses that the DMA state machine is idle, the DMA state machine will send additional requests. However, when long latencies exist due to slower network transfers, the DMA state machine may sense that the DMA state machine is idle, when in fact the DMA state machine is waiting for a previous DMA request to be serviced. For example in one embodiment, when using trick modes, e.g. fast-forward and rewind, there may be issues with one DMA request being issued before a previous DMA request has been serviced. Specifically, a trick mode command received from a user through an IR interface 226 (
To overcome this difficulty, some embodiments include using an IDE sectors left to read indication to delay invoking of subsequent DMA requests. For example, the DMA state machine in the decoder processor may include or have access to an ide_sectors_to_read register which stores an indicator of how many sectors of data need to be read to complete the current read operation. Thus, in one embodiment trick mode operations do not begin until the ide_sectors_to_read register reaches 0. To prevent subsequent DMAs, a mutex may be used to lock the DMA state machine.
Typically DMA state machines and IDE bus protocols do not include time-out provisions. However, as explained previously, using an IDE bus to access data that is stored across a network may result in some delays not typically anticipated by DMA state machines or other storage based hardware and software. Thus, one embodiment includes provisions for implementing a time-out. The time-out may be used to cancel DMA operations. Embodiments may also include provisions for resetting DMA hardware, such as a DMA state machine. Additionally, embodiments may include provisions for halting further DMA operations. Further still, embodiments may include provisions for signaling to a central processing unit that data read requests should be suspended. Notably, various embodiments have different time-out periods. For example, embodiments implemented on wireless networks may have longer time-out periods than embodiments implemented on wired networks. Additionally, embodiments implemented on faster wireless network such as 802.11a or g networks may be shorter time-out periods than embodiments implemented on slower wireless networks such as 802.11b networks.
Referring once again to
In one embodiment, while streaming a file, a DMA read operation may exceed a predetermined time from when a command for the DMA read operation to begin is issued. This can be determined by monitoring for an IDE interrupt to be triggered when data is available to read and/or a DMA request status indicating that a read is complete. If these indicators do not indicate within a predetermined time that data is available and/or that a read is complete, time-out operations can be performed.
In one embodiment, the time-out operations may include provisions for signaling various components of the decoder processor 202 to cease file access activities. For example, a command may be invoked to disable IDE interrupts sent to the central processing unit of the decoder processor 202. Additionally, a command may be invoked to clear any interrupts in an interrupt controller included in the decoder processor 202 to stop any possible interrupts. Commands may also be invoked to set values of registers available to the central processing unit indicating that no IDE interrupts are set, no IDE sectors are available to read, and that the IDE is in an idle state meaning that there are no active reads. Additionally, to prevent further IDE reads from taking place for accessing additional data, the media player state machine may be given a command appropriate to prevent the media player state machine from causing additional data to be requested. For example, the media player state machine may be given a pause or stop command to prevent additional media data from being requested for displaying to a user. Notably, a pause command may be advantageous if some recovery processes are to be performed such that media can be played starting at the location where the time-out occurred. The stop command may be advantageous if restarting from the location when the time-out occurred is not possible, practical, and/or desirable.
Another issue that is addressed by some embodiments relates to manual IDE reads. For example, when a user browses files, such as by browsing file information, images, video, music, media content, directories and the like, manual read commands are used to set up the network processor and verify that the file actually available to process. These may be used, as explained above to read FAT tables or directory information. As with the DMA example, the manual reads may take too much time or time-out. This may be determined in a fashion similar to the DMA time-out in that the IDE interrupt may take too long to go off, and/or the DRQ request status, indicating that all data has been read, may not be set. Thus, some embodiments include functionality for propagating errors back to calling functions so that the calling function knows that it did not receive the correct amount of data.
Embodiments facilitate propagating timeout information to various portions of the system. Thus, time-out activities can be processed by the media player state machine, the DMA state machine, software routines being run by the CPU in the decoder processor 202, etc.
One embodiment described herein further includes functionality for file type detection including a redundant file type check. Some decoder processors include functionality for detecting file type and bitrate. For example, a decoder processor may include a routine in the firmware of the decoder processor for detecting that a file is an MPEG2 file with a bitrate of 8 Mbs. However, typically the decoder processor expects the file to be quickly accessible through an IDE bus interface. However, when the file is delayed in its transfer to the decoder processor because of network delays, the file type and bitrate detection of the decoder processor may not function appropriately, and erroneous file types and bitrates may be detected. Thus, one embodiment includes functionality for including a redundant file type and bitrate detection algorithm which can take into account the network delays such that the appropriate bitrate and file type may be detected and displayed to a user by the decoder processor 202.
Embodiments may also include computer-readable media for carrying or having computer-executable instructions or data structures stored thereon. Such computer-readable media can be any available media that can be accessed by a general purpose or special purpose computer. By way of example, and not limitation, such computer-readable media can comprise RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to carry or store desired program code means in the form of computer-executable instructions or data structures and which can be accessed by a general purpose or special purpose computer. When information is transferred or provided over a network or another communications connection (either hardwired, wireless, or a combination of hardwired or wireless) to a computer, the computer properly views the connection as a computer-readable medium. Thus, any such connection is properly termed a computer-readable medium. Combinations of the above should also be included within the scope of computer-readable media.
Computer-executable instructions comprise, for example, instructions and data which cause a general purpose computer, special purpose computer, or special purpose processing device to perform a certain function or group of functions. Although the subject matter has been described in language specific to structural features and/or methodological acts, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts described above are disclosed as example forms of implementing the claims.
The present invention may be embodied in other specific forms without departing from its spirit or essential characteristics. The described embodiments are to be considered in all respects only as illustrative and not restrictive. The scope of the invention is, therefore, indicated by the appended claims rather than by the foregoing description. All changes which come within the meaning and range of equivalency of the claims are to be embraced within their scope.
