rpress;637018 Wrote: > Ah, so I've been looking into this. I added some code to http_recv so > that it would yield the thread if the audio->output_buffer is too low. > This worked very well and fixed it 90%, but it seems like there is still > something else that is tying things up occasionally.
I've been looking at the changes to the pa_callback, there's still a lock/unlock pair happening in the slimaudio_buffer_available function. I believe that the buffering also needs to be changed to use a ringbuffer implementation which doesn't require locks to access the buffer. As you're using the slimaudio_buffer_available in http_recv as well, that could be causing the last 10%. Another possibility is the decoder thread spinning too long for the slower CPU. Sorry it's all just suggestions and nothing concrete. -- ralphy Ralphy *4*-Classics, *2*-Booms, *12*-Squeezeslaves 'Squeezeslave' (http://code.google.com/p/squeezeslave/) 'donations' (https://www.paypal.com/cgi-bin/webscr?cmd=_donations&business=LL5P6365KQEXN&lc=CA&item_name=Squeezeslave¤cy_code=USD&bn=PP%2dDonationsBF%3abtn_donate_SM%2egif%3aNonHosted) always appreciated. ------------------------------------------------------------------------ ralphy's Profile: http://forums.slimdevices.com/member.php?userid=3484 View this thread: http://forums.slimdevices.com/showthread.php?t=83362 _______________________________________________ discuss mailing list [email protected] http://lists.slimdevices.com/mailman/listinfo/discuss
