Bug 1536 - Audio Startup Time delay is sent before every playlist item
: Audio Startup Time delay is sent before every playlist item
Status: RESOLVED FIXED
Product: Logitech Media Server
Classification: Unclassified
Component: Playlists
: 6.0.2
: Other Linux (other)
: P2 normal with 2 votes (vote)
: Future
Assigned To: Andy Grundman
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2005-05-14 15:49 UTC by Andy Grundman
Modified: 2015-02-06 08:34 UTC (History)
0 users

See Also:
Category: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Andy Grundman 2005-05-14 15:49:00 UTC
Using a cue sheet to listen to a file, when it goes to the next virtual "track",
there is an approx. 1 sec gap in the audio.  The crossfading settings don't
appear to affect this.  I've tried both Crossfade=0, Crossfade=1, and None with
no change.

I'm using an mp3 file, and the cue is in a separate file in the same directory.
Comment 1 Andy Grundman 2005-05-14 17:01:59 UTC
I've tried on another file (a VBR mp3), and the gap is a lot smaller, just a
split-second blip.  But the audio should be completely seamless.

The first file I tested was a CBR mp3.
Comment 2 Andy Grundman 2005-05-15 11:43:43 UTC
I did some debugging and found this is caused by mp3SilencePrelude.  I had this
set to 1 because my receiver has a startup delay.  The silence should only be
added when starting from a stopped or paused state though, and not sent during a
playlist change.
Comment 3 Andy Grundman 2005-05-15 11:54:40 UTC
I'm changing the summary of this bug as this also affects normal playlists, not
just cue sheets.  The mp3SilencePrelede is sent before each new track, but only
for mp3 files.  I'm not sure why this is, as any receiver that needs this delay
would need it for all file types.
Comment 4 KDF 2005-05-15 14:08:23 UTC
I seem to recall that part of the original discussion before this feature came
about was the loss of lock at the beginning of every mp3 file, where PCM was
fine.   I'm not up on the specifics becuase they do not apply to me (my
equipment isn't so high spec as to have such a fine band).

reassigning to vidur, since I'm sure he was more involved in this than Dan.
Comment 5 Blackketter Dean 2007-10-22 16:39:55 UTC
andy, is this still an issue?
Comment 6 Andrea 2007-12-28 03:09:32 UTC
Yes, it's still an issue. Adding my vote. It led me to believe MP3 gapless wasn't working when in reality it sufficed to drop this value to 0 to get gapless playback.
Comment 7 Michael Herger 2015-02-06 08:34:09 UTC
This was fixed in 7.6.