On Fri, Mar 11, 2016 at 11:39:11AM +0100, Takashi Iwai wrote:
On Fri, 11 Mar 2016 11:37:47 +0100, Vinod Koul wrote:
On Fri, Mar 11, 2016 at 10:04:25AM +0000, Charles Keepax wrote:
On Fri, Mar 11, 2016 at 01:18:43PM +0530, Vinod Koul wrote:
On Thu, Mar 10, 2016 at 10:44:51AM +0000, Charles Keepax wrote:
The soc_compr_pointer does not correctly pass any errors returned by the driver callback back up the stack. This patch corrects this issue.
Should we do that :) I am not too sure. Pointer query is supposed to read the current value and return. You are trying to indicate that stream has gone bad which is not the same as read faced an error...
Also please use cover letter for these things to describe problem you are trying to solve.
Apologies for not doing so, I had been viewing this as more of a simple oversight in the framework rather than a design choice.
The problem I am looking at is the DSP suffers an unrecoverable error. We can find out about this error in our driver because the DSP returns some error status to us. This is fine if user-space is doing a read as reads return error status back to user-space so the user can find out that things have gone bad. However, if user-space is doing an avail request there is no path for the error to come back up to user-space. The pointer request returns zero available data, so a read never happens and we basically just end up sitting waiting for data on a stream that we know full well has died.
So this confirms my hunch and we should then notify core of error by stopping the stream properly and then return error on poll/pointer query.
So cna try this untested patch, whcih includes a hack for stopped state. We don't seem to have a stopped state in ALSA, that bit would need refinement
In PCM, the stopped state is either SETUP/PREPARE or XRUN.
Takashi
Thanks guys, I will take a look at all this and look at respinning the series.
Thanks, Charles