Imira mirrors the phone screen and audio to a Miracast sink - a TV or an HDMI dongle - over Wi-Fi Direct. No app on the TV, no cables, no network: the phone talks to the sink directly. As far as I know this is the first working Wi-Fi Display source for Sailfish OS. It's still very experimental.
FOR SMOOTH CASTING: MIND YOUR WI-FI
The phone has one radio. If it is connected to your Wi-Fi network on a different channel than the cast, it has to hop back and forth - heard as dropouts, seen as a stuttering or black picture.
- Best: no Wi-Fi connection while casting (Wi-Fi on, but not connected). The cast has the radio to itself.
- Fine: a 2.4 GHz network (this is what i'm using).
- Avoid: 5 GHz networks while casting, or disconnect.
WHAT IS STABLE, WHAT IS NOT
- Mirroring your screen and audio to a TV/dongle works on the tested hardware.
- The convergence direction (the TV as a separate desktop with its own apps) is early and experimental.
- Tested on the Xperia 10 III (Sailfish OS 5.0.0.62) and the Jolla Phone 2026 (Sailfish OS 5.2.0.17), against a Microsoft Wireless Display Adapter V2 and an LG webOS TV. Other phones and receivers (projectors, Samsung TVs, ...) are new territory.
- Your receiver does not work? About -> Diagnostics: switch on the detailed log, try a cast, create a report. It is anonymized, saved in Documents and can be copied straight into the forum or an issue.
- Known rough edge: playing a video in the Gallery WHILE casting can crash the Gallery's playback (hardware encoder and decoder share the video core).
PLEASE READ - WHAT THE PACKAGE INSTALLS SYSTEM-WIDE
Miracast on Sailfish is not possible with the stock system, so this package is invasive by necessity:
- a root systemd service (imira.service) for Wi-Fi Direct, the WFD/RTSP handshake, screen capture and H.264/RTP streaming. It is NOT started at boot: the app starts it when opened (a polkit rule allows exactly this one unit), and it stops by itself when the app is closed;
- a bundled, P2P-capable wpa_supplicant under /usr/libexec/imira/ (the stock one has Wi-Fi Direct compiled out) - used only while scanning or casting;
- a PulseAudio policy file so the daemon can capture the audio without touching the microphone;
- the app runs without the Sailfish sandbox, because it exchanges control/status files with the service.
Nothing leaves your network - the phone streams directly to the receiver. Removing the app removes all of it.
STATUS AND RESPONSIBLE USE
Work in progress, shared as is, no warranty (GPLv3). This touches Wi-Fi and system audio deeply and runs a root service; install it because you want to experiment with Miracast on Sailfish, not because you need a polished tool. Feedback with your phone and receiver model is welcome - ideally with a diagnostics report.
ARCHITECTURES
aarch64 (Sailfish OS 5.0+). No armv7hl build.
Written with Claude Code (Anthropic).
Source, issues, releases: https://github.com/JimKnopfIoT/harbour-imira
| Attachment | Size | Date |
|---|---|---|
| 1.41 MB | 27/09/2026 - 20:03 |
- The picture no longer goes black after a few seconds, which it did with 0.10.4 on the Jolla Phone 2026. The audio capture had stopped asking PulseAudio for a latency; with nothing else asking, PulseAudio then handed the sound over in two-second lumps whose timestamps ran up to three seconds ahead, and the receiver, which keys the picture to the audio clock, threw every frame away. - A new audio clock. The timeline follows the sample position, anchored on arrival times instead of PulseAudio's latency figure, which wobbles around zero and read 711 ms for the first blocks. The old clock jumped by a quarter of a second whenever that figure drifted — heard as the sound swallowing itself every few seconds, and after turning the phone as a black picture. The new one was designed on recorded data and moves by at most a few milliseconds a second. - Sound and picture get a presentation margin of 150 ms, so the audio reaches the receiver before it is due instead of being dropped as late. - One radio, one channel. When the phone is connected to a Wi-Fi network, the cast now asks the receiver for that network's channel, so the radio no longer has to hop between two channels and lose packets on the way — measured as the main cause of remaining dropouts. If the network uses a radar channel (5 GHz, 52–144) that Wi-Fi Direct may not share, or the receiver declines, the app says so and suggests a 2.4 GHz network or disconnecting while casting. - Diagnostics page (About → Diagnostics) for receivers nobody has tested yet. A detailed log records the whole Wi-Fi Direct negotiation, and a report collects everything needed to find out why a cast fails: a fresh search for receivers with what each one says about itself, the connect and handshake logs, the relevant part of the supplicant log, the phone's wireless capabilities, the Wi-Fi channel and, optionally, the channels in use around it. The report is anonymized — MAC addresses cut to the maker part, names of other devices and networks, serial numbers and public addresses removed — and lands in Documents, ready to be copied into a forum post. - Receivers that hand out addresses by DHCP now work. The address used to come only from the Wi-Fi Direct handshake itself, a newer feature many TVs lack; without it the TV never learned where to connect. - "Streaming" now means that pictures are actually going out. Until the receiver has set up the session, the app says "Waiting for receiver". A receiver that never opens the session is given up on after a minute, and such an attempt counts as failed instead of being retried forever. - Every log is in English and time-stamped, and says much more: the receiver's details per attempt, why the supplicant gave up, where the address came from, which channels are in use, and what goes in and comes out of the encoder.
Comments
birdzhang
Sun, 2026/08/23 - 05:39
Permalink
Hi, is it possible to add android apps to TV apps?
JimKnopfIoT
Sun, 2026/08/23 - 09:39
Permalink
@birdzhang I can't answer that — my focus is on native apps for Sailfish OS.