* playback write error (DMA or IRQ trouble) @ 2008-06-02 7:09 Harsha priya gupta 2008-06-02 7:32 ` Takashi Iwai 0 siblings, 1 reply; 15+ messages in thread From: Harsha priya gupta @ 2008-06-02 7:09 UTC (permalink / raw) To: Alsa-devel Can anyone give me a clue as to when i would get such an error? -- -Harsha ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: playback write error (DMA or IRQ trouble) 2008-06-02 7:09 playback write error (DMA or IRQ trouble) Harsha priya gupta @ 2008-06-02 7:32 ` Takashi Iwai 2008-06-02 7:56 ` Harsha priya gupta 0 siblings, 1 reply; 15+ messages in thread From: Takashi Iwai @ 2008-06-02 7:32 UTC (permalink / raw) To: Harsha priya gupta; +Cc: Alsa-devel 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: playback write error (DMA or IRQ trouble) 2008-06-02 7:32 ` Takashi Iwai @ 2008-06-02 7:56 ` Harsha priya gupta 2008-06-02 8:07 ` Takashi Iwai 0 siblings, 1 reply; 15+ messages in thread From: Harsha priya gupta @ 2008-06-02 7:56 UTC (permalink / raw) To: Takashi Iwai; +Cc: Alsa-devel 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: playback write error (DMA or IRQ trouble) 2008-06-02 7:56 ` Harsha priya gupta @ 2008-06-02 8:07 ` Takashi Iwai 2008-06-02 9:03 ` Harsha priya gupta 0 siblings, 1 reply; 15+ messages in thread From: Takashi Iwai @ 2008-06-02 8:07 UTC (permalink / raw) To: Harsha priya gupta; +Cc: Alsa-devel 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 > > ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: playback write error (DMA or IRQ trouble) 2008-06-02 8:07 ` Takashi Iwai @ 2008-06-02 9:03 ` Harsha priya gupta 2008-06-02 9:24 ` Takashi Iwai 0 siblings, 1 reply; 15+ messages in thread From: Harsha priya gupta @ 2008-06-02 9:03 UTC (permalink / raw) To: Takashi Iwai; +Cc: Alsa-devel 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: playback write error (DMA or IRQ trouble) 2008-06-02 9:03 ` Harsha priya gupta @ 2008-06-02 9:24 ` Takashi Iwai 2008-06-02 9:36 ` Harsha priya gupta 0 siblings, 1 reply; 15+ messages in thread From: Takashi Iwai @ 2008-06-02 9:24 UTC (permalink / raw) To: Harsha priya gupta; +Cc: Alsa-devel 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 > > ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: playback write error (DMA or IRQ trouble) 2008-06-02 9:24 ` Takashi Iwai @ 2008-06-02 9:36 ` Harsha priya gupta 2008-06-02 9:40 ` Takashi Iwai 0 siblings, 1 reply; 15+ messages in thread From: Harsha priya gupta @ 2008-06-02 9:36 UTC (permalink / raw) To: Takashi Iwai; +Cc: Alsa-devel 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: playback write error (DMA or IRQ trouble) 2008-06-02 9:36 ` Harsha priya gupta @ 2008-06-02 9:40 ` Takashi Iwai 2008-06-02 9:46 ` Harsha priya gupta 0 siblings, 1 reply; 15+ messages in thread From: Takashi Iwai @ 2008-06-02 9:40 UTC (permalink / raw) To: Harsha priya gupta; +Cc: Alsa-devel 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 > > ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: playback write error (DMA or IRQ trouble) 2008-06-02 9:40 ` Takashi Iwai @ 2008-06-02 9:46 ` Harsha priya gupta 2008-06-02 10:02 ` Takashi Iwai 0 siblings, 1 reply; 15+ messages in thread From: Harsha priya gupta @ 2008-06-02 9:46 UTC (permalink / raw) To: Takashi Iwai; +Cc: Alsa-devel 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: playback write error (DMA or IRQ trouble) 2008-06-02 9:46 ` Harsha priya gupta @ 2008-06-02 10:02 ` Takashi Iwai 2008-06-02 10:09 ` Harsha priya gupta 0 siblings, 1 reply; 15+ messages in thread From: Takashi Iwai @ 2008-06-02 10:02 UTC (permalink / raw) To: Harsha priya gupta; +Cc: Alsa-devel 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 > > ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: playback write error (DMA or IRQ trouble) 2008-06-02 10:02 ` Takashi Iwai @ 2008-06-02 10:09 ` Harsha priya gupta 2008-06-02 10:11 ` Takashi Iwai 0 siblings, 1 reply; 15+ messages in thread From: Harsha priya gupta @ 2008-06-02 10:09 UTC (permalink / raw) To: Takashi Iwai; +Cc: Alsa-devel 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: playback write error (DMA or IRQ trouble) 2008-06-02 10:09 ` Harsha priya gupta @ 2008-06-02 10:11 ` Takashi Iwai 0 siblings, 0 replies; 15+ messages in thread From: Takashi Iwai @ 2008-06-02 10:11 UTC (permalink / raw) To: Harsha priya gupta; +Cc: Alsa-devel 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 > > ^ permalink raw reply [flat|nested] 15+ messages in thread
* playback write error(DMA or IRQ trouble?) @ 2011-05-20 5:10 innoway 2011-05-20 5:22 ` Raymond Yau 0 siblings, 1 reply; 15+ messages in thread From: innoway @ 2011-05-20 5:10 UTC (permalink / raw) To: alsa-devel [-- 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 --] ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: playback write error(DMA or IRQ trouble?) 2011-05-20 5:10 playback write error(DMA or IRQ trouble?) innoway @ 2011-05-20 5:22 ` Raymond Yau 0 siblings, 0 replies; 15+ messages in thread From: Raymond Yau @ 2011-05-20 5:22 UTC (permalink / raw) To: ALSA Development Mailing List 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: playback write error(DMA or IRQ trouble?) @ 2011-05-22 6:46 innoway 0 siblings, 0 replies; 15+ messages in thread From: innoway @ 2011-05-22 6:46 UTC (permalink / raw) To: Raymond Yau; +Cc: alsa-devel 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2011-05-22 6:46 UTC | newest] Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2008-06-02 7:09 playback write error (DMA or IRQ trouble) Harsha priya gupta 2008-06-02 7:32 ` Takashi Iwai 2008-06-02 7:56 ` Harsha priya gupta 2008-06-02 8:07 ` Takashi Iwai 2008-06-02 9:03 ` Harsha priya gupta 2008-06-02 9:24 ` Takashi Iwai 2008-06-02 9:36 ` Harsha priya gupta 2008-06-02 9:40 ` Takashi Iwai 2008-06-02 9:46 ` Harsha priya gupta 2008-06-02 10:02 ` Takashi Iwai 2008-06-02 10:09 ` Harsha priya gupta 2008-06-02 10:11 ` Takashi Iwai 2011-05-20 5:10 playback write error(DMA or IRQ trouble?) innoway 2011-05-20 5:22 ` Raymond Yau 2011-05-22 6:46 innoway
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.