[alsa-devel] playback write error (DMA or IRQ trouble)

Takashi Iwai tiwai at suse.de
Mon Jun 2 11:40:08 CEST 2008


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


More information about the Alsa-devel mailing list