Hi Luiz,
On Thu, 2011-08-04 at 04:20 -0400, Luiz Augusto von Dentz wrote:
> Hi Peter,
>
> On Thu, Aug 4, 2011 at 12:14 AM, Peter Hurley <peter@xxxxxxxxxxxxxxxxxx> wrote:
> > Hi Luiz,
> >
> > .....
> >
> > 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).
>
> Really, so you have a fix for that? I would be happy to see your
> proposal and discussion on PulseAudio mailing list.
I'd rather start over :)
> > 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!)
>
> But why the kernel is not stopping PulseAudio? I mean PA does use
> POLLOUT to check if the socket is writable, it then writes as much as
> possible and sleep, but without using guaranteed channels with proper
> QoS support I don't this changing anytime soon.
The kernel can't stop the socket because there's not enough information
to know when to restart it (and I doubt other controllers forward STOP
packets to the host like BCM).
This is my whole point about the stream indices and computed latency:
PulseAudio's design is predicated on *knowing* the relationship between
elapsed time and stream index, and thus being able to deliver data to
the sink just before it's needed (especially with pre-emptible kernel).
But for a remote device to be flow-controlling implies that PulseAudio
is way ahead of what's actually playing. Full remote recv buffers + full
host tx buffers * 853-byte packets of RTP data is pretty far ahead!
> > 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.
>
> This can be fixed, the source already uses the smoother anyway, but Im
> afraid this can cause bad effects like much frequent wakeups and even
> auto of sync with some headsets.
Exactly. The element (smoother) designed specifically to ensure the
correct latency calculation, doesn't.
[Aside: the problems caused by removing the sleep timer go deeper than
just flooding BT - it also exposes some source index problems. Just
haven't had time to investigate that further yet]
> > My point here is I think it's premature to conclude that PulseAudio
> > doesn't have a part to play.
>
> It probably does, but it doesn't change the fact the prioritization is
> pretty much needed, actually it will probably make such problems more
> visible than ever.
Agreed. As I wrote in the other post, I think priority-based tx
scheduling is an excellent idea.
Regards,
Peter
��.n��������+%������w��{.n�����{��� �^n�r������&��z�ޗ�zf���h���~����������_��+v���)ߣ�
