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 _______________________________________________ pulseaudio-discuss mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
