... cpu to other threads.
The following problem exists on osx and ios (was not able to reproduce this on linux).
On all audio codecs in paplayer which get decoded via ffmpeg (dvdplayercodec) when pausing a track it might happen that it just unpauses itself and skips to the next track.
The following stuff is going on when this happens:
I know that pausing paplayer in the way i propose in this PR will stop filling the buffers during pause. But hey this is audio - every crappy wlan should get this through the air with out the need of a big cache.
I also know that the core issue might lay much deeper (maybe even in ffmpeg or a compile issue on osx/ios). But we need a fix for frodo - and i'm already done again with that paplayer stuff (i can't stand it more then 3 hours in a row ;) ).
ping to @elupus @gnif @davilla
[paplayer] - when player is paused - don't process streams but just y…
…ield cpu to other threads
Sleep() instead of CThread::Sleep(), this code is in PAPlayer::Process and the inherited Sleep has a check for bStop so it will abort if the the PAPlayer thread is stopped. 10ms is not much but hey, it all adds up :)
The same sleep is used 5 lines down for sleeping the watermark stuff. What is the issue when the sleep gets aborted when paplayer thread is stopped? This even would be nice imo?
And i could increase it to 100ms if we want :)
I guess who every added the other did not know about how the inherited Sleep works, or it was some cp monster running around :)
But what is the problem with sleep aborting when m_bStop is set? The thread is going to stop then anyway - so?
there is no problem, I'm confused :) Sleep() and CThread::Sleep() are the same thing inside a CThread
IIRC the CThread::Sleep was recommended by davilla in an IRC conversation a long time ago specifically for PAPlayer, but can't recall why.
Is the big negative number returned consistent?
If this fix helps iOS no concerns merging (although we obviously don't fill the queues as fast) but I haven't been able to reproduce here on Win.
/me swims over to the treasure chest and blows a bubble.
I can reproduce this as follows.
1. having a test folder on smb or nfs share which contains 3 flac or 3 m4a testfiles (or anything else which is decoded through dvdplayercodec)
2. Start xbmc
3. go into music->files->testfolder
4. start playback of the first testfile
5. enter fullscreen
6. pause the stream (enter for bringing up the osd, enter again for pausing the stream)
7. wait between 5 and 20 secs until the stream autostarts the next track
When i have done this with my testfiles for a while the problem occurs more seldom. But its always there after a fresh restart of XBMC.
Can anyone think of negative influences this could have (beside it the fact that it doesn't fill the cache during pause) which would block this from going in? (or should we learn it the hard way maybe? ^^)
Why does this happen only during pause? What is different in that case?
Maybe some buffer gets overrun in ffmpeg or so? (cause during pause it just keeps decoding)
If it's paused, wouldn't it just decode until the player buffer is full, and then just sleep at that point until things are resumed?
Well i guess it would do. This is a bug somewhere else i suppose. As of my reproduction it was harder to reproduce the longer i tried without restarting XBMC. This is just the quick fix for it for frodo (well as long as nobody else wants to dig into this at this speedy moment).
I really don't like fixes going in that no one understands, particularly when they alter fundamental bits of code such as the main loop of the audio player. I certainly wouldn't be confident that this won't break other stuff.
I suspect you've uncovered a real problem, but I can't see why it would happen only on pause. If we don't understand it, we can't know that it has actually fixed anything.
can you jump on irc?