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@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

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@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@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

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@suse.de 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@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@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
>
>

-- -Harsha

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@suse.de 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@suse.de> 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@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@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
>     >
>     >
>
> --
> -Harsha
>
>

-- -Harsha

At Mon, 2 Jun 2008 15:39:07 +0530, Harsha priya gupta wrote:

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?

No, no. The one second timer is just my example where the period_size = 48000 at 48kHz is assumed. The actual timer period must be calculated from the sample rate, the buffer size and the period size given by the user and the hardware supports.

Takashi

On Mon, Jun 2, 2008 at 3:32 PM, Takashi Iwai tiwai@suse.de 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@suse.de> 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@suse.de> 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@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@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
>     >     >
>     >     >
>     >
>     > --
>     > -Harsha
>     >
>     >
>
> --
> -Harsha
>
>

-- -Harsha