No subject

call snd_pcm_period_elapsed.

On Mon, Jun 2, 2008 at 1:37 PM, Takashi Iwai <tiwai at suse.de> wrote:

> At Mon, 2 Jun 2008 13:26:01 +0530,
> Harsha priya gupta wrote:
> >
> > I implemented the copy function and immediately transfered the user block
> data
> > to the hardware.
> >
> > Correct me if am wrong;
> > .pointer implementation - passes the current buffer pointer. When the
> .pointer
> > function returns the size of the buffer = user buffer size logically I
> need to
> > expect the hardware to send an interrupt because buffer is consumed and I
> > should call snd_pcm_period_elapsed after that.
> >
> > what would happen if i call the snd_pcm_period_elapsed from the pointer
> > function once the buffer is consumed from hardware. Would that be right?
>  This
> > is what i am trying to do
>
> The logic is reversed.
> The pointer callback is a passive one that does nothing but returning
> the current h/w buffer position.  This is called either from
> snd_pcm_period_elapsed() or at the PCM status update.
>
> You must call snd_pcm_period_elapsed() somewhere in your driver
> *explicitly* at the timing that one period is finished.  Usually, this
> is done in an IRQ handler the h/w generates at the period ("fragment",
> "half-buffer", or whatever) boundary.
>
> And note that the valid value from the pointer callback is between 0
> and buffer_size-1 as it handles the buffer as a ring-buffer.  The
> value buffer_size is invalid.
>
>
> Takashi
>
> > On Mon, Jun 2, 2008 at 1:02 PM, Takashi Iwai <tiwai at suse.de> wrote:
> >
> >     At Mon, 2 Jun 2008 12:39:31 +0530,
> >     Harsha priya gupta wrote:
> >     >
> >     > Can anyone give me a clue as to when i would get such an error?
> >
> >     ... only if you give more clue what exactly you did.
> >
> >     In general, it implies that an interrupt isn't issued properly at PCM
> >     period boundary.
> >
> >     Takashi
> >
> > --
> > -Harsha
> >
> >
>



-- 
-Harsha