Trigger problems while writing Alsa Shim

Trigger problems while writing Alsa Shim

[bruce]

I am writing a shim from alsa to our own sound card drivers.  I was  
able to get the init driver working and our sound card recognized.   
Things seem to be set up correctly.  When I do aplay to my device (USB  
device works find), it calls my copy callback twice and then it calls  
the trigger and fails.  The call that fails is in pcm_write  
(writei_func) with a -5.  I know that my callback returns zero but  
there must be something else under the covers since that gets to be  
zero.  Any help would be appreciated.
T

Re: Trigger problems while writing Alsa Shim

[Takashi Iwai]

At Fri, 07 Mar 2008 10:10:05 -0600,
bruce@azbarclay.com wrote:
> 
> I am writing a shim from alsa to our own sound card drivers.  I was  
> able to get the init driver working and our sound card recognized.   
> Things seem to be set up correctly.  When I do aplay to my device (USB  
> device works find), it calls my copy callback twice and then it calls  
> the trigger and fails.  The call that fails is in pcm_write  
> (writei_func) with a -5.  I know that my callback returns zero but  
> there must be something else under the covers since that gets to be  
> zero.  Any help would be appreciated.

The error -5 is -EIO.  Typically it indicates that the data isn't
handled properly by the PCM core.

ALSA PCM core needs proper (asynchronous) notification via
snd_pcm_period_elapsed().  Otherwise the internals won't be updated
and you'll have the error.  Usually this is called from the irq
handler.

snd_pcm_period_elapsed() is supposed to be issued at the time when the
last period (fragment, chunk) has been processed -- meaning the sound
is really played back.  It doesn't mean that the data is fed to the
hardware.

Once after snd_pcm_period_elapsed() is called, PCM core calls the
pointer callback and updates the internals including the current
position.  Then it wakes up the pending tasks, which will restart
writing to the buffer, etc.


Takashi