On 10/22/2014 01:45 PM, Devin Heitmueller wrote:
this seems like a feature, not a bug. PulseAudio starts streaming before clients push any data and likewise keeps sources active even after for some time after clients stop recording. Closing VLC in your example doesn't immediately close the ALSA device. look for module-suspend-on-idle in your default.pa config file.
The ALSA userland emulation in PulseAudio is supposed to faithfully emulate the behavior of the ALSA kernel ABI... except when it doesn't, then it's not a bug but rather a feature. :-)
I also agree that the open/close of the alsa device is the only way to control exclusion.
I was also a proponent that we should have fairly coarse locking done at open/close for the various device nodes (ALSA/V4L/DVB). The challenge here is that we have a large installed based of existing applications that rely on kernel behavior that isn't formally specified in any specification. Hence we're forced to try to come up with a solution that minimizes the risk of ABI breakage.
If we were doing this from scratch then we could lay down some hard/fast rules about things apps aren't supposed to do and how apps are supposed to respond to those exception cases. Unfortunately we don't have that luxury here.
Sounds like we don't have a clear direction on open/close or capture start/stop. What I am hearing is open/close isn't acceptable for media maintainers and capture trigger start/stop isn't acceptable to sound maintainers. :) Fork in the road, which way do we go?
Implementation wise, supporting capture trigger start/stop approach will be harder to maintain in longterm. It adds more variables to the mix. Applications open sounds device from the main thread and then create a new thread to handle streams. I can see that based on the token hold requests that come in. So the token hold logic will have to take that into account, leading into potential unbalanced lock/unlock scenarios. It is not impossible to solve, that's what I did in this patch series, but it does get complex.
What I am looking for is some consensus on let's go with an approach and try. Doesn't matter which way we go, and how much testing I do, I am bound to miss something and this work needs to soak for a bit in the media experimental branch.
thanks, -- Shuah