Bug 16256 - "Fade out" and "Fade in and out" cause audio glitch when fade-out starts
: "Fade out" and "Fade in and out" cause audio glitch when fade-out starts
Status: RESOLVED FIXED
Product: SqueezePlay
Classification: Unclassified
Component: Audio
: 7.5.x
: PC Other
: P1 major with 1 vote (vote)
: 7.5.x
Assigned To: Andy Grundman
http://forums.slimdevices.com/showthr...
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2010-05-24 11:20 UTC by Andy Grundman
Modified: 2010-08-24 05:28 UTC (History)
7 users (show)

See Also:
Category: Bug


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Andy Grundman 2010-05-24 11:20:24 UTC

    
Comment 1 Richard George 2010-05-25 10:24:13 UTC
This audio glitch occurs regardless if crossfade is set to "fade in", "fade out", "fade in & out" or "crossfade". Also doesn't seem to change if smart crossfade is enabled or not.
Comment 2 Stefan Bellon 2010-05-25 12:10:32 UTC
I cannot confirm squeeze's statement. For me, it is really just "fade out" and "fade in and out" which cause the short gap 10 seconds before the end of the song. "crossfade" and "fade in" are definitely ok and play to the end without that gap.
Comment 3 Andy Grundman 2010-05-25 14:06:00 UTC
The problem appears to be that decode_fade_out takes too long rewriting all the samples in the output buffer with the faded values, and this causes the audio output callback to stall and underrun.  We probably need to find another way to implement fade-out, even a heavily optimized decode_fade_out could still cause this issue.

I think the reason this works in ip3k is that it doesn't use the same audio locking that SP uses.
Comment 4 Stefan Bellon 2010-05-25 14:41:08 UTC
Do I understand it correctly that at one point the whole fade-out sequence is calculated and written to memory? Then the gap should become longer if I increase the fade-out time to 20 seconds and should halve if I decrease it to 5 seconds, is that correct?

If I understood that correctly, what about repeatedly calculating only that fraction of time ahead that is manageable without underrunning the buffer? Not that I understand the internal design and can comment in it seriously.
Comment 5 Andy Grundman 2010-05-25 14:52:37 UTC
The max time supported for fading is 10 seconds.  If you reduce it to 5, for example, it may be slightly better but won't go away completely.
Comment 6 Chris Owens 2010-05-26 13:56:33 UTC
Andy, for 7.5.1 we should disable the fade-out on the server side as you suggested.  We can implement the firmware fix for the next release.
Comment 7 SVN Bot 2010-05-26 17:47:51 UTC
 == Auto-comment from SVN commit #8826 to the jive repo by agrundman ==
 == http://svn.slimdevices.com/jive?view=revision&revision=8826 ==

Bug 16256, disable fade-out for now
Comment 8 SVN Bot 2010-05-26 19:21:54 UTC
 == Auto-comment from SVN commit #8829 to the jive repo by agrundman ==
 == http://svn.slimdevices.com/jive?view=revision&revision=8829 ==

Bug 16256, first half of moving fade-out code from decode_output to the audio modules, this contains only portaudio support
Comment 9 SVN Bot 2010-05-27 07:11:37 UTC
 == Auto-comment from SVN commit #8831 to the jive repo by agrundman ==
 == http://svn.slimdevices.com/jive?view=revision&revision=8831 ==

Bug 16256, ALSA fade-out implementation
Comment 10 Alan Young 2010-08-24 04:08:40 UTC
Andy, is this fixed now?
Comment 11 Andy Grundman 2010-08-24 05:28:30 UTC
Yep.