Say if my hardware is such that it shall interrupt only after it has
processed entire sample and not ever period or sample. What will ensure that
i get my next buffer down? Will calling the snd_pcm_period_elapsed in the
interrupt function help?
On Mon, Jun 2, 2008 at 2:54 PM, Takashi Iwai <tiwai@xxxxxxx> wrote:
> At Mon, 2 Jun 2008 14:33:14 +0530,
> Harsha priya gupta wrote:
> >
> > Quick question
> >
> > From my copy function after I pass the buffer to HW, what would happen if
> i
> > call snd_pcm_period_elapsed.
>
> It's invalid and a misdesign.
>
> I guess you are misunderstanding about when to
> callsnd_pcm_period_elapsed(). snd_pcm_period_elapsed() is called when
> one period of samples on the hardware is *processed*. It doesn't mean
> that the samples are transferred to the hardware.
>
> Suppose that you have period_size = 48000 (frames) for 48kHz samples.
> Then, the first snd_pcm_period_epased() shall be called just one
> second after starting the PCM stream. The second call be another one
> second later, and so on. It doesn't matter how quick the copy to h/w
> is done (via copy callback).
>
>
> Takashi
>
> >
> > On Mon, Jun 2, 2008 at 1:37 PM, Takashi Iwai <tiwai@xxxxxxx> 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@xxxxxxx>
> 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
> >
> >
>
--
-Harsha
_______________________________________________
Alsa-devel mailing list
Alsa-devel@xxxxxxxxxxxxxxxx
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
