> As far as I understand it, this information is already supplied to the > application via the timing information and underrun callbacks. > > When an underrun is hit, it would make sense that the applications > checks the latency information and adjusts it's flow rate accordingly. > Thank you, Col! I'll check the application code to see if there is something I can do. But, I still have question on pulseaudio: 1. why buffer underruns are more likely to happen for a Bluetooth HSP sink, especially after moving sinks? If I connected the BT headset at first, and then launch the VOIP application, the sink input latency is about hold 20 ~ 30ms although there are still underruns from time to time. But if I launch VOIP and then move to BT sink, the sink input latency is 0, frequent underruns and rewind flood happens. Why moving cause such a difference? 2. But if I use ALSA, sink input's latency is usually 50m ~ 80ms. Why it works better than a BT sink? Thanks Amanda
