On Thu, 2011-03-24 at 15:31 +0200, pl bossart wrote: > On Thu, Mar 24, 2011 at 8:16 AM, Tanu Kaskinen <tanu.kaskinen at digia.com> wrote: > > Adjusting the sample rate is done in the IO thread, which can cause > > interruptions in the audio if the adjustment requires heavy computation. The > > trivial resampler is guaranteed to be light on the cpu. > > > > It would be better to adjust the sample rate in some other thread (FWIW, > > module-combine uses the main thread), but this quick hack fixes the immediate > > problem of spending too much time in the IO thread. > > I don't think it's the right or only way to solve the problem. If you > are using the loopback and SRC is required, the assumption is that you > don't care too much about latency. If the audio events are spaced > enough, there should be plenty of time to run the resampling. we > should instead adjust the sink/source latencies to reduce the number > of events and not compromize on quality. Aren't you assuming here that the resampling adjustment timeout happens right after the buffers are filled, and never when the buffer is running low and a refill is scheduled right after the adjustment timeout? > This trivial resampler should only be used if for some reason you want > both real-time behavior and low-latency while using an SRC. I fail to > see in what cases you would care? In what practical cases did you > encounter underflows? 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. -- Tanu
