All of lore.kernel.org
 help / color / mirror / Atom feed
* RE: Problem with ALSA in 2.6.14-omap2 on OSK
@ 2005-12-13 16:18 Menon, Nishanth
  0 siblings, 0 replies; 9+ messages in thread
From: Menon, Nishanth @ 2005-12-13 16:18 UTC (permalink / raw)
  To: Dirk Behme, Daniel Petrini; +Cc: linux-omap-open-source

> Some notes to my environment. I'm using ~5MB mp3 playing over NFS with
> madplay in ramdisk. Yesterday, I had an additional idea, but no time
to
> test it yet: Do you have PREEMPT (CONFIG_PREEMPT=y) enabled? May be
this
> is the difference?
One suggestion, can u measure the time b/w subsequent writes?
Get_time_of_day or something of that sort can help. The average write
time should be within sampling rate. If not, it might point at latency
issues spend in user context.. since it is only 5 Meg, can u try a
ramdisk for the test - can isolate any issues due to network latencies..
just guessing here..
Regards,
Nishanth Menon

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Problem with ALSA in 2.6.14-omap2 on OSK
  2005-12-12 19:14     ` Daniel Petrini
@ 2005-12-13 15:47       ` Dirk Behme
  0 siblings, 0 replies; 9+ messages in thread
From: Dirk Behme @ 2005-12-13 15:47 UTC (permalink / raw)
  To: Daniel Petrini; +Cc: linux-omap-open-source

Daniel Petrini wrote:
> Hi Dirk,
> 
> On 11/27/05, Dirk Behme <dirk.behme@de.bosch.com> wrote:
> 
>>Tony Lindgren wrote:
>>
>>>* Menon, Nishanth <x0nishan@ti.com> [051123 08:37]:
>>>
>>>
>>>>There is further the fix to L/R sync issue as reported by Ajaya Babu in
>>>>a previous mail in this list for the OSS - it might hit the ALSA too if
>>>>the condition is not met properly.
>>>
>>>
>>>To me it sounds like Ajaya Babu's fix to stop mcbsp before dma is
>>>enabled probably fixes the remaining problems.
>>>
>>>Does anybody have a tested patch for OSS and Alsa for that?
>>
>>In the attachment a patch for Alsa as described by Ajaya Babu (hopefully
>>correct?). Unfortunately it seems to not fix the issues with repeated
>>audio parts while using Alsa.
> 
> 
> I tested it and it worked fine here, with version omap-2.6.15-rc4
> (without rollbacks in dma.c).

Thanks for testing! Seems strange to me why Yves and I have these
glitches, and you not. As you can see by my L/R patch posted to the
list, I switched back to OSS.

Some notes to my environment. I'm using ~5MB mp3 playing over NFS with
madplay in ramdisk. Yesterday, I had an additional idea, but no time to
test it yet: Do you have PREEMPT (CONFIG_PREEMPT=y) enabled? May be this 
is the difference?

Dirk

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Problem with ALSA in 2.6.14-omap2 on OSK
  2005-11-28  9:55     ` Dirk Behme
@ 2005-12-12 19:34       ` Daniel Petrini
  0 siblings, 0 replies; 9+ messages in thread
From: Daniel Petrini @ 2005-12-12 19:34 UTC (permalink / raw)
  To: Dirk Behme; +Cc: linux-omap-open-source

Hi Dirk,

On 11/28/05, Dirk Behme <dirk.behme@de.bosch.com> wrote:
> Dirk Behme wrote:
> > Yves Godin wrote:
> >  > The files from the alsa driver have not changed between 2.6.14-rc1 and
> >  > 2.6.14-omap2. So I supposed the changes have been made to the OMAP dma
> >  > drivers.
> >
> > Looks to me that it is something in DMA as well.
>
> Next step ;) Looking into sound/oss/omap-audio-dma-intfc.c I found that
> there is done much more stuff than in sound/arm/omap-alsa-dma.c. So, I
> put the ping pong work item logic from OSS DMA to ALSA DMA as well. And
> looks like this fixes the issue of repeated audio samples :)
>
> Please test. I use 'madplay foo.mp3' for tests.
>
> But unfortunately, now there seems to be some noise over the (now
> unrepeated) audio output.
>
> Any ideas about that?

Tested this as well (against omap-2.6.15-rc4), the ping pong works,
but you have to set nr_linked_channels to 2 or 3, unlike your patch
which has 1 for this variable.

I heard the same noise throughout the music playing. Both in mp3 and wav.
With the increased channels it became more prone to inconsistences if
I stop the music with ctrl-c. But worth mention that after this key
combination, if the song can restart (calling the command again), it
starts without the mentioned noises.

Daniel
--
INdT - Manaus - Brazil

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Problem with ALSA in 2.6.14-omap2 on OSK
  2005-11-27 17:46   ` Dirk Behme
  2005-11-28  9:55     ` Dirk Behme
@ 2005-12-12 19:14     ` Daniel Petrini
  2005-12-13 15:47       ` Dirk Behme
  1 sibling, 1 reply; 9+ messages in thread
From: Daniel Petrini @ 2005-12-12 19:14 UTC (permalink / raw)
  To: Dirk Behme; +Cc: linux-omap-open-source

Hi Dirk,

On 11/27/05, Dirk Behme <dirk.behme@de.bosch.com> wrote:
> Tony Lindgren wrote:
> > * Menon, Nishanth <x0nishan@ti.com> [051123 08:37]:
> >
> >>There is further the fix to L/R sync issue as reported by Ajaya Babu in
> >>a previous mail in this list for the OSS - it might hit the ALSA too if
> >>the condition is not met properly.
> >
> >
> > To me it sounds like Ajaya Babu's fix to stop mcbsp before dma is
> > enabled probably fixes the remaining problems.
> >
> > Does anybody have a tested patch for OSS and Alsa for that?
>
> In the attachment a patch for Alsa as described by Ajaya Babu (hopefully
> correct?). Unfortunately it seems to not fix the issues with repeated
> audio parts while using Alsa.

I tested it and it worked fine here, with version omap-2.6.15-rc4
(without rollbacks in dma.c).

Cheers,

Daniel
--
INdT - Manaus - Brazil

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Problem with ALSA in 2.6.14-omap2 on OSK
  2005-11-27 17:46   ` Dirk Behme
@ 2005-11-28  9:55     ` Dirk Behme
  2005-12-12 19:34       ` Daniel Petrini
  2005-12-12 19:14     ` Daniel Petrini
  1 sibling, 1 reply; 9+ messages in thread
From: Dirk Behme @ 2005-11-28  9:55 UTC (permalink / raw)
  To: linux-omap-open-source

[-- Attachment #1: Type: text/plain, Size: 878 bytes --]

Dirk Behme wrote:
> Yves Godin wrote:
>  > The files from the alsa driver have not changed between 2.6.14-rc1 and
>  > 2.6.14-omap2. So I supposed the changes have been made to the OMAP dma
>  > drivers.
> 
> Looks to me that it is something in DMA as well.

Next step ;) Looking into sound/oss/omap-audio-dma-intfc.c I found that
there is done much more stuff than in sound/arm/omap-alsa-dma.c. So, I
put the ping pong work item logic from OSS DMA to ALSA DMA as well. And
looks like this fixes the issue of repeated audio samples :)

Please test. I use 'madplay foo.mp3' for tests.

But unfortunately, now there seems to be some noise over the (now
unrepeated) audio output.

Any ideas about that?

Note: For tests, first apply alsa_dma.patch, which includes Ajaya Babu
L/R fix (reposted here, same as in the last mail), then apply
alsa_fix_repeat.patch.

Many thanks

Dirk



[-- Attachment #2: alsa_dma.patch --]
[-- Type: text/plain, Size: 3412 bytes --]

--- ./sound/arm/omap-aic23.c_orig	2005-11-25 20:24:14.782887816 +0100
+++ ./sound/arm/omap-aic23.c	2005-11-25 20:42:10.552346000 +0100
@@ -34,6 +34,8 @@
  *
  * 2005-07-29   INdT Kernel Team - Alsa driver for omap osk. Creation of new 
  *                                 file omap-aic23.c
+ *
+ * 2005-11-25   Dirk Behme      - Added L/R Channel Interchange fix as proposed by Ajaya Babu
  */
 
 #include <linux/config.h>
@@ -156,6 +158,20 @@ static snd_pcm_hw_constraint_list_t hw_c
 	.mask = 0,
 };
 
+/*
+ * HW interface start and stop helper functions
+ */
+static int audio_ifc_start(void)
+{
+	omap_mcbsp_start(AUDIO_MCBSP); 
+	return 0;
+}
+
+static int audio_ifc_stop(void)
+{
+	omap_mcbsp_stop(AUDIO_MCBSP);
+	return 0;
+}
 
 /*
  * Codec/mcbsp init and configuration section
@@ -243,12 +259,20 @@ static void omap_aic23_audio_init(struct
 	    SNDRV_PCM_STREAM_PLAYBACK;
 	omap_aic23->s[SNDRV_PCM_STREAM_PLAYBACK].dma_dev =
 	    OMAP_DMA_MCBSP1_TX;
+	omap_aic23->s[SNDRV_PCM_STREAM_PLAYBACK].hw_start =
+	    audio_ifc_start;
+	omap_aic23->s[SNDRV_PCM_STREAM_PLAYBACK].hw_stop =
+	    audio_ifc_stop;
 
 	omap_aic23->s[SNDRV_PCM_STREAM_CAPTURE].id = "Alsa AIC23 in";
 	omap_aic23->s[SNDRV_PCM_STREAM_CAPTURE].stream_id =
 	    SNDRV_PCM_STREAM_CAPTURE;
 	omap_aic23->s[SNDRV_PCM_STREAM_CAPTURE].dma_dev =
 	    OMAP_DMA_MCBSP1_RX;
+	omap_aic23->s[SNDRV_PCM_STREAM_CAPTURE].hw_start =
+	    audio_ifc_start;
+	omap_aic23->s[SNDRV_PCM_STREAM_CAPTURE].hw_stop =
+	    audio_ifc_stop;
 
 	/* configuring the McBSP */
 	omap_mcbsp_request(AUDIO_MCBSP);
--- ./sound/arm/omap-aic23.h_orig	2005-11-25 20:28:02.368289576 +0100
+++ ./sound/arm/omap-aic23.h	2005-11-25 20:38:02.210099760 +0100
@@ -33,7 +33,8 @@
  *  2005/07/25 INdT-10LE Kernel Team - 	Alsa driver for omap osk,
  *  					original version based in sa1100 driver
  *  					and omap oss driver.
- *  
+ *
+ *  2005-11-25   Dirk Behme      - Added L/R Channel Interchange fix as proposed by Ajaya Babu
  */
 
 #ifndef __OMAP_AIC23_H
@@ -85,6 +86,8 @@ struct audio_stream {
 	snd_pcm_substream_t *stream;	/* the pcm stream */
 	unsigned linked:1;	/* dma channels linked */
 	int offset;		/* store start position of the last period in the alsa buffer */
+        int (*hw_start)(void);  /* interface to start HW interface, e.g. McBSP */
+        int (*hw_stop)(void);   /* interface to stop HW interface, e.g. McBSP */
 };
 
 /*
--- ./sound/arm/omap-alsa-dma.c_orig	2005-11-24 17:13:48.000000000 +0100
+++ ./sound/arm/omap-alsa-dma.c	2005-11-25 20:46:58.328597360 +0100
@@ -34,7 +34,9 @@
  * 2005-07-19	INdT Kernel Team - Alsa port. Creation of new file omap-alsa-dma.c based in
  * 				   omap-audio-dma-intfc.c oss file. Support for aic23 codec.
  * 				   Removal of buffer handling (Alsa does that), modifications
- * 				   in dma handling and port to alsa structures. 
+ * 				   in dma handling and port to alsa structures.
+ *
+ * 2005-11-25   Dirk Behme      - Added L/R Channel Interchange fix as proposed by Ajaya Babu
  */
 
 #include <linux/config.h>
@@ -356,8 +358,10 @@ static int audio_start_dma_chain(struct 
 	int channel = s->lch[s->dma_q_head];
 	FN_IN;
 	if (!s->started) {
+	        s->hw_stop();            /* stops McBSP Interface */ 
 		omap_start_dma(channel);
 		s->started = 1;
+		s->hw_start();           /* start McBSP interface */ 
 	}
 	/* else the dma itself will progress forward with out our help */
 	FN_OUT(0);


[-- Attachment #3: alsa_fix_repeat.patch --]
[-- Type: text/plain, Size: 2893 bytes --]

--- ./sound/arm/omap-alsa-dma.c_orig	2005-11-28 09:58:01.601413144 +0100
+++ ./sound/arm/omap-alsa-dma.c	2005-11-28 10:41:38.272618656 +0100
@@ -37,6 +37,8 @@
  * 				   in dma handling and port to alsa structures.
  *
  * 2005-11-25   Dirk Behme      - Added L/R Channel Interchange fix as proposed by Ajaya Babu
+ *
+ * 2005-11-28   Dirk Behme      - Fix DMA issues that all 5-10s a short audio part is repeated
  */
 
 #include <linux/config.h>
@@ -55,6 +57,7 @@
 #include <linux/sysrq.h>
 #include <linux/interrupt.h>
 #include <linux/dma-mapping.h>
+#include <linux/completion.h>
 
 #include <asm/uaccess.h>
 #include <asm/io.h>
@@ -126,7 +129,23 @@
 
 static spinlock_t dma_list_lock = SPIN_LOCK_UNLOCKED;
 
+struct audio_isr_work_item {
+	int current_lch;
+	u16 ch_status;
+	struct audio_stream *s;
+};
+
+static char work_item_running = 0;
 static char nr_linked_channels = 1;
+static struct audio_isr_work_item work1, work2;
+
+/*********************************** MODULE SPECIFIC FUNCTIONS PROTOTYPES *************/
+
+static void audio_dsr_handler(unsigned long);
+static DECLARE_TASKLET(audio_isr_work1, audio_dsr_handler,
+		(unsigned long)&work1);
+static DECLARE_TASKLET(audio_isr_work2, audio_dsr_handler,
+		(unsigned long)&work2);
 
 /*********************************** MODULE SPECIFIC FUNCTIONS ***********************/
 
@@ -414,6 +433,33 @@ int omap_start_sound_dma(struct audio_st
 
 }
 
+/***************************************************************************************
+ *
+ * ISR related functions
+ *
+ **************************************************************************************/
+/* The work item handler */
+static void audio_dsr_handler(unsigned long inData)
+{
+	void *data = (void *)inData;
+	struct audio_isr_work_item *work = data;
+	struct audio_stream *s = (work->s);
+
+	FN_IN;
+	DPRINTK("lch=%d,status=0x%x, data=%p as=%p\n", sound_curr_lch,
+		ch_status, data, s);
+	if (AUDIO_QUEUE_EMPTY(s)) {
+		FN_OUT(-1);
+		return;
+	}
+
+	AUDIO_INCREMENT_HEAD(s);	/* Empty the queue */
+
+	/* Try to fill again */
+	audio_dma_callback(s);
+	FN_OUT(0);
+}
+
 /* 
  * ISRs have to be short and smart.. 
  * Here we call alsa handling, after some error checking
@@ -438,8 +484,26 @@ static void sound_dma_irq_handler(int so
 		return;
 	}
 
-	if (ch_status & DCSR_END_BLOCK) 
-		audio_dma_callback(s);
+	if (AUDIO_QUEUE_LAST(s))
+		omap_audio_stop_dma(s);
+
+	/* Start the work item  - we ping pong the work items */
+	if (!work_item_running) {
+		work1.current_lch = sound_curr_lch;
+		work1.ch_status = ch_status;
+		work1.s = s;
+		/* schedule tasklet 1 */
+		tasklet_schedule(&audio_isr_work1);
+		work_item_running = 1;
+	} else {
+		work2.current_lch = sound_curr_lch;
+		work2.ch_status = ch_status;
+		work2.s = s;
+		/* schedule tasklet 2 */
+		tasklet_schedule(&audio_isr_work2);
+		work_item_running = 0;
+	}
+
 	FN_OUT(0);
 	return;
 }


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



^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Problem with ALSA in 2.6.14-omap2 on OSK
  2005-11-23 16:45 ` Tony Lindgren
@ 2005-11-27 17:46   ` Dirk Behme
  2005-11-28  9:55     ` Dirk Behme
  2005-12-12 19:14     ` Daniel Petrini
  0 siblings, 2 replies; 9+ messages in thread
From: Dirk Behme @ 2005-11-27 17:46 UTC (permalink / raw)
  To: Tony Lindgren; +Cc: linux-omap-open-source

[-- Attachment #1: Type: text/plain, Size: 1173 bytes --]

Tony Lindgren wrote:
> * Menon, Nishanth <x0nishan@ti.com> [051123 08:37]:
> 
>>There is further the fix to L/R sync issue as reported by Ajaya Babu in
>>a previous mail in this list for the OSS - it might hit the ALSA too if
>>the condition is not met properly. 
> 
> 
> To me it sounds like Ajaya Babu's fix to stop mcbsp before dma is
> enabled probably fixes the remaining problems.
> 
> Does anybody have a tested patch for OSS and Alsa for that?

In the attachment a patch for Alsa as described by Ajaya Babu (hopefully
correct?). Unfortunately it seems to not fix the issues with repeated
audio parts while using Alsa.

Yves Godin wrote:
  > The files from the alsa driver have not changed between 2.6.14-rc1 and
  > 2.6.14-omap2. So I supposed the changes have been made to the OMAP dma
  > drivers.

Looks to me that it is something in DMA as well. I made some test with
rolling back DMA changes and seems to me that is something *before*

http://source.mvista.com/git/gitweb.cgi?p=linux-omap-2.6.git;a=commit;h=1ffea4734ff8b26784cb94ad77fe09151d6febb1 


Removing all changes in dma.c and dma.h including this patch shows the
broken audio output as well.

Dirk



[-- Attachment #2: alsa_dma.patch --]
[-- Type: text/plain, Size: 3413 bytes --]

--- ./sound/arm/omap-aic23.c_orig	2005-11-25 20:24:14.782887816 +0100
+++ ./sound/arm/omap-aic23.c	2005-11-25 20:42:10.552346000 +0100
@@ -34,6 +34,8 @@
  *
  * 2005-07-29   INdT Kernel Team - Alsa driver for omap osk. Creation of new 
  *                                 file omap-aic23.c
+ *
+ * 2005-11-25   Dirk Behme      - Added L/R Channel Interchange fix as proposed by Ajaya Babu
  */
 
 #include <linux/config.h>
@@ -156,6 +158,20 @@ static snd_pcm_hw_constraint_list_t hw_c
 	.mask = 0,
 };
 
+/*
+ * HW interface start and stop helper functions
+ */
+static int audio_ifc_start(void)
+{
+	omap_mcbsp_start(AUDIO_MCBSP); 
+	return 0;
+}
+
+static int audio_ifc_stop(void)
+{
+	omap_mcbsp_stop(AUDIO_MCBSP);
+	return 0;
+}
 
 /*
  * Codec/mcbsp init and configuration section
@@ -243,12 +259,20 @@ static void omap_aic23_audio_init(struct
 	    SNDRV_PCM_STREAM_PLAYBACK;
 	omap_aic23->s[SNDRV_PCM_STREAM_PLAYBACK].dma_dev =
 	    OMAP_DMA_MCBSP1_TX;
+	omap_aic23->s[SNDRV_PCM_STREAM_PLAYBACK].hw_start =
+	    audio_ifc_start;
+	omap_aic23->s[SNDRV_PCM_STREAM_PLAYBACK].hw_stop =
+	    audio_ifc_stop;
 
 	omap_aic23->s[SNDRV_PCM_STREAM_CAPTURE].id = "Alsa AIC23 in";
 	omap_aic23->s[SNDRV_PCM_STREAM_CAPTURE].stream_id =
 	    SNDRV_PCM_STREAM_CAPTURE;
 	omap_aic23->s[SNDRV_PCM_STREAM_CAPTURE].dma_dev =
 	    OMAP_DMA_MCBSP1_RX;
+	omap_aic23->s[SNDRV_PCM_STREAM_CAPTURE].hw_start =
+	    audio_ifc_start;
+	omap_aic23->s[SNDRV_PCM_STREAM_CAPTURE].hw_stop =
+	    audio_ifc_stop;
 
 	/* configuring the McBSP */
 	omap_mcbsp_request(AUDIO_MCBSP);
--- ./sound/arm/omap-aic23.h_orig	2005-11-25 20:28:02.368289576 +0100
+++ ./sound/arm/omap-aic23.h	2005-11-25 20:38:02.210099760 +0100
@@ -33,7 +33,8 @@
  *  2005/07/25 INdT-10LE Kernel Team - 	Alsa driver for omap osk,
  *  					original version based in sa1100 driver
  *  					and omap oss driver.
- *  
+ *
+ *  2005-11-25   Dirk Behme      - Added L/R Channel Interchange fix as proposed by Ajaya Babu
  */
 
 #ifndef __OMAP_AIC23_H
@@ -85,6 +86,8 @@ struct audio_stream {
 	snd_pcm_substream_t *stream;	/* the pcm stream */
 	unsigned linked:1;	/* dma channels linked */
 	int offset;		/* store start position of the last period in the alsa buffer */
+        int (*hw_start)(void);  /* interface to start HW interface, e.g. McBSP */
+        int (*hw_stop)(void);   /* interface to stop HW interface, e.g. McBSP */
 };
 
 /*
--- ./sound/arm/omap-alsa-dma.c_orig	2005-11-24 17:13:48.000000000 +0100
+++ ./sound/arm/omap-alsa-dma.c	2005-11-25 20:46:58.328597360 +0100
@@ -34,7 +34,9 @@
  * 2005-07-19	INdT Kernel Team - Alsa port. Creation of new file omap-alsa-dma.c based in
  * 				   omap-audio-dma-intfc.c oss file. Support for aic23 codec.
  * 				   Removal of buffer handling (Alsa does that), modifications
- * 				   in dma handling and port to alsa structures. 
+ * 				   in dma handling and port to alsa structures.
+ *
+ * 2005-11-25   Dirk Behme      - Added L/R Channel Interchange fix as proposed by Ajaya Babu
  */
 
 #include <linux/config.h>
@@ -356,8 +358,10 @@ static int audio_start_dma_chain(struct 
 	int channel = s->lch[s->dma_q_head];
 	FN_IN;
 	if (!s->started) {
+	        s->hw_stop();            /* stops McBSP Interface */ 
 		omap_start_dma(channel);
 		s->started = 1;
+		s->hw_start();           /* start McBSP interface */ 
 	}
 	/* else the dma itself will progress forward with out our help */
 	FN_OUT(0);



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



^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Problem with ALSA in 2.6.14-omap2 on OSK
  2005-11-23 16:36 Menon, Nishanth
@ 2005-11-23 16:45 ` Tony Lindgren
  2005-11-27 17:46   ` Dirk Behme
  0 siblings, 1 reply; 9+ messages in thread
From: Tony Lindgren @ 2005-11-23 16:45 UTC (permalink / raw)
  To: Menon, Nishanth; +Cc: Yves Godin, linux-omap-open-source

* Menon, Nishanth <x0nishan@ti.com> [051123 08:37]:
> 
> There is further the fix to L/R sync issue as reported by Ajaya Babu in
> a previous mail in this list for the OSS - it might hit the ALSA too if
> the condition is not met properly. 

To me it sounds like Ajaya Babu's fix to stop mcbsp before dma is
enabled probably fixes the remaining problems.

Does anybody have a tested patch for OSS and Alsa for that?

Regards,

Tony

^ permalink raw reply	[flat|nested] 9+ messages in thread

* RE: Problem with ALSA in 2.6.14-omap2 on OSK
@ 2005-11-23 16:36 Menon, Nishanth
  2005-11-23 16:45 ` Tony Lindgren
  0 siblings, 1 reply; 9+ messages in thread
From: Menon, Nishanth @ 2005-11-23 16:36 UTC (permalink / raw)
  To: Dirk Behme, linux-omap-open-source; +Cc: Yves Godin

Couple of things regarding the usage of dma as far as audio goes:
If the system is loaded(such as using codecs such as madplay - still not
too loaded compared to running with a video decoder (arm side)+ a couple
of other high load apps) and only one single dma channel is used to
transmit/receive, the overhead incurred in re-filling the channel can
cause glitches in high sampling rate. This is one of the reasons why I
moved across to double dma channel ping pong styled handling in oss.

There is further the fix to L/R sync issue as reported by Ajaya Babu in
a previous mail in this list for the OSS - it might hit the ALSA too if
the condition is not met properly. 

Regards,
Nishanth Menon
> -----Original Message-----
> From: linux-omap-open-source-bounces@linux.omap.com
[mailto:linux-omap-
> open-source-bounces@linux.omap.com] On Behalf Of Dirk Behme
> Sent: Wednesday, November 23, 2005 10:10 AM
> To: linux-omap-open-source@linux.omap.com
> Cc: Yves Godin
> Subject: Re: Problem with ALSA in 2.6.14-omap2 on OSK
> 
> Yves Godin wrote:
> > 	It seems that something has change in the driver for the DMA in
> > 2.6.14-omap2.
> >
> > When I play a pure tone (ALSA driver), I ear some glitches in the
audio
> > every 5-10 secconds. Everithing was correct with 2.6.14-rc1.
> >
> > From what I can see with a scope on the serial data sent to the
codec,
> > it seems that some samples (a complete buffer??) are repeated from
time
> > to time. It's easier to ear it when playing a pure tone (ex 1Khz).
> >
> > Note that my alsa driver is slightly modified to play 24 bits audio
> > samples instead of 16 bits (DMA is configured in 32 bits).
> >
> > The files from the alsa driver have not changed between 2.6.14-rc1
and
> > 2.6.14-omap2. So I supposed the changes have been made to the OMAP
dma
> > drivers.
> 
> On 2.6.15-rc2-omap1 on OSK I can reproduce this using madplay and mp3.
> All 5-10 seconds a short part is repeated.
> 
> Any news or ideas about this?
> 
> Thanks
> 
> Dirk
> _______________________________________________
> Linux-omap-open-source mailing list
> Linux-omap-open-source@linux.omap.com
> http://linux.omap.com/mailman/listinfo/linux-omap-open-source

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Problem with ALSA in 2.6.14-omap2 on OSK
       [not found] <42848A5C5A0D1E47B026E644DD49B08E683708@mail>
@ 2005-11-23 16:10 ` Dirk Behme
  0 siblings, 0 replies; 9+ messages in thread
From: Dirk Behme @ 2005-11-23 16:10 UTC (permalink / raw)
  To: linux-omap-open-source; +Cc: Yves Godin

Yves Godin wrote:
> 	It seems that something has change in the driver for the DMA in
> 2.6.14-omap2.
> 
> When I play a pure tone (ALSA driver), I ear some glitches in the audio
> every 5-10 secconds. Everithing was correct with 2.6.14-rc1.
> 
> From what I can see with a scope on the serial data sent to the codec,
> it seems that some samples (a complete buffer??) are repeated from time
> to time. It's easier to ear it when playing a pure tone (ex 1Khz).
> 
> Note that my alsa driver is slightly modified to play 24 bits audio
> samples instead of 16 bits (DMA is configured in 32 bits). 
> 
> The files from the alsa driver have not changed between 2.6.14-rc1 and
> 2.6.14-omap2. So I supposed the changes have been made to the OMAP dma
> drivers.

On 2.6.15-rc2-omap1 on OSK I can reproduce this using madplay and mp3. 
All 5-10 seconds a short part is repeated.

Any news or ideas about this?

Thanks

Dirk

^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, other threads:[~2005-12-13 16:18 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2005-12-13 16:18 Problem with ALSA in 2.6.14-omap2 on OSK Menon, Nishanth
  -- strict thread matches above, loose matches on Subject: below --
2005-11-23 16:36 Menon, Nishanth
2005-11-23 16:45 ` Tony Lindgren
2005-11-27 17:46   ` Dirk Behme
2005-11-28  9:55     ` Dirk Behme
2005-12-12 19:34       ` Daniel Petrini
2005-12-12 19:14     ` Daniel Petrini
2005-12-13 15:47       ` Dirk Behme
     [not found] <42848A5C5A0D1E47B026E644DD49B08E683708@mail>
2005-11-23 16:10 ` Dirk Behme

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.