1. Field of the Invention
This invention relates to a communication system and, more particularly, to a synchronous communication system formed as a ring network of two or more ports coupled in daisy chain fashion to one another to allow communication to and from a external multimedia device coupled to at least one port of the network to complete the ring. The ports are preferably associated with a single multimedia device, and the network is formed between ports of the device to which the external multimedia device is coupled so that the port can accommodate data that conforms to a particular protocol used by the network (i.e., complaint data), or the port can accommodate non-compliant data as asynchronous Ethernet-based packets of data, synchronous or isochronous data, analog data, and/or Sony/Philips Digital Interface Format (“SPDIF”) data.
2. Description of the Related Art
A communication system is generally known as a system that permits communication between nodes interconnected by a transmission line. Each node can transmit information, or can transmit and receive information, across the transmission line. The communication system of interconnected nodes can be organized in various topologies, such as bus, ring, star, or tree topology.
A bus topology network is generally regarded as linear, where transmissions from one node propagate the length of the transmission line and are received by all other nodes connected to that bus. A ring topology network, however, generally consists of a series of nodes connected to one another by unidirectional transmission links to form a single, closed loop. Examples of a ring network are described in IEEE 802.5 and Fiber Distributed Data Interface (FDDI).
The transmission line between nodes can be either wired or wireless. It is preferred that the transmission line accommodate different types of data. Unfortunately, certain portions of a network may be tailored to sending bursts of data, such as TCP/IP across Ethernet, while other portions may be called upon to send streaming data, such as audio and video data. It would be desirable to introduce a network that can transfer both types of information, in whatever form, upon the network. Moreover, it would be desirable to use, for example, copper wire, fiber optic, or wireless transmission medium for the chosen transmission line.
Ethernet and IEEE 802.03 specify a particular protocol in which packets of data can be sent between computing systems. Ethernet can sense multiple access collisions and can arbitrate which source device will gain mastership over the transmission line. Ethernet operates at the lowest levels of the OSI reference model, normally reserved for the data link and physical link layers. The Ethernet protocol specifies a particular frame format of a preamble, followed by a destination address and a source address, and then the data payload. The data is generally encoded in a 4B/5B or 8B/10B encoding structure prior to the data being sent across the coax or twisted pair transmission line.
The encoded packets of data sent within an Ethernet frame generally have no time relationship relative to each other. For example, a computer can send a burst of data in several successive frames, and then a considerable amount of time might pass before the next burst of data is sent. Bursty or packetized data need not be sent as real-time, time-related data since the packets are typically stored and used later by the destination device.
Conversely, streaming data has a temporal relationship between samples produced from a source port onto the network. That relationship between those samples must be maintained across the transmission line to prevent perceptible errors, such as gaps or altered frequencies. A loss in the temporal relationship can cause a receiver at a destination to experience jitter, echo, or in the worst instance, periodic blanks in the audio and video stream.
Packetized TCP/IP data, for example, placed in an Ethernet frame need not maintain the sample rate or temporal relationship of that data and networks that send packetized data typically send that data at whatever rate the source device operates. Thus, a network that forwards packetized data is generally considered as an asynchronous network. Conversely, a network that forwards streaming data is generally synchronous, with each source and destination node sample at a rate synchronous to the network.
While streaming data is typically sent synchronously across a network, there may be instances in which the sample rate (fs) local to a node is not at the same frequency as the frame synchronization rate (FSR or FSY) of the transmission line. If this is the case, then the data streaming from a source device can be sample rate converted, and then sent synchronously across the network. Alternatively, the data can be sent isochronously across the network.
There are various types of sample rate converters available on the market. For example, Analog Devices Corp. offers part no. AD1896 to convert the sample rate offered by the local clock to another sample rate synchronous to, for example, another clock associated with the network, for example. Either increasing or decreasing the sample rate would be beneficial if a system can be employed that can match fs to FSY. Sample rate conversion, however, oftentimes involves fairly complex algorithms for comparing fs to FSY, and generally a digital signal processor (DSP) is used at the source node. If, for example, the source node contains compressed data, such as AC3 data streaming from a DVD, the compressed data must be decompressed before the data is sample rate converted. Unfortunately, sending decompressed data consumes more network bandwidth than sending compressed data.
It would be desirable to implement an improved communication system or network. The improved network should be one that can accommodate streaming data in either synchronous or isochronous form. The data streaming from a source node should be sent isochronously rather than sample rate converted. Moreover, the improved network should also accommodate packetized data in order to interface computing systems, such as computers and interactive televisions, to streaming audio and video data accessible by such systems.
FIG. 1 illustrates a system made up of nodes that send and receive packetized and streaming data yet, however, communication between such nodes is limited due to the constraints of the different protocols by which data is transferred. As shown, a communication system 10 might have an audio/video receiver 12. Receiver 12 operates essentially as a dual-purpose switch or “hub” for streaming data sent between, for example, an MP3 player 14, an audio tuner 16, a DVD player (or DVR) 18, and CD player 20. Receiver 12 can receive the streaming data from the various players or inputs and forward the serial bitstream after processing to, for example, an amplifier, speakers 22, and/or digital television 24.
The information sent from the various devices 14-20 can be sent to receiver 12 as analog data or digital data. A popular format for digital data is the Sony/Phillips Digital Interface Format (SPDIF). SPDIF was established by the Audio Engineering Society (AES) in conjunction with the European Broadcasting Union (EBU) to create a standard interface known as the AES/EBU interface. The interface constitutes a serial transmission format for linearly-represented, digital audio data. The format is generally independent of sampling frequency, but three sampling frequencies are nonetheless recommended by AES for pulse code modulated (PCM) application: 32 kHz, 44.1 kHz, and 48 kHz. The SPDIF protocol and frame structure is well documented as a series of 16-bit bytes, beginning with control and category codes, as well as the source number and channel number by which data is transferred from a digital source, such as a CD, DVD, or MP3 player.
The SPDIF protocol can, for example, be used by a digital television (DTV) 24, and a packet hub 26 can be used to combine packetized data from, for example, a digital video broadcast (DVB) receiver sometimes known as a set top box 28. Certain commands broadcast from the set top box 28 can be forwarded to hub 26, while streaming data is forwarded to the audio video receiver 12. The command signals that emanate from set top box 28 can be sent as, for example, TCP/IP data within the network layer of the OSI model, which is then wrapped with the Ethernet protocol, recognizable to hub 26. Along with the Ethernet packets from the set top box 28 and digital television 24, hub 26 can also receive Ethernet packets from a personal computer (PC) 30. The packets of information processed by hub 26, therefore, can constitute control information.
It may be desirable to implement interactive television processing in multiple rooms throughout a user's home, or in different homes or locations. For example, another DTV 32 can be situated in a second room, separate and apart from DTV 24 placed in a first room. Alternatively, DTV 32 can be a computer laptop carried outside the home in which DTV 24 resides. Similar to DTV 24, an audio amplifier 34 might form a part of DTV 32 or be built outside DTV 32 and, as shown, receives either digital or analog information. If in digital form, the information can be sent possibly in SPDIF format to amplifier 34, which then processes the digital information and outputs the information to the appropriate left and right speakers, or multiple surround speakers 36.
A prevalent problem with home or consumer audio/video electronics is the rapid advances in digital interaction to those electronics via, for example, PCs. Interacting home electronics with PCs is difficult at best simply due to the differences between asynchronous networks and synchronous networks. Network 10 of FIG. 1 attempts to combine asynchronous, packet-processing nodes or devices with synchronous, streaming nodes or devices. However, the streaming information cannot be reliably sent to DTV 32 if DTV 32 cannot gain mastership of the asynchronous bus 38. This will entail possible loss of streaming data upon DTV 32.
There have been attempts to overcome the problem of interfacing asynchronous transmission lines to synchronous transmission lines in order to network audio and video data. For example, a product known as CobraNet attempts to eliminate the dropouts and discontinuities of streaming data sent across an asynchronous network. CobraNet providers recommend using dedicated Ethernet network for audio, and another dedicated Ethernet network for the packetized data. See, Harshbarger and Gloss, “Networking for Audio, Part 3,” 2004, herein incorporated by reference. Requiring two separate Ethernet networks and maintaining the asynchronous protocol between nodes substantially increases the overhead of the network, and the complexity of software and hardware drivers used by that network.
It would be desirable to introduce a network that can transfer streaming data (both isochronous and synchronous streaming data), as well as packetized TCP/IP data and control data simultaneously across a network. It would also be desirable to send the various types of data across a network that is clocked at the same rate for all such types of data. Thus, the desired network is a synchronous network where sampled, streaming data is cognizant of the network transfer rate, and packetized data is placed onto the network at the network transfer rate. Moreover, the improved network avoids utilizing two transmission paths for audio information and packetized data. Any multimedia device which streams data or sends bursts (packets) of data can be formatted and time-slotted onto the desired communication system and network.
USPTO Backgrounds
USPTO Backgrounds