Hi, Le vendredi 21 juin 2024 à 18:01 +0530, Devarsh Thakkar a écrit : > Hi Nicolas, > > On 20/06/24 23:02, Nicolas Dufresne wrote: > > Le jeudi 20 juin 2024 à 19:50 +0530, Devarsh Thakkar a écrit : > [..] > > Imagine that userspace is going gapless playback, if you have a lets say > 30ms on > > forced suspend cycle due to close/open of the decoder instance, it won't > > actually endup gapless. The delay will ensure that we only suspend when needed. > > > > Shouldn't the applications doing gapless playback avoid frequent open/close of > the decoder instance too as it will add up re-instantiation (initializing hw, > allocating buffers) and cleanup (de-initialization and freeing up of buffers) > delay for each open/close respectively ? Even in case of scenario where > resolution of next stream is different than previous, I guess the application > can still hold up the file handle and do the necessary setup (stream > off/stream on/REQBUFS etc) required for re-initialization ? I don't have a very strong opinion here, I usually try to avoid optimizing for what userspace should do. Best would be to build your opinion on your own testing of existing userspace (perhaps not just GStreamer). I think if you have good reason to force suspend when the last instance is destroyed, please do so (e.g. stability issue, race conditions etc). So far, I don't personally know what is the issue with leaving a small delay in order to avoid a suspend / resume cycle if one quickly close the last instance and open the next one immediately. A comment would be nice, so no one fall in such a trap later. Nicolas
