Fade-in effect is present on resumption with BubbleUPNP, Marantz, Kodi, WiiM DLNA renderers

[madbrain76]

What version of Music Assistant has the issue?

2.0.7

What version of the Home Assistant Integration have you got installed?

2024.6.2

Have you tried everything in the Troubleshooting FAQ and reviewed the Open and Closed Issues and Discussions to resolve this yourself?

• [X] Yes

The problem

When pausing and resuming playback onto a BubbleUPNP renderer, there is a crossfade on resumption

How to reproduce

1. install and start BubbleUPNP for Android
2. Make sure the local renderer is enabled
3. in MA, add the DLNA/UPNP player provider
4. in the player settings, enable queue flow mode
5. in the player settings, turn off volume normalization
6. in the player settings, keep "enable crossfade" disabled
7. select the BubbleUPNP player
8. select an album
9. start playback, using the blue "play" button
10. wait at least 10 seconds, or seek to the middle of the track. This is so that pause/resume doesn't restart the track from the beginning.
11. let it play for a few seconds
12. hit pause
13. hit resume
14. playback resumes
15. a fade-in effect is heard at the beginning of playback

Music Providers

File system (remote share)

Player Providers

DLNA/UPNP

Full log output

log.txt

Additional information

Doing the same operation with JRiver MC as the DLNA server & DLNA controller, playback onto the same BubbleUPNP renderer does not have a fade-in effect when pausing/resuming. Thus, it appears the issue is specific to MA.

What version of Home Assistant Core are your running

2024.6.2

What type of installation are you running?

Home Assistant OS

On what type of hardware are you running?

Windows

[OzGav]

Per Marcels comment here it is a deliberate as the steam is resumed https://github.com/music-assistant/hass-music-assistant/issues/2424

[madbrain76]

@OzGav ,

Respectfully, these are different circumstances, and not the same issue.

1) the other issue was on a Chromecast player provider, not DLNA 2) the other issue happened when after changing one of the player settings (sampling rate) 3) normal pause/resume on the Chromecast does not produce any crossfade, as expected 4) in this case, the fade-in happens in a basic pause/resume case with the DLNA player provider. 5) what is the "Enable crossfade = false" setting in the DLNA player supposed to accomplish, if not prevent this from happening ?

[madbrain76]

I verified that there is also no such issue when using Airplay to my Marantz receiver. MA plays to it, and pause/resume does not introduce any crossfade.

Thus, the issue is specific to the DLNA player provider. Please consider reopening it. Pause/resume is something that is done quite frequently, unlike changing player settings.

Crossfade is really inappropriate for some music. There is no workaround in this case when using a DLNA-only player provider such as BubbleUPNP. I can't run an Airplay sink or Chromecast think on my phone or desktop PC.

[marcelveldt]

We use a small "afde-in" effect when the stream is resumed from stop, its just a small touch/feature. It should not happen on unpause but if the device does not support pause/unpause it may instead switch to stop/resume.

Some DLNA devices sont support pause so I guess that's what introduced this.

This has nothing to do with crossfade at all. If crossfade is disabled, its disabled, period.

[madbrain76]

@marcelveldt ,

I just tested 5 different implementations : JRiver MC, BubbleUPNP, Marantz, WiiM, Kodi .

1) My Marantz SR7011, one of 3 Marantz receivers I tried, has the issue 2) 1 of my 12 WiiM Pro Plus I tried has the issue 3) BubbleUPNP (to play on my phone), also has this issue. 4) Kodi also had this issue. 5) JRiver MC has problems with controls from MA (reported separately). Using its own pause/resume controls, the issue does not occur. I don't know what would happen if I got MA controls to work.

It would surprise me if 4 out of these 5 renderers - and possibly all 5, as the jury is still out on JRiver - didn't support pause. I used a tool from White bear to analyze the renderers capabilities, but it doesn't seem to test (or report) the Avt:Pause command, unfortunately.

Would you mind telling me which DLNA renderers this issue doesn't occur with ?

This is not a trivial issue. It drives me up the wall every time I hear one of these effects on my music, whether they are cross-fade or fade-in. Regardless of what you want to call it, this behavior is is not harmless, and it should be possible to disable it. A search query that includes the terms "classical music" and "cross-fade" or "fade in" will show you that I'm far from the only classical or baroque music listener who feels strongly about fade-in/crossfade effects. And both ChatGPT and Gemini have a lot to say on the subject, as well, if you ask if these affects are appropriate for classical/baroque music.

[marcelveldt]

Did you press play within 30 seconds after pause?

After 30 seconds of pause, we automatically stop and free resources.

[marcelveldt]

I think adding a small config toggle to enable/disable the fade-in effect on resume is not that hard, let's pick that up when the other more pressing issues are resolved anyways.

Next to that I'd like to know/confirm if we have a generic issue with pause on DLNA

[madbrain76]

No, it was a very quick pause/resume . Maybe 5 seconds at most.

Thank you for adding this.

[marcelveldt]

OK, in that case 2 have 1 issue and 1 feature request;

issue; dlna appears to be using stop instead of pause request; opt-out of the resume "effect" on resume (from off/idle)

For clarity: the resume effect should never be present when unpausing from pause

[madbrain76]

I see. From a listener's perspective, there is no knowledge of what the underlying DLNA command is. Some of the renderers are likely end-of-life, and it may not be possible to get improvements or bug fixes to their firmware. I doubt my Marantz NR1603 from 2012 is getting any updates, for example, even security related. Not sure about the SR7011. The SR8015 is probably still supported. Even for those renderers still supported (BubbleUPNP, JRiver MC, Kodi), there is no guarantee that they would agree to make changes to the renderers.

It's unfortunate that DLNA is not as strictly specified as it should be. Absent a time machine to fix this, having a single global toggle to turn off the fade-in for all players in all player providers is what makes the most sense to me.

[github-actions[bot]]

This issue is stale because it has been open 14 days with no activity. Comment or this will be closed in 7 days.

[madbrain76]

Adding comment. It is not right to automatically close issues for inactivity. This is by far my most hated feature of github. And I'll state it again every time I have to comment to keep a bug active.

[OzGav]

@madbrain76 This should be fixed in 2.2.0 or later. Please confirm and then close this.

[madbrain76]

Yes, I can confirm that the fade-in effect is gone. Thank you for fixing it !

Unfortunately, with my WiiM, it takes quite a long time to resume. I timed it at 6 seconds. At least a few seconds worth of music are skipped when it finally starts playing again. I can see the time updating while there is silence before playback starts.

For comparison, I also checked with Chromecast on the same WiiM hardware, and the playback/resume was near instant, and nothing was skipped. With Airplay, the WiiM actually rewinds the music a tiny tiny bit when resuming. For clarification, both the Chromecast and Airplay behavior are perfectly fine.

I'm going to check the other DLNA renderers I listed to see how they behave with MA.

[OzGav]

Ok thanks. It could just be DLNA flakiness. As the original issue is resolved this will be closed. You can open a discussion or issue as appropriate for what else you find.