-
Notifications
You must be signed in to change notification settings - Fork 142
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
Cross fade #237 #523
Cross fade #237 #523
Conversation
I believe @Chaphasilor was working on this, they may be able to help :) |
I was not, but my suggestion would be to pause the crossfading player a few seconds later. Maybe fade the volume down again until the actual track is playing? |
The timing isn't perfect and I can't think of any way to account for the latency added by seeking. Fading the volume down may work, but I'm not sure how well. I have no way knowing when the track is actually playing after the seek and just adding a few seconds would sound bad on devices that seek really fast. |
Hi @BobcatNoah, sorry that I never managed to take a closer look. |
From my testing, I noticed that different devices had different delays for when you call the play method and when it actually starts playing. This meant I can never perfectly sync up the transition between the songs. On my phone, it might sound fine but on a car stereo, there might be a noticeable delay. |
Hmm, okay. Maybe just_audio will get cross-fase support at some point, but that might be a while. The two player approach would be the best solution for cross-fading, but I don't think it would play nicely with the queue and the player itself. |
I didn't even consider the queue being a problem. I guess I'll have to put this on hold until just_audio add crossfade. |
This PR is work in progress and will implement cross fade #237 between songs. The code is not complete because I want someone to review it before I move forward and there is a major issue I need help with.
I don't have a video example right now, but the issue is that the cross fade is being paused before the seeking is finished. This causes a noticeable gap on slower devices or when the device is connected to something like a car stereo. The expected behavior is that it waits until the seeking is finished before pausing. I suspect this is being caused by a delay between when the seek function finishes (thus returning and letting the code continue) and when the song actually starts playing again.
Below is a video of expected behavior. This example isn't perfect though due to the issue.
RPReplay_Final1698882594.MP4