update readme

README.md

@@ -4,38 +4,31 @@
 [![Crates.io](https://img.shields.io/crates/v/creek.svg)](https://crates.io/crates/creek)
 [![License](https://img.shields.io/crates/l/creek.svg)](https://github.com/RustyDAW/creek/blob/main/COPYRIGHT)
 
-Realtime-safe disk streaming to/from audio files using [Symphonia](https://github.com/pdeljanov/Symphonia) to support a variety of codecs. Refer to [Symphonia's documentation](https://docs.rs/symphonia/latest/symphonia/#support) for supported codecs. Symphonia's Cargo features are exposed with the prefix `decode-`, except `aac` and `isomp4` which creek does not work with yet. For example, to enable MP3 decoding in creek, enable the `decode-mp3` feature.
+Realtime-safe streaming to/from audio files on disk.
+
+The included decoder uses [Symphonia](https://github.com/pdeljanov/Symphonia). Refer to [Symphonia's documentation](https://docs.rs/symphonia/latest/symphonia/#support) for supported codecs. Symphonia's Cargo features are exposed with the prefix `decode-`, except `aac` and `isomp4` which creek does not work with yet. For example, to enable MP3 decoding in creek, enable the `decode-mp3` feature.
+
+The included encoder only supports the WAV format.
 
 ## How the Read Stream Works
 
 ![how it works](how_it_works.svg)
 
-The stream has two types of buffers: a `cache` buffer and `look-ahead` buffer.
+The stream internally has two types of buffers: a `cache` buffer and `look-ahead` buffer.
 
-A `cache` buffer is a user-defined range (of a fixed user-defined number of blocks) starting from any frame in the file. Caches must be loaded before they can be used. The default size for a block is 16384 frames in length.
+A `cache` buffer is a pre-loaded user-defined range of samples in the file.
 
-There are a number of `look-ahead` blocks ahead of the currently used cache block/playhead. These automatically load-in to ensure that data will always be ready even in the worse-case IO latency scenerio. A number of `look-ahead` blocks are added to the end of every `cache` buffer to ensure enough data is always available.
+The stream can have as many `cache` buffers as desired. A common use case for this is to cache the start of a file or loop region for seamless looping. When seeking to a frame in the file, creek searches if there exists a cache that contains that frame. If one exists, then playback can resume immediately without buffering.
 
-The stream can have as many `cache` buffers as desired. When seeking to a frame in the file, the stream searches for a cache that contains that frame. If one does, then it uses it and playback can resume immediately. A common use case is to cache the start of a file or loop region for seamless looping.
+The `look-ahead` buffer is used to automatically load frames ahead of the playhead, ensuring that data will always be ready even in a worse-case IO latency scenario.
 
-If a suitable cache is not found (or the cache is not loaded yet), then the `look-ahead` buffer will need to fill-up before any more data can be read. In this case, you may choose to either continue playback (which will output silence) or to temporarily pause playback.
+If a suitable cache is not found (or the cache is not yet loaded), then the `look-ahead` buffer will need to be filled first before any more data can be read. When that happens, you may choose to either continue playback (which will output silence), or temporarily pause playback until data is available.
 
-This stream automatically spawns an "IO server" that handles the non-realtime safe operations. This server is automatically closed when the stream is dropped.
+Creek automatically spawns an "IO server" thread that handles the non-realtime operations. This server is automatically closed when the stream is dropped.
 
 ## How the Write Stream Works
 
-The write stream works how you would expect. Once a block is filled with data, it is sent to the IO server to be written. This block is also recycled back to the stream after writing is done.
-
-### Codecs (Encode)
-
-| Codec  | Status                                          | Default |
-| ------ | ----------------------------------------------- | ------- |
-| Wav    | :heavy_check_mark: Uncompressed, no channel map | Yes     |
-| FLAC   | ? Not currently on roadmap                      | No      |
-| MP3    | ? Not currently on roadmap                      | No      |
-| Opus   | ? Not currently on roadmap                      | No      |
-| PCM    | ? Not currently on roadmap                      | No      |
-| Vorbis | ? Not currently on roadmap                      | No      |
+The write stream works how you would expect. Once a block is filled with data, it is sent to the IO server thread to be written. Once the server thread is done with that block, it sends it back to the write stream to be reused.
 
 ## Examples
 
@@ -118,10 +111,10 @@ write_disk_stream.write(
 
 ### Demos
 
-- A basic [`looping demo player`] that plays a single wav file with adjustable loop regions.
+- A basic [`player app`] that plays a single wav file with adjustable loop regions.
 - A basic [`writer app`] that records a tone to a wav file.
 
-[`looping demo player`]: https://github.com/MeadowlarkDAW/creek/tree/main/demos/player
+[`player app`]: https://github.com/MeadowlarkDAW/creek/tree/main/demos/player
 [`writer app`]: https://github.com/MeadowlarkDAW/creek/tree/main/demos/writer
 
 ## Contributing