[pulseaudio-discuss] State of various rate adjustment patches

[Maarten Bosmans]

2011/1/31 Colin Guthrie <gmane at colin.guthr.ie>:
> 'Twas brillig, and Maarten Bosmans at 31/01/11 10:36 did gyre and gimble:
>> 2011/1/16 Maarten Bosmans <mkbosmans at gmail.com>:
>>> The branch is up at
>>> https://github.com/mkbosmans/pulseaudio/compare/master...rate-adjustment
>>> ready for merging, as far a I am concerned.
>>>
>>> I'm still not entirely sure whether the change of
>>> https://github.com/mkbosmans/pulseaudio/commit/72b90ea8ac53e23862284991a2ce355de250f585
>>> is correct, but it seems to avoid unnecessary rewinds for me.
>>>
>>> I've tested module-loopback by playing to a null-sink and looping its
>>> monitor to the real alsa sink. This showed good behaviour, but may be
>>> the algorithm I used for module-rtp-recv should also be used here.
>>> Does anyone has a better suggestion for a setup to test
>>> module-loopback? null-sink and alsa have very stable latencies, so its
>>> no good test for module-loopback.
>>
>> There where no objections on the list, so I guess the branch at
>> https://github.com/mkbosmans/pulseaudio/compare/master...rate-adjustment
>> can be merged with master.
>
> Cool, thanks Maaren. I'll pull in David's changes and then yours.

On the issue of stable-queue:

The first commit is definitaly a bugfix which should be included to stable-queue
http://git.0pointer.de/?p=pulseaudio.git;a=commit;h=11dbe30bfae09235307115f413fb6172df04a895

The second commit [8b4cb54595baeeb1d9b7d11a842ef7946e43a55a Limit rate
adjustments to small, inaudible jumps] has some fairly straightforward
logic which solves some bugs. I think this can go into stable, as
there is not much that can go wrong.

As I have only tested the patches on two different network setups
(both wired, one busy and one without other traffic), I can't really
vouch for the next commits. I don't really expect any troubles, but
some testing by others would probably be warranted. Anyway, if you do
decide to include them into stable-queue, I'd lump the next three
commits together, ending with
27db0603d6af7d25558af38ed525fc50330a9c32.

As I said before, the last commit
[72b90ea8ac53e23862284991a2ce355de250f585] is really beyond my
understanding of rewinds and would definately not be appropriate for
stable-queue without further review. Also, it has not been tested in
combination with David's rewind patches, so that needs to be done too.

Maarten