<br><br><div class="gmail_quote">On 24 January 2011 09:21, Kurt Taylor <span dir="ltr"><<a href="mailto:kurt.taylor@linaro.org">kurt.taylor@linaro.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> <div><div></div><div class="h5"><br><div class="gmail_quote">On 20 January 2011 16:45, pl bossart <span dir="ltr"><<a href="mailto:bossart.nospam@gmail.com" target="_blank">bossart.nospam@gmail.com</a>></span> wrote:<br> <blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> <div>> Along with increasing the buffer size, the tsched wakeup watermark will need<br> > to be increased, although my initial prototype code did not do that. I<br> > waited until the watermark increased to the point where there were no more<br> > underruns before using powertop. On my PC, it seems like the process for<br> > decreasing the watermark is very aggressive, maybe to the point of causing<br> > more underruns than needed.<br> ><br> > I plan on doing more testing, but on an ARM based platform, obviously, I am<br> > looking for a buffer growth tuning for ARM that will reduce CPU wakes. For<br> > dynamic growth, I am thinking that with the check_left_to_play (alsa-sink.c)<br> > when woken by a timeout, it would be a good time to try to increase buffer<br> > size and hopefully allowing ARM to go to a lower power state on long plays.<br> > The buffer would be set back to normal default when rewinding, etc.<br> <br> </div>You can't really change the size of the buffer, it's defined when you<br> define the hw_params. You can only change the timer value. It think<br> the 'buffer growth' you want is already handled by the concept of<br> latency.<br> We've also experimented with larger buffers. It's not clear to me that<br> you really benefit from 8+ sec buffers. You have other wake-ups in the<br> system that will reduce the benefits of long sleeps. Also as you said<br> the timer watermark needs to take the tlength into account, a fixed<br> initial value isn't very good.<br> And last there is still a wake every 1.5s due to the auto-timing<br> update. It would need to be changed to depend on the latency value.<br> It's been on my TODO list but I still don't understand how the<br> smoother parameters need to be changed.<br> -Pierre<br></blockquote><div><br> </div></div></div></div>Thanks for your reply Pierre.<br> <br> I am still learning and so I spent some time this weekend experimenting. I tried again to show larger buffer size would help, but there was really very little difference, just as you suggested. I then tried to change the buffer size during a playback, when we woke on_timeout in alsa_sink.c and snd_pcm_hw_params failed. In fact, due to the failure, the module was actually unloaded. <br><br>I will do more experimentation on watermark reduction and auto-timing update with relationship to latency and learn that code better. I was wondering if you could elaborate on what you had on your TODO list for this area with regards to smoother parameters.<br><br>I am following the dynamic sample rate discussion as that also may help CPU on ARM. Any other comments and suggestions of areas to look at would also be appreciated.<br> <font color="#888888"> <br>Kurt Taylor (irc krtaylor)<br> <br> </font></blockquote></div><br>Any other thoughts on buffer size growth? Is there a way to increase it during playback that I may have missed? <br><br>Kurt Taylor (irc krtaylor)<br>