On Thu, 2011-03-24 at 09:09 -0500, pl bossart wrote: > > The sink may be running in a low-latency mode even if the loopback > > stream doesn't have any latency requirements - there may be other > > streams active at the same time with stricter timing requirements. > > > > FWIW, the practical case here was a very simple test of looping null > > sink's monitor to a hw sink with default settings on Harmattan. It may > > be that our setup is more suspectible to this kind of problems than > > "normal" systems, but I still think that non-realtime-safe stuff should > > be kept out of the IO threads, regardless of the setup, especially if > > such stuff can very well be done outside the IO thread. > > if you are still using 10ms periods on the hw sinks, then yes it's an > artifical use case in a constrained environment that doesn't use > timer-based scheduling... > I don't disagree that doing SRC in an io thread is not that kosher, > but keep in mind that we also do mixing and volume control in the IO > thread. There is some amount of DSP in this thread which will impact > response time to hw events. It might be that you have misunderstood the reason for the patch. Now that I read the patch description again, it indeed isn't entirely clear: the problem that I'm having is that the periodic (every 10 seconds) reinitialization of the resampler takes too much CPU time. The resampling itself is fine - I don't think it's even possible to move that out of the IO thread, or if it's possible, it probably wouldn't bring any benefits. -- Tanu
