No, as I do not own an ADI. But afaik, it should not be too complicated at all.

Did you look into the ADI2 remote manual?
https://rme-audio.de/downloads/adi2remote_e.pdf

If you read carefully, you will find a link to "The MIDI protocol used by the ADI-2 Remote is available for downloaded as an Excel document:..."

Ok, its an .ods file. But anyhow, after conversion to xls - there is everything you need, good documented how the ADI-2 Remote App communicates with the unit. Probably it would be even possible to build "your own" ADI Remote App with this information.

Putting this together, according your use case - it should not be too complicated to write a script, which listens to your keyboard's volume wheel inputs and translates/sends the values to midi sysex commands which are sent to your unit.

Thats just an idea...

Cool! You seem to know what we are talking about

Thus its hard as i dont own a DAC, I'll do my best to help out. But I probobly need some time time to dig in deeper into this.

But first of all, it would be helpful to know which exact model you own?

Just to be sure you are trying to communicate with the correct DeviceID -  according the doc:
0x71    ADI-2 DAC
0x72    ADI-2 Pro
0x73    ADI-2/4 Pro SE

Additionally, maybe you have to send a valid command first (see examples tab)?
sth like F0 00 20 0D 71 03 09 F7 (if yours is a "ADI-2 DAC") ?
Where
71 = your device ID
03 = Request to device
09 = all Settings (without EQ Presets and Setup-Names)

Then you should see a Continously received status...

Do you see sth coming from the unit (f.ex via a proper receivemidi in second terminal)?
Maybe https://www.snoize.com/MIDIMonitor/ is easier for monitoring MIDI traffic, too...

What firmware version is installed in your ADI-2 DAC? (FPGA 81, DSP 62 ?)
Does the ADI-2 Series Remote for macOS connect and work?

Make sure Sysex is not disabled in the Midi send app

I mean the app you use to send midi commands to the ADI-2 remote.

Thanks for the help, I feel like we're close!

sendmidi dev "ADI-2 DAC (59651073) Port 1" syx hex 00 20 0D 71 02 0F 00 01

^ This isn't giving me any messages in MIDI Monitor however the following does:

sendmidi dev "ADI-2 DAC (59651073) Port 1" syx hex 00 20 0D 71 03 09

It gives me bunch of responses starting with F0 00 20 0D 71 01 ...

I tried the below commands but not changing levels nor giving any messages through MIDI

sendmidi dev "ADI-2 DAC (59651073) Port 1" syx hex 00 20 0D 71 02 4B 1F 1C
sendmidi dev "ADI-2 DAC (59651073) Port 1" syx hex 00 20 0D 71 02 00 20 02

did anyone figure this out?
im also looking to control adi-2 dac volume level with macOS volume keys...

Hi,I made a small Python app to control the ADI-2 hardware volume directly from Windows volume keys/wheels via SysEx.

You can find it here:
https://codeberg.org/Epocha/rme-volume-controller

This is how the OSD looks:

Quick features:

• Direct SysEx: Volume control for Line/Phones/IEM.

• Win32 Hotkeys: Works with standard keyboard volume keys.

• Sync: Reads current volume from DAC on startup.

• Toggles: Double-click Mute to switch Line Out - Phones.

• GUI: Simple settings for dB steps, colors, and hotkeys.

You'll just need Python and the libs from requirements.txt. Hope it helps someone.

Thanks for the feedback and for the link, it was very helpful. I’m developing this on an ADI-2 DAC FS, so I didn't account for the Pro model's dual phone outputs and different toggle logic.

I’ve just released Version 1.1.0 which addresses the points you mentioned. Using SysEx Index 63 for the toggle command.

Summary of changes in v1.1.0:

• Universal Toggle (Index 63): Replaced my previous logic with the native toggle command. It should now follow your device settings.

• Fixed Sync: Improved the polling to fetch the correct active output and volume levels on startup.

• Pro Profiles: Added separate configuration profiles for Phones 1/2 and 3/4.

• Real-Time Detection: The app now polls the status stream (0x07), so it detects output changes made via the physical remote.

• Instance Lock: Added a Windows Mutex to prevent MIDI port conflicts from multiple instances.

• Extended Debugging: I’ve expanded the debug mode to track raw SysEx data.

Since I don't have a Pro model to test on, if you still encounter any issues, please run it in Debug Mode and send me the log. It would be a great help for debugging the Pro-specific behavior.

Thanks for the testing and feedback.

1) Toggle logic & manual output switching
You are right. The hardcoded sequence was a bad approach. I have renamed the menu item to simply "Toggle Output". It now sends a universal Remap Trigger (Index 63) to the DAC, letting the unit switch outputs based on your personal hardware settings.
Furthermore, the app now passively listens to the DAC's continuous Mute states (0x01). This means if you switch the output manually on the device or via the physical remote, the app detects the new active output instantly and reroutes the OSD/controls without needing you to touch the volume knob.

1a) Sync and Reconnect functions
Fixed. Both functions now perform a proper blocking read during startup or manual sync. The app actively fetches not just the volume arrays, but also reads the current Mute states and continuous stream to precisely determine the active output before updating the UI.

2) Media keys periodically unhooking (Windows OSD appearing)
Great catch. This was actually a symptom of how the older version of the app polled the DAC. The aggressive background USB polling was occasionally choking the Python thread. Windows has a strict timeout for keyboard hooks. If the app takes too long to respond because it's busy reading a heavy USB buffer, Windows bypasses the app and triggers the default system volume OSD.
I completely removed the active background polling and switched to a zero-CPU passive listening thread. This eliminates the thread starvation, so media keys should be highly reliable now.

Summary of the other major changes in this update:

• Zero-CPU Architecture: Replaced the heavy polling loop with a passive listening thread. The app now consumes 0% CPU while idle and only reacts when the DAC actively sends data.

• Audio Stutter (DPC Latency) Fix: Stopped flooding the USB bus with continuous REQ_ALL requests, completely preventing audio pops/stutters during playback.

• Reload Hotkeys: Added a tray menu button to instantly force reclaim media keys from apps that sometimes aggressively steal them (like Tidal or Chrome) without restarting the app.

• Safe UI Threading: Decoupled the Tray Icon image generation from the critical MIDI reading thread so rapid volume changes no longer cause lag.

Great!

That being said, the applet still does not correctly detect the active output on the ADI-2 Pro. Also, when I toggle the output with the hotkey, it also activates the Auto Dark mode for some reason.

It looks like the mask format for the status byte 0x07 is a bit off. As far as I see, on output toggle the unit alternates between 0x15 and 0x05 status, but the app in both cases interprets this as Ph. 1/2 being activated, which is false. Also the app does not correctly detect the active output on startup nor on "Sync from DAC" command (which it did before), instead showing the same Ph. 1/2 output as active. I think it has something to do with bit 0 being set in both cases, so it might be not the correct value/format for the ADI-2 Pro...

Here is the log: https://pastebin.com/65sJtsWq

No, I do not use Auto Dark at all, but when I toggle the output via the app, it gets activated. I have to reset it via the remote or the RME's ADI-2 Remote app.

Thanks for the log.It was exactly what I needed.

Root cause found

Your Pro sends 0x15 (Line Out) and 0x05 (Phones) on toggle. The difference is in bit 4 (line_active), which I now use for Pro/SE models instead of bit 0-1.

But there was a second problem: when line=0, I was defaulting to "Phones 1/2". Your toggle config is idx=10 val=2 (Toggle Ph 3/4), so it should be "Phones 3/4". The 0x07 bit 6 (ph34) that should indicate this is always 0 on your unit in toggle mode so the bitfield alone isn't enough.

Fix
The app now reads your toggle configuration (idx=10) during sync and uses it to determine which phones output is the toggle partner:
- line=1 → Line Out
- line=0 + toggle=1 → Phones 1/2
- line=0 + toggle=2 → Phones 3/4

AutoDark
Also fixed. The app was always turning AutoDark ON after the wake pulse. Now it reads your AutoDark state during sync (idx=35 val=0 = OFF in your log) and skips the wake display entirely your display is always on, nothing to wake.

Please test

1. Update from the repo
2. Keep Debug logging ON
3. Try these scenarios:
   - Start the app → check if correct output is shown
   - Toggle via hotkey a few times → check if it alternates correctly
   - Toggle via physical remote/device → check if the app detects it
   - Check that AutoDark is no longer activated on toggle
4. Send me the log if anything is off

The key log line to verify is:

0x07 resolve: model=ADI-2 Pro active_bits=? line=? ph34=? toggle_cfg=2 -> Phones 3/4

If you have time, I'd also appreciate one extra test: physically switch to each of your three outputs (Line Out, Phones 1/2, Phones 3/4) one by one and note the status 0x07: raw=0x?? value for each. This would give me the complete mapping and help verify the detection for all possible states.

Looks it's more complicated than that; see below.

Confirmed.

Now it detects correctly when Line Out 1/2 is activated, but does not detect the Ph. 3/4 as the active output if I have Toggle Ph/Line option set to "3/4" or "1/2+3/4" — it shows that the active output is Ph 1/2 then.

Now if I set the Toggle Ph/Line option to "All Plugged", then the app detects Ph 3/4 as the active output. If I then plug another headphone to Ph 1/2, and the "Dual Phone Mode" is enabled, the unit then cycles between all three outputs and the app detects this correctly. What is weird enough, is that when I plug headphones in both outputs and have the Toggle Ph/Line option set to "1/2+3/4", it then shows strictly the output 3/4 as active (when actually both phone outputs are active at the same time, each with its own volume setting).

Here is the log, hope you'd be able to figure it out

Sorry about the previous version mix-up, I accidentally pushed an older codebase. v1.2.4 now has the actual fix with the toggle config cache.

Changes based on your logs

- The app now reads your Toggle Phones/Line setting (idx=10) during sync and caches it. After a toggle pulse, when the Pro sends the ambiguous 0x05 status, the app uses your toggle config to determine the correct output instead of guessing.
- Added dual phones mode: when toggle is set to "1/2+3/4", volume wheel adjusts both Phones 1/2 and 3/4 simultaneously (same dB step applied to both, each keeps its own level). Mute also toggles both. OSD shows "PH 1/2+3/4".

What I need from you to nail this down:

Please test each toggle mode one by one and for each one write me which output the app detected vs which output was actually active on the device. The log lines I need to see look like this:

0x07 resolve: model=ADI-2 Pro active_bits=1 line=0 ph34=0 toggle_cfg=2 -> Phones 3/4

If the app says Phones 3/4 but the actual active output on your device is something else, write that. For example: App says Phones 3/4 but actual output is Phones 1/2.

I apologize for the back and forth on this, debugging the Pro output detection remotely is quite challenging since the Pro has significantly more toggle combinations and output routing options compared to the ADI-2 DAC I develop on. Your logs and feedback are invaluable.

Hello,

I've a DAC 2 FS, a Stream Deck and Windows 25h2.

@Epocha : your script (v1.2.4) is working fine with Stream Deck default System Volume plugin (El Gato drivers 7.4.0) which is great !

I you don't know what to code you can make your script a native Stream Deck plugin

Thanks for your work.

Not everybody own a Stream Deck so the Python version has to stay alive

There are options to dev plugins without owning a physical Stream Deck :

• there is a Stream Deck Simulator : https://docs.elgato.com/ipad/simulator/

• an emulator : https://github.com/FritzAndFriends/StreamDeckEmulator

• there is a mobile version https://www.elgato.com/us/en/explorer/p … for-free/,  which offers 6 free buttons which can be used in an android emulator (not sure if you can simulate a rotary encoder with this) : https://www.reddit.com/r/elgato/comment … ream_deck/

Do you plan to add an autoupdate feature ? or at least a check if a new version is available option ?

v1.3.0 Released - Playing OSD, Auto-Update
What's New

Playing OSD
The app now shows a custom "Now Playing" overlay when tracks change, triggered by play/pause, or optionally on volume changes. It uses the same dark design as the Volume OSD. Consistent look across both overlays.

- Track name, artist, album art, and a progress bar with timestamps
- Album art fetched via Windows Media API, preserving aspect ratio (square for music, wide for YouTube thumbnails)
- Bouncing marquee scroll for long titles that don't fit
- Play/pause indicator icons
- All independently configurable: position, size, opacity, duration, colors
- Drag-to-place positioning

The progress bar interpolates between API updates, so it runs smoothly even when the source app only updates position data every ~30 seconds.

App Filter
The app auto-detects which programs are playing media (Spotify, foobar2000, browsers, etc.) and lets you choose which ones should trigger the Playing OSD. Detected apps show up as checkboxes in Settings with live refresh. Just play something and it appears. You can also add app IDs manually.

Auto-Update Checker
The app checks for new releases on Codeberg on startup and periodically. When an update is available, dialog pops up with the changelog and options: Update now, Skip this version or Later. The update script auto-detects your git branch, does git fetch + git reset --hard, and reinstalls dependencies if requirements.txt changed.

Settings UI Overhaul
Everything is now organized into tabs: General, Volume OSD, Now Playing, Hardware, Updates. Much easier to navigate with all the new options.

!Important: New Dependency!

This release adds winsdk as a dependency (required for Now Playing/media control). If you're updating an existing install:

venv\Scripts\activate
pip install -r requirements.txt

Or for a fresh install:

git clone https://codeberg.org/Epocha/rme-volume-controller.git
cd rme-volume-controller
python -m venv venv
venv\Scripts\activate
pip install -r requirements.txt

Playing Modes (Settings → Now Playing)

- default - no changes, Windows handles everything
- hide - intercepts media keys to suppress Windows overlay, no custom OSD
- custom - full Playing OSD with all the features above

Since it works when you alt-tab back, the app and DAC connection are fine. The issue is that the fullscreen game is capturing the key events before they reach our hotkey handler.

I've just pushed v1.3.1 which includes diagnostic logging for exactly this scenario.

Once updated, could you test with Debug mode ON (Settings -> General -> Debug mode):

1. Start the app
2. Change volume on desktop. Confirm it works, check log for lines like:

2026-04-20 23:51:14,506 [DEBUG] LL hook: VK=0xAF (VolUp) flags=0x11
2026-04-20 23:51:14,508 [DEBUG] WM_HOTKEY received: id=1

3. Go into the game (fullscreen)
4. Try changing volume in-game
5. Alt-tab out, check the log file (right-click tray icon -> Open log)

What we're looking for:
- If both LL hook: and WM_HOTKEY lines are missing while in-game the game is blocking all key events at a low level (DirectInput exclusive mode)
- If LL hook: appears but WM_HOTKEY is missing the low-level hook sees the key but RegisterHotKey doesn't receive it in fullscreen
- If neither appears the game is consuming the keys entirely before Windows can process them

Quick workaround: switch the game to borderless windowed mode instead of exclusive fullscreen. Hotkeys should work there since Windows keeps processing them normally.

v1.3.1 also adds a few new features: volume slider popup (left-click the tray icon), sample rate display in the tray tooltip, and AutoDark on idle. Full changelog on the release page.

I saw that 1.3.2 was available, but I can't update to it. Even with a fresh install, I remain on 1.3.1 and the notice of a newer version upon starting the script remains. I've updated before so not sure if I did it wrong here but maybe someone else can chime in.

@stfn @PouyouxRME sorry about that. As PouyouxRME correctly spotted, I forgot to bump the version number in the script for v1.3.2. Just pushed v1.3.3 which fixes this and a few AutoDark reliability improvements.