* 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
* 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 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: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-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-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-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-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
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 --
[not found] <42848A5C5A0D1E47B026E644DD49B08E683708@mail>
2005-11-23 16:10 ` Problem with ALSA in 2.6.14-omap2 on OSK Dirk Behme
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
-- strict thread matches above, loose matches on Subject: below --
2005-12-13 16:18 Menon, Nishanth
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox