On 03.04.2017 00:11, Tanu Kaskinen wrote: > On Wed, 2017-03-29 at 10:36 +0200, Georg Chini wrote: >> With the current code, the user can request any end-to-end latency. Because there >> is no protection against underruns, setting the latency too small will result in >> repetitive underruns. >> >> This patch tries to mitigate the problem by calculating the minimum possible latency >> for the current combination of source and sink. The actual calculation has been put >> in a separate function so it can easily be changed. To keep the values up to date, >> changes in the latency ranges have to be tracked. >> >> The calculated minimum latency is used to limit the configured latency. >> The minimum latency is only a "best guess", so the actual minimum may be much >> larger (for example for USB devices) or much smaller than the calculated value. >> >> Port latency offsets are not yet handled properly, this will be done in a separate >> patch. > In what way are they not handled properly? Does it make sense to have > any code related to latency offsets in this patch if it needs to be > fixed later? Port latency offset changes are not yet handled. I'll make this clearer in the next commit message. You cannot calculate a minimum latency without taking the offsets into account, so it makes sense to have the code in this patch. >> @@ -751,6 +860,12 @@ static int sink_input_process_msg_cb(pa_msgobject *obj, int code, void *data, in >> u->output_thread_info.effective_source_latency = (pa_usec_t)offset; >> >> return 0; >> + >> + case SINK_INPUT_MESSAGE_UPDATE_MIN_LATENCY: >> + >> + u->output_thread_info.minimum_latency = (pa_usec_t)offset; > If the minimum latency grows, and the target latency grows too because > of that, I think we should push some silence to the memblockq to > account for the change in the target latency. Otherwise I think there's > a risk of getting many underruns before the latency controller adjusts > to the new target. This is not necessary. if the minimum sink latency is increased because of underruns, the latency after the underrun is normally much larger than the new target latency so that there is no need to add any silence. At least I have not seen a case yet where what you describe happens and i did a lot of testing.
