[pulseaudio-discuss] State of various rate adjustment patches

[Colin Guthrie]

Yo,

'Twas brillig, and Maarten Bosmans at 09/02/11 16:07 did gyre and gimble:
> 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.


As we discussed last night, we'll do another 0.9.x release and as such
if you want to prep a stable queue branch I can merge with the necessary
patches in it, then that would be awesome.

If the sha1's cherry-pick cleanly then we can just do this on IRC
interactively and I'll push it out like that for more testing. If you
want to discuss more, just ping me.

Cheers

Col

-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
  Mageia Contributor [http://www.mageia.org/]
  PulseAudio Hacker [http://www.pulseaudio.org/]
  Trac Hacker [http://trac.edgewall.org/]