Why does a VOIP sink input's current latency become "0" after moving to a new sink? I saw endless "rewind" in log

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Thank you, Col and Xingchao!

> I guess there is something going on here (as you say) with the GTalk
> data flow, but I'm not sure quite what... It could of course just be
> GTalk itself not dealing gracefully with the latency changes (e.g.
> assuming fixed latency?)
>

Is it possible GTalk cannot handle a latency much larger than it requested (128ms)? I think the real latency is much larger than the requesed 128ms and just same as what the other input shows (1982ms).  

>>I think the BT HSP sink is working well, because if I connect another 8KHZ mono music stream to this sink at the same time, I can hear the music. And that music input?s latency is non-zero:
>>?current latency: 1982.00 ms, requested latency: 128.00 ms?.

The sink input's queue length is decided by the latency, right? If the real latency is much bigger than the requested one, will the application know it and request PA to flush input data?

Thanks
Amanda


[Index of Archives]     [Linux Audio Users]     [AMD Graphics]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux