A Horizon desktop can't hear your microphone unless Real-Time Audio-Video is installed, working, and allowed. Pithflow doesn't need it: your voice is captured on the local machine, cleaned up, and delivered into the Horizon desktop as pasted or typed text — the client-to-server direction Horizon's clipboard policy permits by default.
Because the desktop is a virtual machine in a data center and your microphone is plugged into the device on your desk. Something has to carry audio between them, and in Horizon that something is Real-Time Audio-Video (RTAV) — a Horizon Agent feature that presents your local webcam and microphone as virtual devices inside the session. Where RTAV isn't deployed, isn't configured, or is blocked by policy, in-session dictation tools like Win+H open a listening panel connected to nothing.
The fallback Omnissa's documentation names — USB redirection of the audio device — is the option admins avoid: per the same docs, RTAV exists precisely because it "redirects video and audio data with a significantly lower bandwidth than can be achieved by using USB redirection."
For conferencing, yes — Omnissa's docs frame RTAV around running Teams, Webex, and similar apps in the session. For dictation it leaves three gaps. First, it's infrastructure: an agent-side feature plus group policy that your admins control, which is exactly the dependency you were hoping to avoid. Second, even a working RTAV pipeline only gets your audio as far as whatever recognizer runs inside the VM — typically Win+H, with no cleanup pass and no tone control. Third, Omnissa documents a side effect worth knowing: while audio input is redirected to the remote session, the local machine loses access to those same devices, so your mic is committed to one side at a time.
Pithflow runs where the microphone lives. Hold the hotkey, speak, and it captures the audio locally, runs AI cleanup on the transcript, and delivers finished text through the keyboard and clipboard forwarding the Horizon Client already provides — it places the text on your local clipboard and pastes it into the focused window, falling back to typed keystrokes. Punctuation, capitalization, and filler-word removal happen before the text ever reaches the session. The Horizon desktop receives a paste, not a recording.
Only client-to-server — and that's the direction Horizon ships open. The Horizon ADMX policy Configure clipboard redirection (View Agent Configuration › Clipboard Redirection, documented in Omnissa's clipboard redirection guide) defaults to Enabled client to server only when not configured: you can paste into the desktop, but not copy out of it. That default is designed to stop data leaving the session — and pasting dictated text into the session is the one direction it permits.
The honest caveat, every time: if your environment sets that policy to Disabled in both directions, Pithflow's paste path is blocked and only the typed fallback remains. Verify with one seat on the free tier before you plan a rollout.
| Win+H in the session | RTAV + in-session app | Pithflow (local) | |
|---|---|---|---|
| Needs RTAV deployed and allowed | Yes | Yes | No |
| Audio crosses Blast/PCoIP | Yes | Yes | No — text only |
| Changes to the golden image | Agent feature + policy | Agent feature + app install | None |
| Transcript cleanup before it lands | None | Depends on the app | AI cleanup, tones, bilingual ES/EN |
| Blocked by clipboard fully disabled | No | No | Paste path yes — pilot one seat first |
The same product. Horizon left VMware with the end-user-computing divestiture and is developed by Omnissa today — its documentation now lives at docs.omnissa.com. Everything on this page applies to environments still branded VMware Horizon and to current Omnissa Horizon releases alike.
No. RTAV exists to move microphone and webcam data into the remote session. Pithflow never sends audio into the session — it captures your voice on the local machine and only text crosses to the Horizon desktop. Whether RTAV is present, absent, or misconfigured doesn't change that.
Then Pithflow's primary delivery path — placing text on your local clipboard and pasting it into the session — is blocked, and the typed-keystroke fallback is what's left. Don't assume either way: install the free tier on one machine, dictate once into your real Horizon desktop, and you'll know. Pilot one seat before involving anyone else.
Pithflow doesn't talk to the display protocol. It hands finished text to your local machine's input path, and the Horizon Client forwards typing and pasting over whichever protocol the session runs — that forwarding is how you use the desktop at all. If you can type into the Horizon window, dictated text can land there the same way.
No. Pithflow installs on the physical Windows machine running Horizon Client. The golden image, the agent, and the pool configuration stay untouched — there is no server-side component and nothing for image maintenance to track.
Free tier: 2,000 words a week, no card. Installs on your local Windows machine only — the golden image never knows.
Running Citrix or plain RDP instead? Start at the remote desktop dictation hub.