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