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.
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
