OK. So can i assume that its compulsory to raise at least a timer interrupt
every 1 second (for 48K sample/ 48 kHz). if its 96Khz, then i would have to
raise the timer interrupt every 2 seconds... correct?
On Mon, Jun 2, 2008 at 3:32 PM, Takashi Iwai <tiwai@xxxxxxx> wrote:
> At Mon, 2 Jun 2008 15:16:06 +0530,
> Harsha priya gupta wrote:
> >
> > Is there any way to avoid the timer part? Because i do not want the cpu
> to
> > bother with anything till the hardware has done its part.
>
> But your hardware doesn't do what we need. A basic part is missing.
>
> > after the hardware
> > interrupts, can i manipulate someway to get the next buffer rather than
> > interrupting every 1 sec to say that the period has been processed.
>
> Well, how would you handle "the next buffer"?
>
> Suppose all samples on the buffer are processed and an irq is issued.
> At this moment, you have no data on the buffer. It means that the
> device is already in a buffer-underrun error state.
>
> The period-based transfer is the basis of ALSA PCM transfer model.
> In this way, you can write programs requiring a precise timing
> control, too.
>
>
> Takashi
>
> >
> > On Mon, Jun 2, 2008 at 3:10 PM, Takashi Iwai <tiwai@xxxxxxx> wrote:
> >
> > At Mon, 2 Jun 2008 15:06:03 +0530,
> > Harsha priya gupta wrote:
> > >
> > > 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?
> >
> > So, your hardware has only a single ring buffer and can issue an
> > interrupt only at the end of the buffer?
> >
> > If so, you might need to seek for another interrupt source, such as a
> > system timer.
> >
> > Takashi
> >
> > > 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
> > >
> > >
> >
> > --
> > -Harsha
> >
> >
>
--
-Harsha
_______________________________________________
Alsa-devel mailing list
Alsa-devel@xxxxxxxxxxxxxxxx
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
