Re: [pulseaudio-discuss] State of various rate adjustment patches
Yo, 'Twas brillig, and Maarten Bosmans at 09/02/11 16:07 did gyre and gimble: 2011/1/31 Colin Guthrie gm...@colin.guthr.ie: 'Twas brillig, and Maarten Bosmans at 31/01/11 10:36 did gyre and gimble: 2011/1/16 Maarten Bosmans mkbosm...@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/] ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] State of various rate adjustment patches
2011/1/31 Colin Guthrie gm...@colin.guthr.ie: 'Twas brillig, and Maarten Bosmans at 31/01/11 10:36 did gyre and gimble: 2011/1/16 Maarten Bosmans mkbosm...@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 ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] State of various rate adjustment patches
On 2011-02-09 17:07, Maarten Bosmans wrote: 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. From what I can tell, the change seems to be copy-pasted from protocol-native.c, and so it's probably correct. My rewind patches shouldn't change that either for better or for worse. That said, of course testing wouldn't hurt :-) -- David Henningsson, Canonical Ltd. http://launchpad.net/~diwic ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] State of various rate adjustment patches
'Twas brillig, and Maarten Bosmans at 31/01/11 10:36 did gyre and gimble: 2011/1/16 Maarten Bosmans mkbosm...@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. I'll be away for a week now (skiing trip in Switserland, yay), so I'am able to answer any questions later. I'll be away in France next week doing much the same! Enjoy! 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/] ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] State of various rate adjustment patches
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. To test the loopback, what I had in mind was enabling a BT sink (receving data from somewhere else using A2DP) and playing locally on the speakers. That should trigger all kinds of latency issues since the transmitter essentially pushes packets without worrying too much about time, and the receiver has to do all the synchronization work. Should be fairly easy to enable by modifying the /etc/bluetooth/audio.conf, but I haven't had the time to test so far -Pierre ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] State of various rate adjustment patches
2011/1/17 pl bossart bossart.nos...@gmail.com: 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. To test the loopback, what I had in mind was enabling a BT sink (receving data from somewhere else using A2DP) and playing locally on the speakers. That should trigger all kinds of latency issues since the transmitter essentially pushes packets without worrying too much about time, and the receiver has to do all the synchronization work. Should be fairly easy to enable by modifying the /etc/bluetooth/audio.conf, but I haven't had the time to test so far -Pierre I don't have any BT equipment, so it would be great if you could test the changes. Have you experienced any wild rate variations with bluetooth in the past? If so, the current patch should at least get rid of annoying big variations. If you're interested in testing, I could also send a patch to the list where the algorithm I used for module-rtp-recv is applied module-loopback too, it would be interesting to see if it also has an improvement. Maarten ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] State of various rate adjustment patches
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. Maarten 2011/1/15 Maarten Bosmans mkbosm...@gmail.com: 2011/1/15 Colin Guthrie gm...@colin.guthr.ie: Hi, I know people (i.e. Maarten) are discussing and proposing various rate adjustment patches just now. Not quite got a grasp on whether any of them are ready for merging so if/when they are, please just poke me. Col The patches I sent to the list were mainly to illustrate the ideas I was discussing. I am trying to make a coherent set out of them. Things remaining are: - smoothing of the estimated (real) sample rate in module-rtp-recv. I'm tryng to find a balance between very good runtime behaviour and keeping the algorithm not too complicated. - module-loopback. I just need to setup a loopback and start some testing. I would have expected that module-tunnel also needs sample rate adjustments, but it appears it does not. Is that correct? module-echo-cancel also seems to do sample rate adjustments. But it seems that it is not completely implemented yet (there are commented lines), so unless the author of that module explains what de desired behaviour is, I'll just leave that. I'll try to make a patch set and send them to the list for (hopefully) final review. Maarten ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
