The present invention relates to processing audio data for use in a communication session.
Communication systems exist which allow users of the communication system to communicate with each other over a network. Each user can communicate in the communication system using a user terminal Data can be sent between user terminals over the network to thereby facilitate a communication session between users of the communication system.
A user terminal may comprise a microphone for receiving audio data for use in a communications session. The audio data may be speech data from a user, or any other type of audio data which is to be transmitted in the communication session. The audio data received at the microphone is an analog signal. The analog signal can be converted into a digital signal by an analog to digital converter in the user terminal. An analog to digital converter samples the analog audio data at regular time intervals (at a sampling frequency fs). The sampled audio data can then be quantized, such that the samples are assigned a binary number approximating their sampled value. In this way the audio data can be represented as a digital signal. The digital signal may then be encoded and packetized before being transmitted over the network to another user terminal engaging in a communication session. In this way the user terminal can receive audio data, sample the audio data and transmit the sampled audio data over the communication system as part of a communication session. The processing operations performed on the received audio data may be performed by an audio codec at the user terminal.
The sampling frequency with which the audio codec samples the audio data may be set, for example either when an application for communicating over the communication system starts up at the user terminal or when a communication session (e.g. a call) is initialized.
According to a first aspect of the invention there is provided a method of processing audio data for transmission over a network in a communication session between a first user terminal and a second user terminal, the method comprising: transmitting samples of audio data which have a sampling frequency and which provide a digital representation of an analog audio signal from the first user terminal to the second user terminal in the communication session; during the communication session, repeatedly determining an estimate of processing resources available for processing audio data in the communication session; and dynamically adjusting the sampling frequency during the communication session based on the determined estimate of available processing resources.
The method may further comprise sampling the analog audio signal at the first user terminal during the communication session to thereby generate said samples of audio data for transmission to the second user terminal. Alternatively, the method may further comprise accessing an audio data file at the first user terminal to thereby retrieve said samples of audio data for transmission to the second user terminal.
The step of sampling an analog audio signal may comprise sampling the analog audio signal at the sampling frequency. In that case, the step of dynamically adjusting the sampling frequency may comprise adjusting the frequency at which the analog audio signal is sampled.
Alternatively, the step of sampling an analog audio signal may comprise: sampling the analog audio signal at an initial sampling frequency to generate intermediate samples of audio data having the initial sampling frequency; and resampling the intermediate samples of audio data, thereby applying an adjustment to the initial sampling frequency of the audio data to thereby generate said samples of audio data at the sampling frequency. In that case the step of dynamically adjusting the sampling frequency may comprise adjusting the initial sampling frequency at which the analog audio signal is sampled and/or adjusting the adjustment applied in the resampling step.
The processing resources may comprise processing resources at the first user terminal. Additionally or alternatively, the processing resources may comprise processing resources at a node (e.g. the second user terminal or a network server), other than the first user terminal, which processes audio data in the communication session, and in that case the step of determining an estimate may comprise receiving, at the first user terminal from the node, a sample frequency adjustment request based on an estimation of the processing resources available at the node.
Preferably, the sampling frequency is increased when the determined estimate of available processing resources increases, and the sampling frequency is decreased when the determined estimate of available processing resources decreases.
In preferred embodiments, the step of estimating the processing resources available at the first user terminal is repeated with a frequency which is high enough that the latest estimate of the processing resources available at the first user terminal is an accurate estimate of the current processing resources available at the first user terminal throughout the communication session. In this way the method can be thought of as continuously estimating the available CPU resources during a communication session (e.g. a call).
The communication session may be an audio communication session in which audio data, but no video data, is transmitted between user terminals. Alternatively, the communication session may be a multimedia communication session involving the transmission of audio data and video data between user terminals. The communication session may be a call between at least two users in the communication system. Alternatively, the communication session may be a call from one user to a voicemail service of another user in the communication system. The audio data may be speech data.
According to a second aspect of the invention there is provided a user terminal for processing audio data for transmission over a network in a communication session between the user terminal and a further user terminal, the user terminal comprising: means for transmitting samples of audio data which have a sampling frequency and which provide a digital representation of an analog audio signal to the further user terminal in the communication session; means for repeatedly determining, during the communication session, an estimate of processing resources available for processing audio data in the communication session; and means for dynamically adjusting the sampling frequency during the communication session based on the determined estimate of available processing resources.
According to a third aspect of the invention there is provided a communication system comprising: a user terminal according to the second aspect of the invention; and the further user terminal.
According to a fourth aspect of the invention there is provided a computer program product comprising a non-transitory computer readable medium storing thereon computer readable instructions for execution by a processor at a first user terminal for processing audio data for transmission over a network in a communication session between the first user terminal and a second user terminal, the instructions comprising instructions for: transmitting samples of audio data which have a sampling frequency and which provide a digital representation of an analog audio signal from the first user terminal to the second user terminal in the communication session; during the communication session, repeatedly determining an estimate of processing resources available for processing audio data in the communication session; and dynamically adjusting the sampling frequency during the communication session based on said determined estimate of available processing resources.
Speech and audio codecs can code the audio data making up an audio signal at different sampling frequencies, and it is possible to adjust the sampling frequency (also known as the “sampling rate”) without interrupting the signal flow. In other words, the sampling rate can be dynamically adjusted during a call, or other communication session. Increasing the sampling rate improves the perceived quality of the audio signal but also increases the consumption of CPU resources. The user's perception of the quality of a communication session may depend upon the sampling frequency which is used by the audio codec. Setting a relatively high sampling frequency will result in a relatively high perceived quality of the audio signal but also will also result in a relatively high consumption of CPU resources which may lead to CPU overload, which in the worst cases can cause some parts of the audio signal to be lost. On the contrary, selecting a relatively low sampling frequency will result in a relatively low perceived quality of the audio signal, but will result in a relatively low likelihood of a CPU overload occurring.
The sampling frequency may be set when an application for communicating over the communication system starts up at the user terminal or when a communication session (e.g. a call is initialized and may depend upon an estimate of the available processing resources (CPU resources) at the user terminal at the time of setting the sampling frequency. The inventors have realized that the amount of available CPU resources is not always known at the moment that the audio codec is initialized at the start of a communication session. For example, the clock frequency of modern CPUs is often dynamically adjusted based on the CPU load. This may result in an underestimation of available CPU resources when estimated at the moment of codec initialization when the CPU clock frequency is relatively low. Such an underestimation of the available CPU resources may lead to the implementation of a lower sampling frequency than necessary, thus lowering the perceived audio quality of the sampled audio data.
The inventors have identified another reason why the available CPU resources may not be known at the start of a call and that is that the CPU is often shared between multiple tasks or processes. These tasks or processes may start or stop, or change their CPU consumption during the call. This can lead to either underestimation or overestimation of the CPU resources available for use in the communication session. Overestimation of the available CPU resources may lead to the implementation of a higher sampling frequency than necessary, which in turn may lead to CPU overload at the user terminal In the worst cases, CPU overload causes some parts of the audio signal to be lost.
The inventors have therefore realized that it can be beneficial to dynamically adjust the sampling frequency of a speech or audio codec based on the available CPU resources. The problems described above can be solved, or at least alleviated, by repeatedly estimating the available CPU resources during a communication session, and, based on those estimations, dynamically adjusting the sampling frequency of the samples of audio data. The adjustment of the sampling frequency may be based on the available CPU resources at the sending user terminal. Additionally, or alternatively, the adjustment of the sampling frequency may be based on the available CPU resources at the receiving user terminal, or at a server node in the communication session.
Dynamically adjusting the sampling frequency creates a wider range of consumption levels for processing resources than is possible with a fixed sampling frequency. This flexibility can be used to dynamically maximize the perceived quality under the available CPU resources. Alternatively, this flexibility can be used to dynamically maximize the user experience combined over a number of simultaneous processes running on the CPU.
The analog audio signal may be resampled after an initial sampling stage, before being transmitted from the user terminal. The sampling frequency of the audio data which is transmitted from the user terminal may be adjusted by adjusting the sampling frequency of the initial sampling and/or by adjusting the adjustment made to the sampling frequency in the resampling stage. For example, the analog audio signal may be sampled by an analog to digital converter, and then may also be sampled by a resampler before being encoded. The sampling frequency of the samples of audio data which are passed to the encoder may be dynamically adjusted by adjusting the operation of one or both of the analog to digital converter and the resampler based on the determined estimate of available processing resources.
In this specification, the term “available CPU resources” is intended to be interpreted as meaning the processing resources available at the user terminal (or other node as the case may be) for use in processing audio data associated with a communication session.
For a better understanding of the present invention and to show how the same may be put into effect, reference will now be made, by way of example, to the following drawings in which:
a shows a functional block diagram of a user terminal for use in transmitting data packets according to one embodiment;
b shows a functional block diagram of a user terminal for use in transmitting data packets according to another embodiment;
a shows a functional block diagram of a user terminal for use in receiving data packets according to one embodiment;
b shows a functional block diagram of a user terminal for use in receiving data packets according to another embodiment;
Preferred embodiments of the invention will now be described by way of example only.
Reference is first made to
The user terminal 104 is configured to execute a communication client 108, provided by a software provider associated with the communication system 100. The communication client 108 is a software program executed on a local processor in the user terminal 104 which allows the user terminal 104 to engage in calls and other communication sessions (e.g. instant messaging communication sessions) over the communication system 100. The user terminal 104 can communicate over the communication system 100 via a network 106, which may be, for example, the Internet. The user terminal 104 can transmit data to, and receive data from, the network 106 over the link 110.
Preferred embodiments of the operation of the user terminal 104 when participating in a communication session with the user terminal 114 over the communication system 100 will now be described with reference to
a shows a functional block diagram of the user terminal 104 for use in transmitting data packets according to a preferred embodiment. The user terminal 104 comprises an analog to digital converter block 302 which comprises a sampler block 304 for receiving an analog audio signal and a quantizer block 306. An output of the sampler block 304 is coupled to an input of the quantizer block 306. The user terminal 104 further comprises an encoder block 308, a packetizer block 310 and a transmitter block 312. An output of the sampler block 304 is coupled to an input of the quantizer block 306. An output of the quantizer block 306 is coupled to an input of the encoder block 308. An output of the encoder block 308 is coupled to an input of the packetizer block 310. An output of the packetizer block 310 is coupled to an input of the transmitter block 312. The transmitter block is configured to transmit data packets from the user terminal 104 to the network 106, e.g. for transmission to the user terminal 114 as part of a communication session between the users 102 and 112. The sampler block 304 is configured to receive audio data, for example via the microphone 212 of the user terminal 104. In some embodiments, the analog to digital converter block 302 is part of the microphone 212. In other embodiments, the microphone 212 is separate from the analog to digital converter block 302. The received audio data may comprise speech data from the user 102 and/or other audio data picked up by the microphone 212.
The analog to digital converter (ADC) block 302 is implemented in hardware. Analog signals in general are manipulated in hardware, and the role of the ADC block 302 is to convert them to the digital domain where they can be manipulated by software (or firmware). The functional blocks 308 to 312 shown in
In another embodiment, as shown in
With reference to
When a communication session is initiated involving the user terminal 104, or when the audio codec is initiated, the sampling frequency used by the sampler block 304 is set. The value for the sampling frequency may be set in dependence upon an estimate of the available CPU resources at the user terminal 104 when the communication session, or audio codec, is initiated. When there is a relatively large amount of CPU resources available at the user terminal 104 for use in processing data associated with a communication session over the communication system 100, the sampling frequency is set to a relatively high value. This allows the quality of the sampled audio data (i.e. how well it represents the received analog audio data) to be relatively high. However, when there is a relatively small amount of CPU resources available at the user terminal 104 for use in processing data associated with a communication session over the communication system 100, the sampling frequency is set to a relatively low value. This reduces the likelihood of a CPU overload occurring during the communication session, which is beneficial since such CPU overloads may lead to a loss of audio data.
In the embodiment shown in
The sampling frequency may also be set in dependence upon other factors, such as the available network bandwidth with which the user terminal 104 can transmit data over the network 106 to the user terminal 114. As an example, setting the sampling frequency to a relatively high value will result in a relatively high network bandwidth being required for transmitting the audio data over the network 106 from the user terminal 104 to the user terminal 114. Whereas, setting the sampling frequency to a relatively low value will result in a relatively low network bandwidth being required for transmitting the audio data over the network 106 from the user terminal 104 to the user terminal 114. Therefore setting the sampling frequency in dependence upon the available network bandwidth provides a mechanism to prevent exceeding the available network bandwidth.
In step S504 the sampled audio data is sent from the sampler block 304 to the quantizer block 306 and the audio data is quantized by the quantizer block 306. In order to quantize the samples of audio data, each sample is assigned a binary number approximating its sampled value. Quantizing divides up the sampled voltage range into 2n-1 quantizing intervals, where “n” is the number of bits per sample (the sampling resolution). For example, an 8-bit system can identify 28 (256) discrete sampled signal values (255 quantizing intervals).
The output of the quantizer block 306 is a digital signal which represents the analog audio signal received at the sampler block 304, and which has fs samples per second (where fs is the sampling frequency) with the value of each sample being represented by n bits. The audio data output from the quantizer block 306 is received at the encoder block 308. Note that in the embodiment shown in
In step S506 the samples of audio data are encoded in the encoder block 308. The encoding applied by the encoder block 308 may depend upon the type of the audio data. For example, where the audio data is speech data from the user 102, the encoder block 308 may encode the audio data using a speech encoding algorithm, as is known in the art. Other types of audio data, e.g. background noise or music may be encoded differently to speech data.
The encoded audio data is sent from the encoder block 308 to the packetizer block 310. In step S508 the audio data is packetized into data packets for transmission over the network 106. The packetization process implemented by the packetizer block 310 may be dependent upon the type of network 106. For example, where the network 106 is the internet, the packetizer block 310 would packetize the audio data into data packets in accordance with a protocol which is suitable for transmission over the internet. Similarly, where the network 106 is a mobile telecommunications network, the packetizer block 310 would packetize the audio data into data packets in accordance with a protocol which is suitable for transmission over the mobile telecommunications network.
The data packets that are output from the packetizer block 310 are received at the transmitter block 312. In step S510 the data packets are transmitted from the transmitter block 312 over the network 106 to the user terminal 114. The transmission of the data packets from the transmitter block 312 uses the network interface 226 in order to transmit the data packets to the network 106.
There is therefore shown in
The precise implementation of the encoder block 308 and the packetizer block 310 is dependent upon the type of the communication system 100. Furthermore, in some embodiments, the audio data is not encoded and/or not packetized before being transmitted from the transmitter block 312 over the network 106.
In preferred embodiments, the user terminal 114 comprises equivalent functional blocks to those of user terminal 104 shown in
a shows a functional block diagram of the user terminal 114 for use in receiving the data packets transmitted from the user terminal 104 according to a preferred embodiment. The user terminal 114 comprises a receiver block 402 configured to receive the data packets from the network 106. The user terminal 114 also comprises a depacketizer block 404, a decoder block 406 and a digital to analog converter block 408. An output of the receiver block 402 is coupled to an input of the depacketizer block 404. An output of the depacketizer block 404 is coupled to an input of the decoder block 406. An output of the decoder block 406 is coupled to an input of the digital to analog converter block 408.
In operation, the data packets comprising audio data are received at the receiver block 402 from the user terminal 104 via the network 106. The received data packets are passed from the receiver block to the depacketizer block 404. The depacketizer block 404 depacketizes the data packets to retrieve the encoded audio data from the data packets. The encoded audio data is passed to the decoder block 406 which decodes the encoded audio data. The output of the decoder block 406 is a digital representation of the audio data which is input into the digital to analog converter block 408. The digital to analog converter block 408 converts the digital audio data into analog form. The analog audio data is then output from the digital to analog converter block 408 and played out of the user terminal 114 to the user 112, e.g. using speakers of the user terminal 114.
A skilled person would be aware of the precise implementation details of the functional blocks 402 to 408, and may make variations in those implementation details. The digital to analog converter (DAC) block 408 is implemented in hardware. However, the functional blocks 402 to 406 shown in
Furthermore, in some embodiments, some or all, of the functional blocks 402 to 408 are implemented in an audio codec at the user terminal 114.
In another embodiment, as shown in
In preferred embodiments, the user terminal 104 comprises equivalent functional blocks to those of user terminal 114 shown in
During a communication session, the method steps shown in
In step S602 a communication session is initiated between the users 102 and 112, using their respective user terminals 104 and 114 to communicate over the network 106. Audio data is sampled and transmitted from the user terminal 104 to the user terminal 114 (and vice versa) according to the method steps shown in
As described above, when the communication session is initiated the sampling frequency (of the ADC block 302 and/or the adjustment to the sampling frequency introduced by a resampler block 307 in the user terminal 104) is set. For example the audio codec may be initialized when the communication session is initialized, and on initialization of the codec the sampling frequency is set. The sampling frequency may be set according to an estimation of the available CPU resources at the user terminal 104 at the time of initializing the codec. The communication session proceeds and the audio data received at the user terminal 104 is sampled using the sampling frequency which has been set. As described below, the sampling frequency can be set, and then later adjusted dynamically based on available CPU resources.
During the communication session, at some point after the initialization of the communication session, the CPU resources available at the user terminal 104 are estimated again in step S604. In step S606, based on the estimated processing resources available at the first user terminal 104, the sampling frequency is dynamically adjusted during the communication session. This allows the sampling frequency to be altered in response to changes in the CPU resources available at the user terminal 104. The value of the sampling frequency may be adjusted in step S606 based on the latest estimate of the available CPU resources, as estimated in step S604. The sampling frequency can be dynamically adjusted, meaning that the sampling frequency can be adjusted during the communication session. The value of the adjusted sampling frequency is based on the most recent estimate of the available CPU resources. This allows the sampling frequency to be optimized to the current CPU resources available at the user terminal 104. As described above, the sampling frequency of the audio data can be adjusted by adjusting the sampler block 304 and/or the resampler block 307 in the user terminal 104.
The adjustment of the sampling frequency applied by the resampler block 307 can be adjusted in a similar way in which the sampling frequency used by the sampler block 304 is adjusted. The adjustment of the sampling frequency applied by the resampler block 307 may be in addition or as an alternative to the adjustment of the sampling frequency used by the sampler block 304. For example, the sampling frequency of the ADC block 302 can be kept constant and instead the output sampling frequency of the resampler block 307 is adapted. Adjusting the sampling frequency of the resampler block 307 by adjusting the resampling ratio used therein may be less likely to cause glitches in the audio stream than adjusting the sampling frequency of the sampler block 304 of the ADC 302. It can therefore be beneficial to adjust the sampling frequency of the resampler block 307 rather than that of the sampler block 304, in particular because the adjustment is performed dynamically during a communication session.
The sampling frequency of the codec is set at the encoder side. In other words, the encoding process is done at a certain sampling rate, and the decoder decodes a signal with the same sampling frequency. Therefore, if the decoder side wishes to change the sampling frequency (e.g. in response to a determination of the available CPU resources at the decoder side), it will need to communicate this adjustment to the encoder. The same is true for a server in the network: when the server wishes to change the sampling frequency (in response to a determination of the available CPU resources at the server), it will need to communicate this adjustment to the encoder. In order to communicate the adjustment to the sending user terminal, the receiving user terminal (or a server involved in the communication session) can send a sample frequency adjustment request to the sending user terminal. In response the sending user terminal can dynamically adjust the sampling frequency of the audio data which is transmitted in the communication session. In this way, the sampling frequency used at the sending user terminal can be dynamically adjusted based on the CPU resources available at the receiving user terminal, or available at a network server involved in processing the audio data in the communication session (e.g. by routing the audio data to the receiving user terminal). For the sending user terminal 104 it's simpler: it can adjust the sampling rate locally and the decoder will recognize that it receives data encoded at a different sampling rate and adjust for that by either resampling the signal or adjusting the DAC's sampling frequency.
In step S608 it is determined whether the communication session has ended. If the communication session has ended then the method ends in step S610. However, if it is determined in step S608 that the communication session has not ended then the method passes back to step S604 in order for the available CPU resources to be estimated again.
In this way, during the communication session (i.e. from initiation of the communication session until the communication session ending) steps S604 and S606 of estimating the available CPU resources and adjusting the sampling frequency are performed repeatedly. To give examples, steps S604 and S606 may be performed one time per minute, one time per second or one hundred times per second. Steps S604 and S606 may be performed effectively continuously (that is to say with a frequency which is high enough that the latest estimate of the CPU resources available at the user terminal 104 is an accurate estimate of the current CPU resources available at the user terminal 104 throughout the communication session). Preferably, the sampling frequency is adjusted in step S606 based on the most up to date estimate of the available CPU resources estimated in step S604.
The method steps 602 to 610 shown in
Sometimes multiple processes that compete for CPU resources at the user terminal 104 are all in control of one application. For example, a call may start as an audio call, i.e. with only audio data being transmitted, and then during the call the call may become a video call in which audio data and video data are transmitted over the network 106. The user terminal 104 has an audio codec as described above for processing the audio data for the call and has a video codec for processing the video data for the call. The CPU resources consumed by the video and audio codecs can be dynamically adjusted to fit within the available CPU resources. For example, the CPU resources consumed by the audio codec can be adjusted by dynamically adjusting the sampling frequency of the sampled audio data based as described above. The CPU resources consumed by the video codec can be adjusted as is known in the art, e.g. by adjusting the resolution or the frame rate of the video data. In one embodiment the application for the communication session adjusts the sampling frequency of the audio codec such that some measure or estimate of user experience for the entire (audio and video) call is optimized.
More broadly, a plurality of processes (e.g. the audio and video processing processes described above) can be executed at the user terminal 104 during the communication session. A combined measure of the user's experience of the executed processes can be determined, and the sampling frequency can be dynamically adjusted based on the determined combined measure.
Another example of multiple processes competing for CPU resources at the user terminal 104 is when the user terminal 104 is hosting a conference call over the communication system 100. The host of a conference call may also be a network server. As host of the conference, the user terminal 104 will decode the incoming audio streams from all participants in the conference call (e.g. user 112 and other users in the communication system 100 not shown in
The available CPU resources mentioned above are processing resources available for processing the audio data in a communication session. In this sense the available processing resources may include resources available for receiving, sampling, encoding, packetizing and transmitting the audio data, e.g. at the user terminal 104 as described above. The processing resources may also include resources available for receiving, depacketizing, decoding and outputting audio data, e.g. at the user terminal 114 as described above. The available processing resources may also include resources available for receiving and forwarding data packets comprising the audio data at a routing node in the network 106, e.g. in the transmission path between the user terminal 104 and the user terminal 114. Indeed in a broad sense, the available CPU resources include any resources available for performing any processing on the audio data in the communication session between the user terminal 104 and the user terminal 114. The available CPU resources will depend upon other competing processes running on the user terminal 104 (or on another node at which the available processing resources are estimated, e.g. the user terminal 114 or another node in the communication system involved in processing the audio data in the communication session). A person skilled in the art would be aware of a suitable method, or methods, for performing the estimation of the available processing resources, which may, for example, involve determining the total processing resources available at a user terminal and the processing resources used by other processes at the user terminal. The precise details of the estimation of the available CPU resources, being known in the art, are not further described herein.
In some embodiments, the audio data is not sampled at the user terminal 104 from an analog audio signal during the communication session. For example, the audio data may be retrieved from an audio data file rather than being sampled by the sampler block 304 during the communication session. For example, an audio data file may be stored in the memory 224 (or another memory) of the first user terminal 104. The user 102 may decide that the audio data from the audio data file is to be transmitted to the user terminal 114 in the communication session. Therefore, the audio data file is accessed from the memory 224 to retrieve the digital samples of audio data for transmission to the user terminal 114. The digital audio samples may be input into the resampler block 307 shown in
Some applications or codecs can dynamically (i.e., during a call) adjust the sampling frequency based on the available network bandwidth. Lowering the sampling frequency reduces the bitrate of the codec, therefore dynamically adjusting the sampling frequency provides a mechanism to prevent exceeding the network bandwidth. However, this is not the same mechanism as that described above in which the sampling frequency is dynamically adjusted based on the available CPU resources at the user terminal. An aim of the mechanism described above is to dynamically optimize the sampling frequency of the audio codec in dependence on the available CPU resources, such that the sampling frequency is high enough to provide good quality sampled audio data without being so high as to cause CPU overload at the user terminal 104. In some embodiments, the sampling frequency is dynamically adapted based on a determination of the available network bandwidth, as well as on the estimated CPU resources available at the user terminal 104.
The communication system 100 shown in
The method steps described above could be implemented with a computer program product comprising a non-transitory computer readable medium storing thereon computer readable instructions for execution by the CPU 202 at the user terminal 104. Execution of the computer readable instructions at the user terminal 104 may cause the methods steps described above to be carried out.
While this invention has been particularly shown and described with reference to preferred embodiments, it will be understood to those skilled in the art that various changes in form and detail may be made without departing from the scope of the invention as defined by the appendant claims.
This application claims the benefit of U.S. Provisional Application No. 61/427,986, filed on Dec. 29, 2010. The entire teachings of the above application are incorporated herein by reference.
Number | Date | Country | |
---|---|---|---|
61427986 | Dec 2010 | US |