<html> <head> <base href="https://bugs.freedesktop.org/" /> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW --- - module-loopback ignores latency_msec option" href="https://bugs.freedesktop.org/show_bug.cgi?id=80770#c2">Comment # 2</a> on <a class="bz_bug_link bz_status_NEW " title="NEW --- - module-loopback ignores latency_msec option" href="https://bugs.freedesktop.org/show_bug.cgi?id=80770">bug 80770</a> from <a class="email" href="mailto:ifyoudieinthegameyoudieforreal@gmail.com" title="ifyoudieinthegameyoudieforreal@gmail.com">ifyoudieinthegameyoudieforreal@gmail.com</a> <pre>(In reply to <a href="show_bug.cgi?id=80770#c1">comment #1</a>) > any reason not using line playback volume of your onboard sound card or > analog input monitor of your oxygen mixer instead of the software loopback > which have high latency at least one capture period and one plpayback > period ? Yes, there's a reason that I'm using PulseAudio's loopback module instead of the ALSA monitor, directly. That doesn't have anything to do with this bug, though. Since I last commented, I was able to reduce the 'Sink Latency' (and the module-loopback 'buffer latency') dramatically by correcting my PulseAudio default fragment size from the default 25 down to a more suitable 3. Although the 'Buffer Latency' value is no longer ~200ms, which defeats my theory that module-loopback always uses the recorded default value of 200ms, the latencies are still exactly the same regardless of whether I supply latency_msec=1 or latency_msec=2000. I'm not sure of exactly how module-loopback settles on its latency, but it still appears that the latency_msec option is ignored, as far as I can tell.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the QA Contact for the bug.</li> <li>You are the assignee for the bug.</li> </ul> </body> </html>