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

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