playing jerky at beginning of the song

[mpukki]

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]

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-]

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]

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-]

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]

Ah, great! Thanks for clearing that out :)

Then I guess the sleep(0) stays!

[tompen-]

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]

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).

[johnkristian]

I'm running xbmc/spotyxbmc2 on a Intel 520 SSD (FAST) and I also have this issue. I really love your work and hope you get this fixed :)

[akezeke]

Yeah well, if there is a problem with the disk operations there is not much I can do about it, I don't read or write anything concerning the music streaming.

If there are breaks in the middle of songs I would say it has something to do with the internet connection, spotify servers or something else. What I do in spotyXBMC is that I only receive the decoded stream from libspotify, holds it in a small buffer and pushes it to XBMC.

I have also experienced a lot of jerkyness in the beginning of songs but since I switched to a 32bit OS and turned of music volume normalization (in XBMC not in spotyXBMC) the problems are all gone.

[johnkristian]

I highly doubt it's a diskIO problem. I can't switch to 32bit OS (windows 7), but i'll try turning off volume normalization.

[johnkristian]

...and that made no difference

[johnkristian]

just to be clearr. The jerkyness/stuttering is just in the start off the song (when you change song or just right after.

[johnkristian]

Hey.
I just realized.... this might just be an issues with xbmc, not spotyxbmc2. When I load localy stored music files, I also get a pop/click when i change song. But not the little jerkyness the first second of the song. The pop/click might be the soundcard going in/out of "0-bit mode", but i'm not sure. But this is two different issues, but the pop/click issue appears both in xbmc playing local flac/mp3 and spotify playlists.

However, I do not get this pop/click when using standalone spotify or any other player.

[johnkristian]

nope. It's not just an issue with XBMC. It's a bug in spotyxbmc2 "addon"

[dowijnands]

I love this plugin! The stuttering in the beginning I can miss. Is there a possibility that the bug has something to do with playing audio over digital instead of HDMI?

Anyone got a workaround for this problem or anyone else still encountering this problem?

[johnkristian]

Actually .... I discovered more or less the same issue on my phone (android) when 320Kbps support surfaced. Anyone else that can confirm this?

[tompen-]

For master branch this might be related (have not done any experiments, only noticed this commit): xbmc@0151446