On 26.11.2015 08:41, Georg Chini wrote: > On 26.11.2015 01:49, Tanu Kaskinen wrote: >> On Wed, 2015-11-25 at 22:58 +0100, Georg Chini wrote: >>> On 25.11.2015 19:49, Tanu Kaskinen wrote: >>>> On Wed, 2015-11-25 at 16:05 +0100, Georg Chini wrote: >>>>> On 25.11.2015 09:00, Georg Chini wrote: I am not really sure where >>>>> this discussion > is leading to. We are also mixing up different topics at the moment. > The first one is a matter of the safeguards. As already said in a > previous mail, in my opinion those safeguards only have to cover > the most common cases and do not need to be perfect because > the controller will take care at runtime. Let's pick up the safeguard discussion again. Maybe there is a reasoning, based on your calculations in the previous mails. As far as I can tell, we are talking about 3 different cases: 1) Interrupt driven alsa device I would propose to accept that for this kind of device the buffer_latency needs to be one default-fragment-size + some safety margin. This is a value proven in practice and when I remember correctly you reason in another mail that it could indeed fit in that special case. 2) timer based alsa device I arrived at the conclusion that buffer_latency has to be 0.75 * sink_latency. Would it be reasonable to argue that we have to keep one configured sink latency of audio around on the source side? If yes, it would make clear where that 0.75 factor is coming from. The correct value for buffer_latency would then be buffer_latency = configured_sink_latency - 0.25 * configured_source_latency which gives 0.75 * configured_sink_latency if both are equal. 3) the general case, so none of the above This is still unclear. As far as I understand, in this case there will never be timer based scheduling. Am I correct? If yes, it can be distinguished from case 1) just by checking the name of the device. In this general case we probably have to choose very conservative settings as we don't know exactly how the device will behave. If source and sink are of different device type we have to take the larger value.
