Skip to content

v4.1 Modify log parsing and DAC sample rate switching process @horikei525 - #216

Open
horikei525 wants to merge 31 commits into
vincentneo:mainfrom
horikei525:main
Open

horikei525 wants to merge 31 commits into
vincentneo:mainfrom
horikei525:main

Conversation

@horikei525

Copy link
Copy Markdown

v4.1 Release Notes

In the previous v2 version, the application monitored Apple Music logs via "MediaRemote" to synchronize the sample rate. However, this approach forced an inherently contradictory behavior: as an app designed to synchronize sample rates for the highest quality audio experience, the noise generated by the DAC switching sample rates mid-playback would constantly interrupt the music, making it feel almost as if the noise was being introduced intentionally.

With this new v4.1 release, we have fundamentally resolved these core issues.

Our analysis of the Apple Music logs revealed that the system outputs the sample rate to the "log stream" first, and then to "MediaRemote" approximately 100ms later. Consequently, we have switched our monitoring target to the "log stream." The application now operates based on the following two scenarios:

1. Automatic Track Transitions within a Playlist (No User Interactivity)

  • Pre-emptive Detection: The app constantly measures the remaining time of the current track in seconds. At the 1.5-second mark remaining, it begins checking for sample rate changes every 2ms. As soon as the track changes, the new sample rate appears in the log stream.
  • Immediate Muting: The app instantly mutes Apple Music.
  • Pause via AppleScript: Next, it sends a pause command directly to Apple Music's memory space using AppleScript, effectively bypassing the OS layer. (Muting is executed first because it is faster).
  • DAC Switch Request: The app then requests the DAC to change its sample rate.
  • Status Checking & Rewinding: While waiting for the DAC to complete the switch, the app checks the status every 2ms. Since roughly 20ms of audio gets played during the sample rate retrieval process, the app automatically rewinds the playback position back to 00:00.
  • Playback Resumption: Once the DAC configuration is complete, Apple Music is unmuted, and playback resumes seamlessly.

Note: This active switching process itself consumes about 40% CPU capacity. While this is roughly the same as v2.0, the processing time lasts only a fraction of a second.

2. Manual Track Changes by the User

When a user manually skips or selects a track, the behavior adjusts slightly to prevent errors:

  • If the playback position is reset to 00:00 while the DAC is still mid-switch, Apple Music incorrectly assumes that the user's selected track failed to play. This triggers a bizarre bug that defaults back to playing the very first track in the playlist.
  • To prevent this, the app waits until the DAC switch is entirely finished before rewinding to 00:00. This provides Apple Music with a buffer of over 100ms until the DAC is fully ready, successfully avoiding the error.

By implementing these behaviors, the sample rate can be changed rapidly without the user even noticing.

Test Environment & Stability

During my internal testing with a MacBook Air M2 (macOS 26.5.2) paired with the Moondrop Dawn PRO, ECHO-A, and ECHO-B, the behavior appeared highly stable.

Future Roadmap

However, similar to v2, bit-depth switching remains unstable at this time. We will continue to target improvements for this behavior in future updates.

@horikei525

Copy link
Copy Markdown
Author

Sorry to keep you waiting.
I'm glad I gave up on the virtual audio setup.

@horikei525 horikei525 changed the title v4.1 @horikei525 v4.1 Modify log parsing and DAC sample rate switching process @horikei525 Jul 13, 2026
kkgs-32-lab added 3 commits July 13, 2026 16:52
…layback position of a song requiring a sample rate change.
…layback position of a song requiring a sample rate change.
@vincentneo

Copy link
Copy Markdown
Owner

Thanks for your work on this! I will try this out someday!

kkgs-32-lab added 2 commits July 28, 2026 10:01
…ication upon connected device changes, and prevention of playback rewinding.
…ication upon connected device changes, and prevention of playback rewinding.
@horikei525

Copy link
Copy Markdown
Author

We resolved the issue of the process launching twice and implemented fixes to ensure immediate format application and prevent rewinding when changing connected devices.

@horikei525

Copy link
Copy Markdown
Author

Smart Mid-Song Format Handling & New Upgrade Preference Toggle

  • Automatic Downgrade Filtering: Wi-Fi or network fluctuations during playback often cause Apple Music to temporarily drop streaming quality (e.g., 48kHz ➔ 44.1kHz). LosslessSwitcher now automatically ignores mid-song downgrades to eliminate annoying audio dropouts, pops, and mutes in the middle of a song.
  • Customizable Upgrade Following: Added a new setting to the menu bar dropdown:
    "Follow Quality Upgrades Mid-Song (Causes Interruption)"
    • ON (Default): If Apple Music upgrades streaming quality mid-song (e.g., 48kHz ➔ 96kHz), LosslessSwitcher will update the DAC format to prioritize higher quality.
    • OFF: All mid-song format changes are ignored to guarantee uninterrupted playback from start to finish.
    • Note: Native track-to-track format switching at the start of every song remains 100% bit-perfect and unaffected.

@horikei525

Copy link
Copy Markdown
Author

🐛 Fix: Reliable Native Track Format Switching Regardless of Mid-Song Settings

Problem

Previously, the app relied on a 5-second timer heuristic to determine whether a decoder log was a "mid-song update." However, Apple Music often takes 6 to 10 seconds to output the initial decoder log after a track change.
When the "Follow Quality Upgrades Mid-Song" setting was turned OFF, the app misclassified the delayed initial log of a new track as a "mid-song update" and ignored it, leaving the DAC sample rate stuck on the previous track's rate.

Solution

  • Introduced a dedicated state flag (isAwaitingInitialFormatForTrack) that resets upon every track change.
  • The first decoder log received for a new track is now 100% guaranteed to be processed as the track's native initial format and applied to the DAC immediately, regardless of buffering delays or mid-song settings.
  • Subsequent logs for the same track are correctly classified as mid-song updates and follow the user's mid-song upgrade/downgrade preference settings.

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