I have released a new version of Softsqueeze 2.3. This will be in the 6.2 nightlies or you can download it from Sourceforge (http://softsqueeze.sourceforge.net). Later in the week I'll release a new version on the trunk.
This fixes (for me anyway!) sync. I've been listening with out problem for nearly a couple of hours now. Gapless flac playback should also working again, but I have not tested this (please let me know). Several times people have asked how the buffering / sync works, so if you interested in what the problems were please read on. Three audio buffers are used in Softsqueeze; the decoder buffer holds encoded audio (mp3, flac, etc), the output buffer holds pcm samples, finally the small javasound buffer holds the samples written by Softsqueeze to the audio device. When two or more players are sync'd then the slimserver starts streaming the encoded audio but leaves all the players paused. The players send status information back to the slimserver reporting how fully the audio buffers are, when all players have enough data in the decoder buffer then the unpause command is send to all payers. The first problem was a recently introduced typo that caused a block of silence to be written into the output buffer when a new track started to be decoded in Softsqueeze. This also broke gapless flac playback. Doh! The Squeezebox decodes audio a few bytes at a time so it does not take long for the decoded pcm samples to play out of your speakers following the unpause command. In Java the most efficient to stream audio is to decode blocks of audio data, Softsqueeze uses a block size of 128000 bytes. It takes too long to decode a full audio block and start playback compared to the process in a hardware player. So Softsqueeze cheats, it starts decoding while the player is paused to reduce the latency when playback starts. The second problem was that sometimes the decoder buffer had reached the playback threshold and the unpause command sent but the first block of audio had not yet been decoded. This made Softsqueeze play behind the Squeezebox. To fix this Softsqueeze now sends zero buffer fullness until some samples have been decoded to the output buffer, causing all players to wait until Softsqueeze is ready to start playback. The opposite problem also exists, if the hardware player is slow to buffer (say working wirelessly) then Softsqueeze might have decoded lots of pcm samples. I then found that the first write to the javasound buffer could take too long, again causing lack of sync. Now to help smoothly start playback both the decoder and output buffers are filled using an exponentially increasing block size, starting with 4096 bytes until the maximum block size is reached. This helps control the playback latency, but this approach does increase the risk of an audio buffer underrun at the start of a track. Only with wider testing can we be sure the balance here is correct. I hope this now works for everyone!! Richard -- rtitmuss ------------------------------------------------------------------------ rtitmuss's Profile: http://forums.slimdevices.com/member.php?userid=36 View this thread: http://forums.slimdevices.com/showthread.php?t=19823 _______________________________________________ Discuss mailing list Discuss@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/discuss
