I checked `piper --help` and tested it directly — here's what's actually going on.

**Why the second command hangs**
`piper` has no positional "text" argument at all — text only ever comes from **stdin** (or `-i file.txt`). Your wrapper only reads `$1` for the voice code and never touches `$2`. So:

```
piperttsWraper.sh us "hello world"
```
"hello world" becomes `$2`, which the script silently ignores. `piper` then falls back to reading stdin — but since nothing was piped in, stdin is your terminal, so it just sits there waiting for you to type text and hit Enter (Ctrl+D to end). It's not erroring, it's blocked waiting for keyboard input — which looks exactly like "not working."

**Why the first command is actually correct**
```
echo "hello world" | piperttsWraper.sh us
```
This *is* the right usage. The `echo` pipes into the script's stdin, and since the script's final line (`piper ... | pw-cat ...`) has no explicit input redirect, `piper` inherits that same stdin. I verified this directly — bypassing playback and writing to a file instead:
```
$ echo "hello world" | piper -m en_US-lessac-medium.onnx --sentence-silence 0.2 --output_file /tmp/piper_test.wav
```
produced a valid 35KB wav in under a second. So if that first command *isn't* producing sound for you, the stdin plumbing isn't the problem — something downstream is (likely `pw-cat` targeting the wrong sink, or PipeWire routing). Want me to check that separately?

**Other valid usage patterns**
- Interactive: `piperttsWraper.sh us` then type a line, Enter, Ctrl+D when done
- From a file: `piperttsWraper.sh us < notes.txt`

**On the CPU/memory concern**
My test run: `0.93s` wall time but `7.97s` user time — Piper is multi-threaded and briefly saturates several CPU cores per invocation, even though it's short-lived. Right now there are zero lingering `piper`/`pw-cat` processes, so it's not leaking between calls. But if your nvim integration fires it rapidly (e.g. per keystroke or per line) without waiting for the previous call to finish, overlapping invocations would each spike CPU/memory at once, which could feel like the machine is "losing memory." What's actually triggering piper from nvim — a plugin, a keybinding, something else? That'll tell me whether it's a serialization issue worth fixing.

Separately — want me to patch `piperttsWraper.sh` so `piperttsWraper.sh us "hello world"` works too (treat `$2` as literal text when given, falling back to stdin otherwise)? That'd match the usage you actually tried.