Skip to content

ASIO open retry after a quick failure - #1013

Merged
bonninr merged 1 commit into
devfrom
fix/asio-patience
Nov 9, 2026
Merged

bonninr merged 1 commit into
devfrom
fix/asio-patience

Conversation

@bonninr

@bonninr bonninr commented Nov 9, 2026

Copy link
Copy Markdown
Owner

For #1007.

ASIO devices now retry a failed open. Some ASIO drivers (the MOTU 24AO in #1007) need a second or more to lock their clock after a sample rate change. JUCE starts the device 10 ms after it sets the rate, so the first open fails with "Can't start device". The player then moves the rate back and forth until one open lands.

PatientDevice wraps each ASIO device:

  • On a quick failed open it closes the device, waits, and opens it again with the same channels, rate and buffer.
  • Waits: 20, 80, 320 and 1280 ms, 1.7 s in all before it reports the error. 20 ms settles a professional card; the longer waits cover a driver still locking its clock.
  • A device that opens at once is opened once, with no wait.
  • Only a failure under 1 s gets another attempt. "Device didn't start correctly" comes after JUCE's own 3 s wait for a first callback, so a dead driver fails once, as before.
  • The log records each retry and the attempt that opened.

PatientDeviceType wraps the ASIO type: its device list, default device, index lookup and change notices are the ASIO type's own. The driver's reset requests reach the device manager as before.

The wrapper covers every open: the saved device at startup, the Audio settings dialog, the first-run wizard, and the output pairs the mixer opens.

Tests

  • functional.audio.patient-open:
    • A driver failing twice opens at the third attempt, each attempt at the same 96 kHz, 1024 samples and 4 outputs, closed after each failure.
    • A ready driver opens once.
    • A driver that never opens reports its own error after one attempt per wait and the first.
    • A slow failure is reported after 1 attempt.
  • functional.audio.patient-type: the list, default and scan are the wrapped type's; a created device is patient, found at its place in the list, and opens at its second attempt; the wrapped type's change notices reach listeners.
  • Windows mp_tests --no-perf: 520 run, 0 failed.
  • In the program, on the test machine's Realtek ASIO and ASIO4ALL drivers: both load and deliver no callbacks at any rate ("Device didn't start correctly" after 3 s). The first build retried that failure too and held startup for 14 s per driver. With the 1 s limit each driver gets one attempt, and the window opens at 13 s. The test machine has no driver with the quick failure of ASIO - Motu #1007; the fake driver above covers it.

An ASIO driver still locking its clock after a sample rate change fails
its first open with "Can't start device" (#1007). PatientDevice closes
the device and opens it again with the same channels, rate and buffer
after 20, 80, 320 and 1280 ms. Only a failure under 1 s gets another
attempt: JUCE's 3 s wait for a first callback already covers a slow one.
@bonninr
bonninr merged commit 8a674a6 into dev Nov 9, 2026
21 of 22 checks passed
@bonninr
bonninr deleted the fix/asio-patience branch November 9, 2026 15:50
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants