playback write error(DMA or IRQ trouble?)

playback write error(DMA or IRQ trouble?)

[innoway]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 1909 bytes --]

 I develop an embedded system on the Linux board with Freescale i.MX27
(ARM processor).   I succeed on sound, which is transferred using
Synchronous Serial Interface (SSI). It,s fine and then I try to do test
of inserting or pulling out a USB memory stick in the USB host connector
while sounding.   I get the following error message from
snd_pcm_lib_write1() of <linux src>/sound /core/pcm_lib.c after waiting
for a while (about 10sec).       playback  write error (DMA or IRQ
trouble?)   and then from snd_pcm_drain() of <linux
src>/sound/core/pcm_native.c      playback drain error (DMA or IRQ
trouble?)   (No sound during this period)

and then it is sounding again.

I want to prevent the sound from stopping even if something happens
suddenly such as the USB memory stick is plugged in or out.

I try to fix the above programs, but I don't succeed.

Can someone give me the clue?   [13:21:38]:/proc# cat interrupts
           CPU0
 12:       3456         -  mxc_i2c
 16:        141          -  CSPI_IRQ
 18:        952          -  mxcintuart
 26:    1051255     -  MXC Timer Tick
 28:      29446        -  PCMCIA IRQ, ide0
 50:         33           -  fec
 54:        793          -  ehci_hcd:usb1
 56:          1            -  arc_udc
 61:          0            -  LCDC
117:          0           -  m66291_udc
147:          0           -  PMIC_IRQ
157:     337179     -  SMSC_LAN911x_ISR
176:          0           -  fec(MII)

[13:35:03]:/proc# cat dma
dma channel  0: unused
dma channel  1: unused
dma channel  2: unused
dma channel  3: unused
dma channel  4: unused
dma channel  5: unused
dma channel  6: unused
dma channel  7: unused
dma channel  8: unused
dma channel  9: unused
dma channel 10: unused
dma channel 11: unused
dma channel 12: unused
dma channel 13: unused
dma channel 14: unused
dma channel 15: unused   Thank you

Masanori Inoue

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: playback write error(DMA or IRQ trouble?)

[Raymond Yau]

2011/5/20  <innoway@mymelody.com>:
>  I develop an embedded system on the Linux board with Freescale i.MX27
> (ARM processor).   I succeed on sound, which is transferred using
> Synchronous Serial Interface (SSI). It,s fine and then I try to do test
> of inserting or pulling out a USB memory stick in the USB host connector
> while sounding.   I get the following error message from
> snd_pcm_lib_write1() of <linux src>/sound /core/pcm_lib.c after waiting
> for a while (about 10sec).       playback  write error (DMA or IRQ
> trouble?)   and then from snd_pcm_drain() of <linux
> src>/sound/core/pcm_native.c      playback drain error (DMA or IRQ
> trouble?)   (No sound during this period)
>
> and then it is sounding again.
>
> I want to prevent the sound from stopping even if something happens
> suddenly such as the USB memory stick is plugged in or out.
>
> I try to fix the above programs, but I don't succeed.
>
> Can someone give me the clue?   [13:21:38]:/proc# cat interrupts
>            CPU0
>  12:       3456         -  mxc_i2c
>  16:        141          -  CSPI_IRQ
>  18:        952          -  mxcintuart
>  26:    1051255     -  MXC Timer Tick
>  28:      29446        -  PCMCIA IRQ, ide0
>  50:         33           -  fec
>  54:        793          -  ehci_hcd:usb1
>  56:          1            -  arc_udc
>  61:          0            -  LCDC
> 117:          0           -  m66291_udc
> 147:          0           -  PMIC_IRQ
> 157:     337179     -  SMSC_LAN911x_ISR
> 176:          0           -  fec(MII)
>
> [13:35:03]:/proc# cat dma
> dma channel  0: unused
> dma channel  1: unused
> dma channel  2: unused
> dma channel  3: unused
> dma channel  4: unused
> dma channel  5: unused
> dma channel  6: unused
> dma channel  7: unused
> dma channel  8: unused
> dma channel  9: unused
> dma channel 10: unused
> dma channel 11: unused
> dma channel 12: unused
> dma channel 13: unused
> dma channel 14: unused
> dma channel 15: unused   Thank you
>
> Masanori Inoue
>

This error also occur in snd-hda-intel

echo 32768 > /proc/asound/Intel/pcm0p/sub0/prealloc

speaker-test which use maximum buffer size also have (DMA or IRQ error
in system log

THis seem to be related to the schedule_timeout

		tout = schedule_timeout(msecs_to_jiffies(10000));

I guess this is why PA server treat avail  > 10 seconds is invalid

Re: playback write error(DMA or IRQ trouble?)

[innoway]

 I'll try to fix the programs from this Monday and I think I have to
learn alsa system more deeply because I 'm a newcomer about it. Thank you

  2011/5/20 <innoway@mymelody.com>:
  > I develop an embedded system on the Linux board with Freescale
  i.MX27
  > (ARM processor). I succeed on sound, which is transferred using
  > Synchronous Serial Interface (SSI). It,s fine and then I try to do
  test
  > of inserting or pulling out a USB memory stick in the USB host
  connector
  > while sounding. I get the following error message from
  > snd_pcm_lib_write1() of <linux src>/sound /core/pcm_lib.c after
  waiting
  > for a while (about 10sec). playback write error (DMA or IRQ
  > trouble?) and then from snd_pcm_drain() of <linux
  > src>/sound/core/pcm_native.c playback drain error (DMA or IRQ
  > trouble?) (No sound during this period)
  >
  > and then it is sounding again.
  >
  > I want to prevent the sound from stopping even if something happens
  > suddenly such as the USB memory stick is plugged in or out.
  >
  > I try to fix the above programs, but I don't succeed.
  >
  > Can someone give me the clue? [13:21:38]:/proc# cat interrupts
  > CPU0
  > 12: 3456 - mxc_i2c
  > 16: 141 - CSPI_IRQ
  > 18: 952 - mxcintuart
  > 26: 1051255 - MXC Timer Tick
  > 28: 29446 - PCMCIA IRQ, ide0
  > 50: 33 - fec
  > 54: 793 - ehci_hcd:usb1
  > 56: 1 - arc_udc
  > 61: 0 - LCDC
  > 117: 0 - m66291_udc
  > 147: 0 - PMIC_IRQ
  > 157: 337179 - SMSC_LAN911x_ISR
  > 176: 0 - fec(MII)
  >
  > [13:35:03]:/proc# cat dma
  > dma channel 0: unused
  > dma channel 1: unused
  > dma channel 2: unused
  > dma channel 3: unused
  > dma channel 4: unused
  > dma channel 5: unused
  > dma channel 6: unused
  > dma channel 7: unused
  > dma channel 8: unused
  > dma channel 9: unused
  > dma channel 10: unused
  > dma channel 11: unused
  > dma channel 12: unused
  > dma channel 13: unused
  > dma channel 14: unused
  > dma channel 15: unused Thank you
  >
  > Masanori Inoue
  >

  This error also occur in snd-hda-intel

  echo 32768 > /proc/asound/Intel/pcm0p/sub0/prealloc

  speaker-test which use maximum buffer size also have (DMA or IRQ
  error
  in system log

  THis seem to be related to the schedule_timeout

  tout = schedule_timeout(msecs_to_jiffies(10000));

  I guess this is why PA server treat avail > 10 seconds is invalid
  _______________________________________________
  Alsa-devel mailing list
  Alsa-devel@alsa-project.org
  http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: playback write error (DMA or IRQ trouble)

[Takashi Iwai]

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

Re: playback write error (DMA or IRQ trouble)

[Harsha priya gupta]

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?

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

Re: playback write error (DMA or IRQ trouble)

[Takashi Iwai]

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

Re: playback write error (DMA or IRQ trouble)

[Harsha priya gupta]

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

Re: playback write error (DMA or IRQ trouble)

[Takashi Iwai]

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

Re: playback write error (DMA or IRQ trouble)

[Harsha priya gupta]

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?

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

Re: playback write error (DMA or IRQ trouble)

[Takashi Iwai]

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

Re: playback write error (DMA or IRQ trouble)

[Harsha priya gupta]

Quick question

>From my copy function after I pass the buffer to HW, what would happen if i
call snd_pcm_period_elapsed.

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

Re: playback write error (DMA or IRQ trouble)

[Takashi Iwai]

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

Re: playback write error (DMA or IRQ trouble)

[Harsha priya gupta]

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



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

Re: playback write error (DMA or IRQ trouble)

[Takashi Iwai]

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

playback write error (DMA or IRQ trouble)

[Harsha priya gupta]

Can anyone give me a clue as to when i would get such an error?

-- 
-Harsha