playing jerky at beginning of the song

mpukki commented 12 years ago

Hi,

I'm experiencing some problems with playback. At the start of some songs playback is jerky for a few seconds and sometimes maybe in the middle of the song for maybe .2-.5 second periods. I'm using higher bit rate but it shouldn't be an issue, because 100/10M Internet connection. Any ideas how I could debug this problem? are there any kind of buffers used and are any kind of warning/error generated for the log for their depletion?

Problem could also be on my home network, because topology is somewhat complex. But I cant do any debugging with my network unless I can confirm some kind of problem from the log. So what to look from the log or how to modify the source to get some output?

btw, this problem seems to be most common when selecting an item from the play list, rather than letting the play list to go to next song by itself.

Regards, Mikko

akezeke commented 12 years ago

Hi,

I have noticed this too, but only on the 64 builds I have tried. It is probably a buffering problem but I cant find what is causing it.

It might be a problem in libspotify since I don't get any buffer underrun errors or anything like that either.

For now I recommend you to try a 32 bit build and see if the problem still exists (if you are on 64 bit now), I might take a closer look at this again later if I have some spare time.

tompen- commented 12 years ago

I noticed there is a relationship between jerky playback in the middle of a song, and short moments of "gui freeze". That is, if I constantly press the up and down arrow keys to scroll up and down in a playlist while playing a song in the background, sometimes there is a bit of delay before the gui responds. During such GUI delay, there is sometimes also jerky sound.

After a bit of experimenting (without really understanding the source code), a change that I feel have improved things is:

Sleep(5); to Sleep(0);

in BackGroundThreads.cpp, line 66. (do this without changing the value on line 65)

Sometimes the Sleep(5) is in reality much longer than 5ms due to other threads or locks. This change helps processEvents to not have as much "catching up" work to perform for each iteration in the while-loop. I think the shorter Sleep-time also helps processEvents to faster aquire the lock if another thread temporarily releases the lock.

I have noticed the GUI becomes more responsive (the duration of each GUI "freeze" is shorter). I thought this might give an increased cpu-usage, but from looking the cpu I can not find that it does. Im currently trying to evaluate if this helps also for the moments of jerky sound.

akezeke commented 12 years ago

Hi,

Interesting findings, but I guess sleep(0) does not sleep at all so I can remove it. I will try this and if its not increasing the cpu usage I will make this change later.

tompen- commented 12 years ago

I do not agree with Sleep(0) not sleeping. Normally a thread works the entire timeslice it has been given by the kernel, then the next thread works it´s timeslice and so on (basic multitasking). With Sleep(0) the thread ends it´s work even if the timeslice it was given by the kernel is not finished yet. So basically Sleep(0) means that the thread yields the remaning time in it´s timeslice so other threads can use this time instead. If you remove Sleep(0) the loop might run many times within the same thread timeslice before a thread context switch occurs. With Sleep(0), the while loop will only run one time before another thread gets activated.

akezeke commented 12 years ago

Ah, great! Thanks for clearing that out :)

Then I guess the sleep(0) stays!

tompen- commented 12 years ago

I noticed one reason for music interruptions is disk io bottleneck. Using the command: iostat 1

while listening to music, I see a relationship between high io wait time and short moments without music. At least that happens for me on an old usb-stick when the music goes silent for a second in the middle of a song.

akezeke commented 12 years ago

Ok, make sense, I have never tried it on a slow disk myself and never experienced any problems in the middle of songs. One way to solve it is to increase the buffer size, the tradeoff is then that it will take longer to start playing songs. Maybe I should allow the buffersize to be defined in the settings.

But this will not remove the jerky sound in the beginning of songs, I have tried with all variants of buffersizes and nothing seems to help here (except running a 32bit build).