Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Read: end playback visibly when the audio source throws a read error

Open
  • Is something wrong?
#161 2 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
3/5
Estimated time
1-2 days
Newbie friendliness
74/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
swift
Domain
audio-video-rtc, desktop

Research direction

Start in Sources/LocalVoice/ReadingAudio.swift, tracing the source.read error path around lines 326–366 and the existing engine recovery path around lines 403–405. Use an isolated throwing ReadingAudioSource fixture to check failures before the first frame and after buffered audio, while confirming not-yet-rendered streaming input still works. Done means each failure settles visibly once with useful retry guidance, preserves text and voice, and Retry can complete.

Written by the indexing model from the issue text.

Description

bug

Outcome and evidence

P2, source-confirmed recovery gap; native fault injection pending. An audio-source read error is swallowed, leaving the player eligible to retry while its playing state can remain active with no audible progress.

Workbench Preview 2.3.0, build 20260928054038, source 00be555139f87d4557f48fcffc132b8621c251a2, unmodified source, macOS 26.5.1 (25F80), Apple M5, built-in display. Identity verified in the running app using Copy build details on 28 September 2026.

Normal installed Listen → Pause → Resume → Stop was exercised with synthetic text and returned to editable text. That pass does not cover this error branch. No live audio file was removed or corrupted.

Owner and bounded change

Source links below pin the earlier audited commit 9578d8cf; the relevant paths were checked against installed 00be5551 and the described behaviour is unchanged. Source findings and native observations are distinguished below.

ReadingAudio.swift uses try? source.read and breaks scheduling on error without finish(false). The tick path around lines 326–340 can attempt scheduling again while frames remain. Engine recovery already reports failure around lines 403–405.

Route an actual source-read failure once through the existing completion/error path. Clear active/paused state, retain the input text and give an actionable retry. Distinguish a thrown error from streaming audio that is not ready yet.

Acceptance

  • An isolated throwing ReadingAudioSource fixture fails before first frame and after some buffered audio; both settle visibly with one useful error.
  • No endless playing state, retry loop or repeated error storm remains.
  • Not-yet-rendered streaming input continues normally.
  • Original text and chosen voice survive; Retry can complete.
  • Retest installed normal playback, Pause/Resume, Stop, seek and export with synthetic material.
  • Report code/fixture validation separately from the signed installed build and audible/hardware checks.

Related: PR #129 and installed verification #140. Use an isolated fixture instead of damaging user audio to reproduce.

Dominant language
Swift
Stars
0
Forks
1
Avg merge
8h 5m
Merged PRs (30d)
215

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from Ship-Work/workbench

All issues in Ship-Work/workbench

Similar issues

More Swift issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.