<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#c5">Comment # 5</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#c4">comment #4</a>) > module-loopback doesn't ignore the option, there's a different explanation > for the observations. If changing the default fragment size has some effect, > then it means that the sink (and probably source too if they're the same > card) are not using timer-based scheduling, and hence don't support dynamic > latency. Without dynamic latency, module-loopback can't control the overall > latency. Or more specifically, it can't make the latency smaller than what > the sink and source allow; it can be considered a bug that latency_msec=2000 > doesn't make the latency higher, because that should be possible to do. Thank you for the insight. It does seem like module-loopback isn't conrolling the overall latency, as you say, since its latency seems tied to the latency of my sink (and source, since they are indeed on the same card). That being said, I'm able to get less latency using pacat (record at 1ms, playback at 1ms. I don't know if the actual latency is as low as that request, but it's quite a bit faster than module-loopback, anyway). I'm not an engineer, but it seems like module-loopback would be doing something similar to what I'm doing with pacat (recording from an input and playing that back to an output in real time, unless it uses some kind of lower-level, less-intensive means), and, although it would arguably be difficult on many systems to have that running in the background at all times, I don't see why it wouldn't be possible by user request if it's possible for pacat. If it should be possible to add ~more~ latency, anyway, then I'm not going to change the title of this bug, since changing the value of latency_msec has no effect one way or the other. Also, as far as I've read, the manual doesn't give any warning about soundcards that don't support dynamic latency; I think that I rightfully expected that changing the option value would do something, but it's ineffectual and no message is produced, so it's effectively being ignored. Also, I can set arbitrarily high latencies using pacat, and they're accurately reproduced. For the record, and in case this helps anyone else, here's the pacat command that I'm using: pacat -r --latency-msec=1 -d alsa_input.pci-0000_08_04.0.analog-stereo | pacat -p --latency-msec=1 -d alsa_output.pci-0000_08_04.0.analog-stereo where "alsa_input.pci-0000_08_04.0.analog-stereo" and "alsa_output.pci-0000_08_04.0.analog-stereo" are my input and output devices, respectfully; anyone else's will be different. Does anyone know of a command or option that I can use to make module-loopback produce valuable messages? It'd be interesting to see what it has to say for itself when it's ignoring or failing to implement my latency requests.</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>