[NUT-devel] [nut]: r651 - docs/nutissues.txt

[diego]

Author: diego
Date: Mon Mar  3 17:58:44 2008
New Revision: 651

Log:
misc spelling fixes


Modified:
   docs/nutissues.txt

Modified: docs/nutissues.txt
==============================================================================
--- docs/nutissues.txt	(original)
+++ docs/nutissues.txt	Mon Mar  3 17:58:44 2008
@@ -16,7 +16,7 @@ C. buffer fullness in seconds
 D. buffer fullness in bytes
 E. transmit time stamps
 
-Values in bytes are sensitiv to packet loss, which can delay initial startup.
+Values in bytes are sensitive to packet loss, which can delay initial startup.
 
 
 These can be stored in one of the following
@@ -122,34 +122,34 @@ Implemented
 
 Issue small-frames
 ------------------
-The original intent of nut frames was that 1 container frame == 1 codec
-frame. Though this does not seem to be explicitly written in nut.txt.
+The original intent of NUT frames was that 1 container frame == 1 codec
+frame, albeit this does not seem to be explicitly written in nut.txt.
 Also it is inefficient for very small frames, AMR-NB for example has 6-32
 bytes per frame.
 
 Solutions:
 A. Enforce 1 container frame == 1 codec frame even if it causes 10% overhead.
 B. Allow multiple frames as long as the whole packet is less than some
-   fixed minimum in bytes (like 256byte)
+   fixed minimum in bytes (like 256byte).
 C. Allow multiple frames as long as the whole packet is less than some
    fixed minimum in bytes (like 256byte) and the codec uses a constant
    framesize in samples.
 D. Use header compression, that is allow to store the first (few) bytes
    of a codec frame together with its size in the framecode table. This
    would allow us to store the size of a frame without any redundancy.
-   Thus effectivly avoiding the overhead small frames cause.
+   Thus effectively avoiding the overhead small frames cause.
 
 It seems the consensus is: A+D With the specified bounds
 
 
 Issue pcm-frames
 ----------------
-No word is said about how many or few PCM samples should be in a frame.
+No word is said about how many or how few PCM samples should be in a frame.
 
 Solutions:
-A. Define an maximum number of samples (like 512)
-B. Define an maximum timespam (like 0.1 sec)
-C. Define an maximum number of bytes (like 1024)
+A. Define a maximum number of samples (like 512).
+B. Define a maximum timespam (like 0.1 sec).
+C. Define a maximum number of bytes (like 1024).
 
 Implemented: A
 
@@ -175,7 +175,7 @@ C. New field in the stream header
 D. Only allow 1 standard interleaving
 
 What about the interleaving of non raw codecs, do all specify the
-interleaving, or does any leave it to the container? If so, our options
+interleaving, or do any leave it to the container? If so, our options
 would be down to only C.
 
 Also a field specific to just raw does not belong in the stream headers.