-
-
Notifications
You must be signed in to change notification settings - Fork 87
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Unnecessary switching to intermediate 48hz rate before going to 96khz #134
Comments
The problem is due to Apple Music sometimes logging lower resolution values in the first few seconds of playback, which LosslessSwitcher ends up picking up. As such, this issue remains unsolvable at present. |
I agree with you; this is something Apple is doing,and it seems to do it consistently. Whenever the sample rate needs to change from the current rate to another rate it always changes first to 48khz, then after a second or two it changes to the correct rate. So I believe it should be possible for you to wait for that short period,to see if it changes a second time, before changing to The only time this won't apply is when the actual sample rate should be 48khz; but then, after the short wait, it will still be at 48khz. |
I can consider trying this |
That would be great! Thanks. |
Not sure if I should open a separate issue, but the issue I am facing might be a subset of the above issue mentioned - wherein the sample rate gets set to 96 kHz, but then switches back to 48 kHz. This happens when the song is played from anywhere in Apple Music except Library. When it is played from Library, this issue does not occur. The CPU usage for Lossless Switcher also becomes 60-100% for a few seconds when this happens. Build version: |
Whenever Apple Music switches from 44.1khz to 96khz music, instead of switching directly to 96khz an intermediate 48khz is first applied.
This is causing problems for my own app, which is watching for sample rate changes on the output device, and making decisions based on those.
Can this intermediate switching somehow be avoided?
The text was updated successfully, but these errors were encountered: