bluegaspode;695858 Wrote: > I'm trying to stream Spotify via SqueezePlayer and face some strange > problems. Maybe you can help me finding out the cause? > > When I start a stream via Spotify it plays too fast in the beginning. > For me it sounds like a lot of frames are dropped. > This settles down after some waiting time when the song starts to play > correctly without dropping frames. > > The spotifyd log has a lot of the following messages > -------- > [00:16:10.156459] music_delivery:416 called with num_frames: 2048 > [00:16:10.157241] _streambuf_write:263 player: 0 wrote 2106 new bytes > of 2106 min 2106 > [00:16:10.157883] _streambuf_write:263 player: 0 wrote 2206 new bytes > of 2206 min 2206 > [00:16:10.157973] music_delivery:566 streamed frames: 643072 can't > write: 16 rate: 88773 / 44100 > -------- > > I searched that on the forum and found several threads where you are > asking if FLAC tracks are streaming fine (yes they are) or if the > Spotify Self Test works (for some reason it says 'Streaming from > Spotify Failed' - though through starting on Squeezeboxes/SqueezePlayer > gives me a stream). > I finally found a thread where you ask to disable Spotify->FLAC > streaming (i.e. forcing PCM streaming ... > http://forums.slimdevices.com/showthread.php?t=90895). > > This resolves the problem for me (yeah!!), so I think we can conclude: > - Spotify download is fast enough > - my network is fast enough > - FLAC conversion on the server has trouble (probably my server is too > slow - it's a SheevaPlug) > > I wouldn't expect dropped frames though, but rather many rebufferings > in SqueezePlayer. > Any ideas? > > Thanks a lot for your help!
Suspect the problem here is lack of cpu - so turning off flac streaming fixes it. The spotify library decodes the audio to raw pcm. The plugin wrapper then uses libflac to reencode it to minimse network traffic. It then sends it over the tcp session to the client. The can't write message above just means the tcp socket send buffer is full and so it can't write to the socket. In this case it does not drop the samples, but waits again for the spotify library callback to try writing audio again. The assumption is that tcp has enough buffering in the output socket to sustain the stream [there is no extra fifo in my code]. This works ok on systems I have tested, but perhaps may cause dropouts on lower speed cpus systems. The rate 88773 / 44100 says that the accumulated rate for the track is 88773 samples per sec - as long as this is above the 44100 number you should not hear a drop out. It is is below then I would suggest either the local network or feed to spotify is too slow. In the case of sync, each set of samples must be written to all client's tcp sockets before it moves on, so it is possible that one tcp session which is congested will slow the others down. What devices was this with pippin? -- Triode ------------------------------------------------------------------------ Triode's Profile: http://forums.slimdevices.com/member.php?userid=17 View this thread: http://forums.slimdevices.com/showthread.php?t=79706 _______________________________________________ plugins mailing list [email protected] http://lists.slimdevices.com/mailman/listinfo/plugins
