JackOfAll wrote: > Triode, > Can you please add the following patch to git. (I wouldn't have noticed > the snafu with getting linear filter every time if I hadn't been logging > the quality spec immediately before creating the resampler.) >
Applied. > > Don't know how you feel about this one. Drop the LOCK earlier and try > and avoid the sleep if we don't have enough space to write all frames in > one go. By dropping the LOCK after writing what we can, we give the > output thread a change to remove bytes from the out buf and maybe avoid > a sleep, before looping again. > Does this gain any benefit??? The output thread can only ever reduce the frames in the outputbuf and so if it runs it creates more space. So this loop only exectutes in two cases (assuming its working correctly!): 1) when we know there is enough space in the output buf during normal decoding, 2) during the drain phase at the end of decoding when we can get too much data. So in case 1) the while loop only every itterates more than once if we are wrapping the output buffer (happens once every 10 seconds..). I agree it could buy something during the drain phase - is this the case you are looking at? > > I'm still tinkering with this.... > <snip> > We want that to be the 2 * alsa buffer_size? (which we need to store as currently output.buffer is potentially also the buffer time in ms...) I'd like to play with this but it sounds reasonable and not sure why we don't do it for all sample rate all the time as its only twice what I have now? (4 * avail which will normally be the period size.) ------------------------------------------------------------------------ Triode's Profile: http://forums.slimdevices.com/member.php?userid=17 View this thread: http://forums.slimdevices.com/showthread.php?t=98544 _______________________________________________ unix mailing list [email protected] http://lists.slimdevices.com/mailman/listinfo/unix
