On Thu 31 Jan 09:33 PST 2019, Srinivas Kandagatla wrote: > On 31/01/2019 16:05, Bjorn Andersson wrote: > > Sure, but we want the design to allow for that still, either in future > > upstream or by additional downstream code. > > > Yes, I agree, I don't have solution for this ATM. > It will be interesting to see how Intel handles this kind of usecase on > there DSP. > > The whole issue is the APR messaging is not really atomic in nature, it is > basically request->response but the fact in existing code is that smd/glink > callbacks run in interrupt context. > > Trying to pretend that APR is atomic in nature is problem with audio. > > As audio (dai-links) can be marked as atomic or non-atomic depending on > which bus it links with, for example when it has to work with other buses > like slimbus, soundwire, i2c whose transactions can sleep we mark the audio > dai-link as non-atomic which means that the functions can sleep. > In the above case, invoking any audio functions as part of the rpmsg > callback is an issue. > > The only solution I found to address this is handle the callbacks in > workqueue. > Okay, I think we should merge this and once we have the means of doing low latency playback we can measure and worst case revisit this decision. Reviewed-by: Bjorn Andersson <bjorn.andersson@xxxxxxxxxx> Regards, Bjorn > > > Also it depends on definition of "latency", is the latency referring to > > > "filling the data" or "latency between DSP command and response". > > > > > I'm referring to the latency between the message from the DSP until we > > give it a new buffer. > > > > > For former case as long as we have more samples in our ring buffer there > > > should be no latency in filling the data. > > > For later case it should not really matter as long as former case is taken > > > care off. > > > > > > Low latency audio involves smaller sample sizes and no or minimal > > > preprocessing in DSP so am guessing that we should be okay with responses in > > > workqueue as long as we have good size ring buffer. > > > > > Relying on more buffered data will increase the latency of the audio, > > preventing you from doing really low-latency things. > My bad!.. Yes, in low latency case we would have very less buffers! > > srini >
