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. 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.
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 wouldhappen 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 calledwhen
one period of samples on the hardware is *processed*. It doesn'tmean
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 transferedthe 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 isconsumed
and I > > should call snd_pcm_period_elapsed after that. > > > > what would happen if i call the snd_pcm_period_elapsed fromthe
pointer > > function once the buffer is consumed from hardware. Wouldthat be
right? > This > > is what i am trying to do > > The logic is reversed. > The pointer callback is a passive one that does nothing butreturning
> 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 isbetween 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 suchan
error? > > > > ... only if you give more clue what exactly you did. > > > > In general, it implies that an interrupt isn't issuedproperly
at PCM > > period boundary. > > > > Takashi > > > > -- > > -Harsha > > > > > > -- > -Harsha > >-- -Harsha