U.S. patent application number 12/922078 was filed with the patent office on 2011-01-20 for data transfer method and system for loudspeakers in a digital sound reproduction system.
This patent application is currently assigned to GENELEC OY. Invention is credited to Niko Haatainen.
Application Number | 20110015769 12/922078 |
Document ID | / |
Family ID | 39938374 |
Filed Date | 2011-01-20 |
United States Patent
Application |
20110015769 |
Kind Code |
A1 |
Haatainen; Niko |
January 20, 2011 |
DATA TRANSFER METHOD AND SYSTEM FOR LOUDSPEAKERS IN A DIGITAL SOUND
REPRODUCTION SYSTEM
Abstract
The present publication describes a data transfer method and
system in a digital sound reproduction system. The method comprises
method steps for generating a digital audio stream for multiple
channels in a host data source, e.g. a computer (1), the audio
stream is formed by multiple consecutive samples, receiving the
digital audio stream sent by the host data source (1) through a
digital data transmission network by several digital receivers (2)
each of which including a microcontroller with a clock, the
receivers (2) further including means for generating an audio
signal. In accordance with the invention the host data source (1)
sends repeatedly a synchronization sample (60) to at least one
receiver (2), the receiver (2) replies to the synchronization
sample (60) by a return sample (61), the host (1) calculates a
latency (T) for each receiver (2) based on the sending time
(Th.sub.1) of the synchronization sample (60) and the reception
time (Th.sub.2) of the return sample (61) and the processing time
(Tt.sub.1-Tt.sub.2) of the receiver (2), the host (1) sends to the
receiver (2) information of the calculated latency (T) in
combination with the time stamp the measurement time, based on this
information the receiver (2) adjusts the function of its clock, and
the above synchronization steps are repeated continuously.
Inventors: |
Haatainen; Niko; (Iisalmi,
FI) |
Correspondence
Address: |
BIRCH STEWART KOLASCH & BIRCH
PO BOX 747
FALLS CHURCH
VA
22040-0747
US
|
Assignee: |
GENELEC OY
Iisalmi
FI
|
Family ID: |
39938374 |
Appl. No.: |
12/922078 |
Filed: |
March 12, 2008 |
PCT Filed: |
March 12, 2008 |
PCT NO: |
PCT/EP08/52917 |
371 Date: |
September 27, 2010 |
Current U.S.
Class: |
700/94 |
Current CPC
Class: |
H04R 27/00 20130101;
H04J 3/0667 20130101; H04R 2227/003 20130101; H04R 3/12 20130101;
H04R 2227/005 20130101 |
Class at
Publication: |
700/94 |
International
Class: |
G06F 17/00 20060101
G06F017/00 |
Claims
1-15. (canceled)
16. A data transfer method in a digital sound reproduction system,
comprising method steps for generating a digital audio stream for
multiple channels in a host data source, e.g. a computer, the audio
stream is formed by multiple consecutive samples, receiving the
digital audio stream sent by the host data source through a digital
data transmission network by several digital receivers each of
which including a microcontroller with a clock, the receivers
further including means for generating an audio signal, wherein the
host data source sends repeatedly a synchronization sample to at
least one receiver, the receiver replies to the synchronization
sample by a return sample, the host calculates a latency (T) for
each receiver based on the sending time (Th.sub.1) of the
synchronization sample and the reception time (Th.sub.2) of the
return sample and the processing time (Tt.sub.2-Tt.sub.1) of the
receiver, the host sends to the receiver information of the
calculated latency (T) in combination with the time stamp the
measurement time, based on this information the receiver adjusts
the function of its clock, and the above synchronization steps are
repeated continuously.
17. Method according to claim 16, wherein the digital audio stream
is transmitted wirelessly to the receiver.
18. Method according to claim 16 or 17, wherein the receiver
compensates for the clock difference by setting the local clock
rate in order to obtain synch of the microcontroller of the
receiver.
19. Method according to claim 16 or 17, wherein the host compares
the calculated latency (T) with a reference latency and if the
calculated latency (T) is larger than the reference latency, no
adjustment information is sent to the receiver and the host starts
a routine to redefine the reference latency.
20. Method according to claim 19, wherein the clock difference is
compensated for by adding or removing samples to/from the audio
data stream and adjusting clock value accordingly.
21. A data transfer system for a digital sound reproduction system,
comprising a host data source, e.g., a computer for generating a
digital audio stream for multiple channels, the audio stream is
formed by multiple consecutive samples, a transmission path for the
host data source, multiple digital receivers capable to communicate
over the transmission path with the host data source, the receivers
including means for receiving the digital audio stream sent by the
host data source a microcontroller with a clock, and means for
generating an audio signal, wherein the host computer has means for
sending repeatedly a synchronization sample to at least one
receiver, the receiver has means for replying to the
synchronization sample by a return sample, the host includes
further means for calculating a latency (T) for each receiver based
on the sending time (Th.sub.1) of the synchronization sample and
the reception time (Th.sub.2) of the return sample and the
processing time (Tt.sub.2-Tt.sub.1) of the receiver, sending to the
each receiver information of the calculated latency (T) in
combination with the time stamp the measurement time, whereby based
on this information the receiver includes means for adjusting the
function of its clock, and the system includes means for repeating
the above synchronization steps continuously.
22. The system according to claim 21, wherein it includes means for
transmitting the digital audio stream wirelessly to the
receiver.
23. The system according to claim 21 or 22, wherein the receiver
includes means for compensating for the clock difference by setting
the clock frequency of the microcontroller of the receiver.
24. The system according to claim 21 or 22, wherein the host
includes means for comparing the calculated latency (T) with a
reference latency and if the calculated latency (T) is larger than
the reference latency, no adjustment information is sent to the
receiver and the host starts a routine to redefine the reference
latency.
25. The system according to any previous system claim 21 or 22,
wherein the system includes means for compensating for the clock
difference by adding or removing samples to/from the audio data
stream.
26. A synchronization method in a digital sound reproduction
system, comprising method steps for generating a digital audio
stream in a host data source, e.g. a computer, receiving the
digital audio stream sent by the host data source through a digital
data transmission network by several digital receivers each of
which including a microcontroller with a clock, the receivers
further including means for generating an audio signal, whereby the
receivers are grouped in a predetermined manner, wherein the host
data source sends repeatedly a synchronization sample to all
receivers of a group, the receivers reply to the synchronization
samples by return samples, the host calculates a latency times (T)
for each sample and each receiver based on sending time (Th.sub.1)
of the synchronization sample and the reception time (Th.sub.2) of
the return sample and the processing time (Tt.sub.2-Tt.sub.1) of
the receiver, and based on the calculated latency times (T) the
host forms statistically a reference latency value, below which
time most of the latency times are.
27. Method according to claim 26, wherein the digital audio stream
is transmitted wirelessly to the receiver.
28. Method according to claim 26 or 27, wherein the reference
latency is set such that at least 80% of the measured and
calculated latency values are below the reference latency.
29. Method according to claim 26 or 27, wherein the reference
latency is set such that at least 50% of the measured and
calculated latency values are below the reference latency.
30. Method according to claim 26 or 27, wherein it includes the
following steps: 1. Sending ECHO REQ to receiver, 2. Getting
timestamp TSsend for the packet containing ECHO REQ from timestamp
driver, 3. Receiving ECHO RESP, whereby it will contain receiver
ProcessingLatency, which is amount of microseconds receiver spent
between receipt of the ECHO REQ and sending of ECHO RESP 4. Getting
timestamp TSrecv for the ECHO RESP packet 5. Calculating Roundtrip
latency is TSrecv--TSsend--ProcessingLatency
Description
[0001] The present invention relates to a data transfer method
according to the preamble of Claim 1.
[0002] The invention also relates to a data transfer system.
[0003] According to the prior art, there are several commercial
system for digital audio reproduction in digital networks. For
example following products are available today. The Gibson
MaGIC.TM. network Cobra Net.TM., EtherSound.TM., Livewire.TM.,
MADI.TM. and others describe systems by which audio data may be
streamed to digital loudspeakers or sound reproduction systems.
Basically the quality of the reproduction in these systems is fairy
good for home use but for professional use the digital transfer
technology causes some problems.
[0004] In accordance with the prior art the above problem has been
solved by buffering the information into receivers and controlling
the unloading of the information from the receivers.
[0005] In more detail, to synchronize clocks over Ethernet
connections the exact travel time of network packets must be
measured. This is difficult for two reasons. First, standard
network socket API will introduce random latency between calling
the user-mode send-function and the actual output of the packet
depending on the status of the operating system. The same applies
also to reception of packets, the time between reception of packet
from the network and its indication to user-mode process listening
to the UDP socket cannot be accurately determined.
[0006] Secondly, when packet travels through network it will go
through one or more hubs, switches or routers. Each device may
randomly delay packets depending on the load of network and state
of the device. This introduces random latency in travel time that
cannot be predicted. When measured, it is found that the latency is
nearly constant for most of the packets but some packets may be
delayed by several hundreds of microseconds or even more.
[0007] The invention is intended to eliminate some defects of the
state of the art disclosed above and for this purpose create an
entirely new type of method and apparatus for data transfer in a
sound reproduction system.
[0008] The invention is based on implementing network packet time
stamping in network protocol stack so that accurate time for send
and receipt of packets can be determined. In a preferred embodiment
the receiver software implements the time stamping directly in the
Ethernet driver (for which we have source code) for the most
accurate operation possible.
[0009] The second problem is preferably solved simply by running
the clock synchronization, which includes determination of
round-trip time between host and receiver, and performing the
synchronization only if the latency is within acceptable range from
measured minimum latency.
[0010] More specifically, the method according to the invention is
characterized by what is stated in the characterizing portion of
Claim 1.
[0011] The system according to the invention is, in turn,
characterized by what is stated in the characterizing portion of
Claim 6.
[0012] Considerable advantages are gained with the aid of the
invention.
[0013] The present invention is especially suitable for multi
channel sound reproduction systems, where along the same data
transfer path is sent a data stream including audio information of
multiple audio channels to be reproduced simultaneously in several
loudspeakers.
[0014] With the aid of the method according to the invention, a
statistical latency time may be defined in a start-up procedure and
use this value as a reference latency time for further, continuous
latency measurement.
[0015] By these two methods the audio reproduction system may adapt
to the load of the network and make suitable adjustments in order
to maintain high quality and synchronized multi-channel audio
reproduction in most of the load variation cases.
[0016] In the following, the invention is examined with the aid of
examples and with reference to the accompanying drawings.
[0017] FIG. 1 shows a block diagram a digital audio system, which
can be used in connection with the present invention.
[0018] FIG. 2 shows as a block diagram one network management host
system in accordance with the invention.
[0019] FIG. 3 shows as a block diagram one receiver management
system according to the invention.
[0020] FIG. 4 shows as a timing diagram a method in accordance with
the invention.
[0021] FIG. 6 shows as a flow chart a synchronization protocol in
the receiver in accordance with the invention.
[0022] FIG. 7 shows as a flow chart a synchronization protocol in
the host in accordance with the invention.
[0023] In the invention, the following terminology is used in
connection with the reference numbers. However, the list is not
exhaustive especially relating to the block and flow diagrams of
FIGS. 7-11: [0024] 1 host or host data source [0025] 2 receiver,
digital loudspeaker, [0026] 2a wireless receiver [0027] 3 switch,
network [0028] 4 group of receivers [0029] 10 hard disc [0030] 12
virtual software audio adapter (driver) [0031] 13 audio data
manager [0032] 14 synchronization manager [0033] 15 network
interface [0034] 16 network timestamping [0035] 17 system clock
[0036] 20 network interface [0037] 22 timer hardware [0038] 23
adjustable oscillator [0039] 24 loudspeaker networks communications
[0040] 25 synchronization controller [0041] 26 digital to analog
conversion [0042] 27 audio stream controller [0043] 28 data output
controller [0044] 29 sample rate converter [0045] 60
synchronization signal/ECHO REQ [0046] 61 Return message/ECHO RESP
[0047] 62 Control Command/SET CLOCK [0048] 150 Wireless Local Area
Network (WLAN) access point
[0049] Also the following acronyms and abbreviations are used in
the following text. [0050] DHCP Dynamic Host Configuration Protocol
[0051] FEC Forward Error Correction [0052] GLM Genelec Loudspeaker
Manager [0053] Global LSNW Multicast address:port to which all
global LSNW traffic is sent. All address receivers listen to this
address to receive DISCOVERY, ANNOUNCE, GROUP and other global
messages [0054] Group LSNW Multicast address:port to which all data
directed to set of grouped address receivers is sent. All receivers
that are assigned to same group listen to same group address. Group
address will receive clock synchronization messages, streamed audio
and glm control messages. [0055] Host Application that manages the
loudspeaker network, streams audio and send glm-control messages.
[0056] IP Internet Protocol [0057] LSNW Loudspeaker Network [0058]
Multicast A special IP address that will be routed to members of a
multicast address group. [0059] Receiver Processor, network
interface and the software that connects a loudspeaker to
IP-network [0060] UDP User datagram protocol
[0061] Further, in this application latency means the network delay
between two network elements for a data sample.
[0062] In accordance with FIG. 1 the system in accordance with the
invention comprises at least one host computer 1 or host data
source for controlling the system and several receivers 1 connected
to the host computers 1 via en digital network 3 comprising the
signal path 3 formed by cables, connectors, network adapters and
switches etc.
[0063] In other words the LSNW (Loudspeaker network) system consist
of one or more hosts 1 that each manage sets of receiver devices 2.
Hosts 1 act as source of management, control and audio data to the
receivers 2. Hosts 1 are responsible for discovering receivers 2
connected to IP-network, managing groups 4 of receivers and
providing them with audio. Receivers 2 respond to commands and
playback audio data from hosts 1.
[0064] In accordance with FIG. 2 the host system comprises
typically hard disc 10 by which Digital audio data may be stored.
Also some other non-volatile medium like flash memory can be used.
Digital audio data may be acquired from virtual software audio
adapter (driver) 12 that redirects audio to networked loudspeakers.
Audio data manager 13 acquires digital audio data and makes it
suitable for streaming. Streaming and synchronization manager 14
controls clock synchronization of loudspeaker devices (receivers)
currently controlled by the host. Network interface 15 connects the
host to computer communications network. Network timestamp-module
16 manages accurate timing of synchronization related network
traffic. This is required to reduce effects of random latencies
introduced by the non real-time operating system (such as Windows,
Linux etc.) run by the host. System clock 17 provides accurate time
information used by the synchronization manager and a standard
Ethernet network 3 enables IP-based communications between the host
and the receivers.
[0065] Host application manages the loudspeaker network, routes
management information from GLM and audio from audio software to
receivers. Host application will run as a background daemon process
on the host computer. On windows platform, these background
processes are usually referred as services or system services.
[0066] Host provides interface for GLM software to send and receive
GLM-messages to receivers as if the GLM Software was using GLM
network.
[0067] Host software will provide standard audio interface for
audio software to send audio to LSNW receivers. Such interfaces are
for example ASIO and Windows audio. The audio software will see
LSNW receivers as channels in virtual audio interface provided by
the host.
[0068] Host will include proprietary kernel-mode driver software to
provide necessary virtual audio interface and UDP Network interface
20 connects the receiver to communications network 3. Timer
hardware 22 provides time information for the system clock and
synchronization controller. Adjustable oscillator 23 provides clock
signal for timer hardware and audio data output controller 28.
Loudspeaker networks communications module 24 manages network
traffic to and from host computer. Synchronization controller 25
synchronizer receivers clock with host. It adjusts clock oscillator
in order to minimize clock drift between receiver and host clocks.
Digital signal processing, digital-to-analog conversion takes place
in block 26. Audio stream controller 27 manages audio data received
from host and feeds it to audio data output controller 28. Audio
data output controller 28 outputs audio data at rate specified by
adjustable oscillator 23. This guarantees that samples will be
output at same rate as host outputs them. Sample rate converter 29
converts digital audio to internal sample rate used by digital
signal processing and digital-to-analog conversion.
[0069] Accurate clock synchronization is essential for correct
working of the LSNW. The LSNW protocol has mechanism for clock
synchronization that enables synchronization of host and receiver
clock within accuracy of about 10-20 microseconds.
[0070] The solution to the travel time (latency) measurement is to
implement network packet time stamping in network protocol stack so
that accurate time for send and receipt of packets can be
determined. In windows host software the time stamping is
implemented as an IP Packet Filter that examines incoming and
outgoing UDP-packets and record time stamps if packet is destined
to or originates from an LSNW receiver. This location is not
optimal for time stamping, as the time stamps should be collected
as near the network hardware as possible, but experience shows that
time stamping at the IP Packet Filter lever gives good
accuracy.
[0071] The receiver software in accordance with the invention
implements the time stamping directly in the Ethernet driver for
the most accurate operation possible. For this purpose a source
code has been developed in connection with the invention.
[0072] The problem of random variation of network latency can be
solved simply by running the clock synchronization, which includes
determination of round-trip time between host and receiver, and
performing the synchronization only if the latency is within
acceptable range from measured minimum latency.
[0073] Clock synchronization is initiated by the host in accordance
with FIG. 4. The host 1 will synchronize clocks with each group
member in a round-robin fashion to guarantee all receivers have
accurate time. A receiver may send SYNCH REQUEST message to host if
it feels a need to resynchronize its clock. This can happen for
example if receiver must interrupt audio stream due to packet loss
and continues it when audio packets are received.
[0074] When a receiver 2 is assigned to a group, the host will send
several ECHO REQ packets 60 to receiver to probe the roundtrip
latency. The receiver 2 will reply with ECHO RESP 61 and the host 1
will then determine roundtrip latency Tt.sub.1-Tt.sub.2 for each
transaction. Once the roundtrip latency Tt.sub.1-Tt.sub.2 is
determined with adequate accuracy, the host 1 will set the minimum
acceptable roundtrip for successful synchronization. The latency
will also change as the function of packet size, so the latency is
probed for packets of different sizes.
[0075] The actual roundtrip latency is measured as follows: [0076]
1. Send ECHO REQ 60 to receiver 2 (add extra payload to increase
packet size if necessary, receiver will not process the extra
payload as it is used only to change actual UDP datagram size to
determine latency for different packet sizes) [0077] 2. Get
timestamp TSsend (Th.sub.1) for the packet containing ECHO REQ 60
from timestamp driver [0078] 3. Receive ECHO RESP 61 from the
receiver, it will contain receiver ProcessingLatency, which is
amount of microseconds receiver spent between receipt of the ECHO
REQ 60 and sending of ECHO RESP 61 [0079] 4. Get timestamp TSrecv
(Th.sub.2) for the ECHO RESP 61 packet. Timestamp is formed by the
Host 1 [0080] 5. Roundtrip latency is
TSrecv--TSsend--ProcessingLatency
[0081] Actual clock synchronization starts like the
request--response transaction in initialization phase. Host sends
an ECHO REQ 61 and receiver replies with ECHO RESP 61.
[0082] ECHO RESP 61 packet contains two values, receivers clock at
the time Tt.sub.1 of receipt of ECHO REQ 60 packet and
ProcessingLatency, the time spent by receiver between receipt of
ECHO REQ 60 and sending of ECHO RESP 61.
[0083] The host 1 will calculate the roundtrip latency as is
initialization phase and if the latency is below the maximum
acceptable value determined in initialization, host sends the CLOCK
SET message 62 to receiver 2 that contains an estimate of hosts
clock at the time receiver received the ECHO REQ 61 packet. The
estimated time is calculated by adding half of the measured
roundtrip time to time of outputting the ECHO REQ 61 packet.
[0084] The protocol assumes that the network latency from host to
receiver is equal to latency from receiver to host. This is usually
the case, but the roundtrip will become unsymmetrical when ECHO REQ
is appended to audio data as packet that contains ECHO REQ and
audio data is much larger than the response packet that contains
only ECHO RESP. This unsymmetry can be compensated by appending
extra data to ECHO RESP to make the response packet same size as
the request. In real applications, the unsymmetry of network packet
sizes does not have very large effect on the actual result of the
synchronization. The effect of unsymmetric network latency to
offsets between host and receiver clocks can be calculated as
follows (for simplicity, the calculation does not include
processing latency): [0085] 1. Host clock after synchronization
will be Th.sub.1+L.sub.ht+L.sub.th+L.sub.ht (=Host time at
start+latency of ECHO REQ+latency of ECHO REPLY+latency of CLOCK
SET) [0086] 2. Receiver clock at the end of synchronization will be
Th.sub.1+(L.sub.th+L.sub.ht)/2+L.sub.th+L.sub.ht (SET CLOCK
time+latency of ECHO REPLY+latency of CLOCK SET) [0087] The
difference of clock will be
Th.sub.1+L.sub.ht+L.sub.th+L.sub.ht-(Th.sub.1+(L.sub.th+L.sub.ht)/2+L.-
sub.th+L.sub.ht)=(L.sub.th-L.sub.ht)/2
[0088] Further in more detail, in accordance with FIG. 5 host and
receiver clocks have 2 second offset at host time 10.000000 s
(Th.sub.1). Synch protocol packet latencies are 0.000160 s from
host to receiver (Th.sub.1-Tt.sub.1) 60, 0.000180 s from receiver
to host 61 (Tt.sub.2-Th.sub.2). This will result in 0.000010 s
clock offset at the end of synchronization, assuming that receivers
clock does not significantly drift from host clock between target
time 12.000160 and 12.000710. Receiver 2 may also correct frequency
of its clock based on the measured offsets and reduce average error
between target and host clocks.
[0089] Since the network latencies (0.000160 s and 0.000180 s) were
not equal, host and target clocks will have offset of
(0.000180-0.000160)/2=0.000010 at the end of synchronization
(Tt.sub.3).
[0090] In accordance with FIG. 6 at start 90 receiver initializes
hardware, possibly acquires IP address via DHCP and enters Idle
state. In block 91 the receiver receives SET GROUP command from
host. The message contains IP address of multicast group to which
all the loudspeaker group related traffic is sent. The message also
contains information on which channel of multi-channel audio the
receiver is to output to digital-to-analog conversion. Receiver
starts to listen to the multicast address. It also sends message to
host and acknowledges that the receiver has entered the group.
Receiver enters state 92, RUNNING. At running state 92 receiver
will receive message directed to loudspeaker group multicast IP
address. Audio data is entered into play queue and eventually
output to digital-to-analog conversion. If receiver receives
REQUEST TIMESTAMP message it enters state 97, SEND TIMESTAMP TO
HOST. If receiver receives SET CLOCK message it enters state 93. In
block 93 validity of new clock value is determined based on current
time, estimate of clock drift between host and receiver and time
interval since last SET CLOCK message. If the new value appears
invalid (due to large processing latency in host or some other
reason), receiver clock is not set and control returns to state 92,
RUNNING. If the new clock value appears valid, state 94, ADJUST
OSCILLATOR, is entered. Control voltage to adjustable oscillator is
set in block 94 based on the measured drift and between host and
receiver clocks and the current control voltage. In block 95, if
the measured clock offset between receiver and host is less than
the duration of specified number of samples, state 92, RUNNING, is
entered. In block 96, if the measured clock offset between receiver
and host is more than the duration specified number of samples,
adjust clock value by multiple of sample durations. At the same
time add or remove samples to/from the audio stream to compensate
for the clock adjustment. After the adjustment, return to state 92,
RUNNING. Further in block 97 is sent TIMESTAMP message containing
current receiver clock value and processing latency to host.
[0091] In accordance with FIG. 7, in block 100 host application is
started. It queries network for available receiver loudspeakers and
enters IDLE state. In block 101 Host application receives command
from user interface to setup a receiver loudspeaker group. It
starts analyzing network latency to each loudspeaker. In block 102,
if analysis was not successful report error to user and return to
IDLE state. Analysis may not succeed for example if the packet loss
in the network is too large. If analysis of network latencies to
each receiver is successful store maximal acceptable
synchronization network latency for each receiver and enter state
103, RUNNING.
[0092] In running state 103 the system periodically synchronizes
receiver loudspeaker clocks. In block 104 timestamp request is sent
to receiver. If reply is not received within given period, the
system returns to running state and retries the synchronization. If
the synchronization fails several times consecutively, the system
marks receiver loudspeaker as inactive and removes it from the
group of active receivers. If TIMESTAMP is received from receiver,
system enters to state 105. In block 105 the system determines
network latency for the synchronization transaction. If it is above
the maximum acceptable synchronization network latency determined
in 101, the system enters state 108. If the latency is below
acceptable maximum, the system enters to state 106. In state 106
system sends SET CLOCK message to receiver. In block 107, if time
since last latency analysis is below given threshold value, the
system enters to state 102, RUNNING. If time elapsed since last
analysis is too large, the system reanalyzes network latency to
receiver to detect if network latency has been permanently reduced
by entering to state 101. In block 108, if more than given number
of consecutive synchronization transactions have network latency
larger than the acceptable maximum, the system performs latency
analysis in order to determine permanent growth of network
latency.
[0093] According to one embodiment of the invention, the proposed
synchronization method can principally be utilized also in wireless
audio applications, said, wireless loudspeaker systems.
[0094] Due to the lower transfer rate and delays introduced by the
media access control of standard wireless networks, such as 802.11
a/b/g, the network latencies are considerably larger than in wired
100 Mbps or 1000 Mbps Ethernet networks. The synchronization
protocol can adapt to this increased latency as it analyses
networks behavior during the setup phase.
[0095] Standard wireless networks also introduce random latency in
order to prevent collisions during packet transmissions. These
random delays make the synchronization in wireless networks more
difficult that in Ethernet based wired networks. The effects of
said random delays can be reduced by selecting the acceptable
maximum network latency using more strict percentage value than
when operating in wired networks. If percentage of 30% is used
instead of 90%, only transactions with less random delay will be
used for clock synchronization. This modification means that each
clock synchronization requires on average 3 ECHO REQUEST/ECHO REPLY
transactions before acceptable values are acquired for SET CLOCK
command.
[0096] Wireless networks also typically have much larger packet
loss than Ethernet--based wired networks due to radio interference
and collisions during packet transmissions. To reduce the effects
of packet loss a Forward Error Correction (FEC)--encoding may be
used to add redundancy in transmitted audio data. This redundancy
may be used by receiver to reconstruct the audio packets lost by
the network.
* * * * *