Hi Luiz,
On Wed, 2011-08-03 at 09:11 -0400, Luiz Augusto von Dentz wrote:
....
> The main use case for this is A2DP, many people complained that when they
> are using their HID devices (mouses) together with headset the mouse has
> higher priority, which btw is not true since currently there is no
> priority and connections receives the same quote.
>
> With this changes it may reduce the problem since PulseAudio already sets
> A2DP socket as low latency (priority 6), which means audio packets will be
> processed before the HID packets, but this only affects tx and there still
> exist the problem of some HID not letting us being master.
What packets are being transmitted _to_ the HID devices during audio
streaming? In all my captures of A2DP crackle/skips, there's not a
single HID packet being transmitted out. Of course, I was carefully not
to press any of the led-transition keys during the capture :).
It's my belief that the incredibly complicated way that PulseAudio
handles the stream indices and computed latency is really the issue (at
least with A2DP).
For example, in several configuration I have, PulseAudio is rendering
*too fast*. This is evidenced by the remote device sending STOP packets
(which can flood the syslog as 0-length L2CAP packets) because its recv
buffers are full! (Of course, these DM1 packets are eating up air time
too -- which is slowing legitimate rx packets from the HID devices!)
You should hear the 'skipping' when the sleep timer which delays the
next block render is IFDEF'd out of the
module-bluetooth-device.c/threadfn(). With other subsystems but not with
Bluez, PulseAudio uses a 'smoother' to fine-tune when to render the next
block.
My point here is I think it's premature to conclude that PulseAudio
doesn't have a part to play.
> Ive been testing this using A2DP and HID connected simultaneusly without a
> problem, though connecting/paging still makes audio skips, and also tried
> OBEX transfers together to see if audio skips, indeed it does when HID is
> active but it works better than having no priority (skips less frequent)
> and in case of using priority 7 the audio doesn't skip anymore but it
> eventually stall the OBEX transfer (this is maybe because OpenOBEX loop
> while trying to write to socket and don't wait for POLLOUT).
Interesting...
Regards,
Peter Hurley
��.n��������+%������w��{.n�����{��� �^n�r������&��z�ޗ�zf���h���~����������_��+v���)ߣ�
