Re: [alsa-devel] Beep sound in the end of audio file
Hello,
On Tuesday 05 May 2009 20:03:57 ext Aggarwal, Anuj wrote:
Hi,
After playing out any audio file on OMAP3 EVM, having TWL4030 codec, I am hearing a beep sound. I have also tried implementing a mute function in which I disabled all the inputs/outputs but still that didn't help.
Any idea how this can be avoided?
I have not heard from this kind of problem so far, which does not mean, that it does not exist ;) Can you describe the beep sound?
After a quick look I can not pin point the soc board file used with the omap3evm board. Is it in the tree?
Does the beep happens in these cases also (after stopping it with Ctrl+C): aplay -f dat /dev/zero aplay -f dat /dev/urandom
CC-ing alsa-devel...
Thanks and Regards, Anuj Aggarwal
Platform Support Products Texas Instruments Incorporated
-----Original Message----- From: Peter Ujfalusi [mailto:peter.ujfalusi@nokia.com] Sent: Wednesday, May 06, 2009 11:03 AM To: Aggarwal, Anuj Cc: linux-omap@vger.kernel.org; alsa-devel@alsa-project.org Subject: Re: Beep sound in the end of audio file
Hello,
On Tuesday 05 May 2009 20:03:57 ext Aggarwal, Anuj wrote:
Hi,
After playing out any audio file on OMAP3 EVM, having TWL4030 codec, I am hearing a beep sound. I have also tried implementing a mute function in which I disabled all the inputs/outputs but still that didn't help.
Any idea how this can be avoided?
I have not heard from this kind of problem so far, which does not mean, that it does not exist ;) Can you describe the beep sound?
[Aggarwal, Anuj] It's kind of a "tuck" sound coming in the end, after 1 or 2 seconds.
After a quick look I can not pin point the soc board file used with the omap3evm board. Is it in the tree?
[Aggarwal, Anuj] No, it is not. Reason being we already have beagle & sdp3430 there, which are both similar to omap3evm, which I pushed. So mine got rejected. We had some discussions on how to handle this scenario but nothing got finalized.
Does the beep happens in these cases also (after stopping it with Ctrl+C): aplay -f dat /dev/zero aplay -f dat /dev/urandom
[Aggarwal, Anuj] Yes, it comes in both the cases.
CC-ing alsa-devel...
Thanks and Regards, Anuj Aggarwal
Platform Support Products Texas Instruments Incorporated
-- Péter
On Wed, May 06, 2009 at 07:30:03PM +0530, Aggarwal, Anuj wrote:
After a quick look I can not pin point the soc board file used with the omap3evm board. Is it in the tree?
[Aggarwal, Anuj] No, it is not. Reason being we already have beagle & sdp3430 there, which are both similar to omap3evm, which I pushed. So mine got rejected. We had some discussions on how to handle this scenario but nothing got finalized.
Not from the ALSA side it didn't...
On Wed, May 6, 2009 at 7:37 PM, Mark Brown broonie@sirena.org.uk wrote:
On Wed, May 06, 2009 at 07:30:03PM +0530, Aggarwal, Anuj wrote:
After a quick look I can not pin point the soc board file used with the omap3evm board. Is it in the tree?
[Aggarwal, Anuj] No, it is not. Reason being we already have beagle & sdp3430 there, which are both similar to omap3evm, which I pushed. So mine got rejected. We had some discussions on how to handle this scenario but nothing got finalized.
Not from the ALSA side it didn't...
Mark,
Since we are not going with the generic driver, are you going to push this patch:
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg07166.html
-- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, May 07, 2009 at 03:05:08PM +0530, Arun KS wrote:
Since we are not going with the generic driver, are you going to push this patch:
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg07166.html
I can't see anything wrong with it looking in the web archive but somene should send a copy tested against current ASoC.
On Thu, May 7, 2009 at 3:08 PM, Mark Brown broonie@sirena.org.uk wrote:
On Thu, May 07, 2009 at 03:05:08PM +0530, Arun KS wrote:
Since we are not going with the generic driver, are you going to push this patch:
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg07166.html
I can't see anything wrong with it looking in the web archive but somene should send a copy tested against current ASoC.
I tested the patch with current ASoC and it is working.
Anuj,
Can you send a patch against current ASoC.
Arun
Hi,
FWIW: while developing a GSTreamer presentation using a BegleBoard (rev C), I noticed the same "tuck" sound. It also occurs a second or two after the GST application exits. I assumed it was some power management code that was disabling the audio codec after it had gone idle, but never looked into it. BeagleBoard also uses TWL4030.
GST command: gst-launch audiotestsrc freq=1000 num-buffers=100 ! alsasink
/proc/version: Linux version 2.6.28-omap1 (ddompe@Aleph) (gcc version 4.3.1 (GCC) ) #2 Thu Mar 5 08:55:58 CST 2009
Code image: http://www.beagleboard.org/~arago/esc/esc2009sj.v12.img.gz
Todd
On Wed, 2009-05-06 at 19:30 +0530, Aggarwal, Anuj wrote:
-----Original Message----- From: Peter Ujfalusi [mailto:peter.ujfalusi@nokia.com] Sent: Wednesday, May 06, 2009 11:03 AM To: Aggarwal, Anuj Cc: linux-omap@vger.kernel.org; alsa-devel@alsa-project.org Subject: Re: Beep sound in the end of audio file
Hello,
On Tuesday 05 May 2009 20:03:57 ext Aggarwal, Anuj wrote:
Hi,
After playing out any audio file on OMAP3 EVM, having TWL4030 codec, I am hearing a beep sound. I have also tried implementing a mute function in which I disabled all the inputs/outputs but still that didn't help.
Any idea how this can be avoided?
I have not heard from this kind of problem so far, which does not mean, that it does not exist ;) Can you describe the beep sound?
[Aggarwal, Anuj] It's kind of a "tuck" sound coming in the end, after 1 or 2 seconds.
After a quick look I can not pin point the soc board file used with the omap3evm board. Is it in the tree?
[Aggarwal, Anuj] No, it is not. Reason being we already have beagle & sdp3430 there, which are both similar to omap3evm, which I pushed. So mine got rejected. We had some discussions on how to handle this scenario but nothing got finalized.
Does the beep happens in these cases also (after stopping it with Ctrl+C): aplay -f dat /dev/zero aplay -f dat /dev/urandom
[Aggarwal, Anuj] Yes, it comes in both the cases.
CC-ing alsa-devel...
Thanks and Regards, Anuj Aggarwal
Platform Support Products Texas Instruments Incorporated
-- Péter
-- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wednesday 06 May 2009 17:19:49 ext Todd Fischer wrote:
Hi,
FWIW: while developing a GSTreamer presentation using a BegleBoard (rev C), I noticed the same "tuck" sound. It also occurs a second or two after the GST application exits. I assumed it was some power management code that was disabling the audio codec after it had gone idle, but never looked into it. BeagleBoard also uses TWL4030.
GST command: gst-launch audiotestsrc freq=1000 num-buffers=100 ! alsasink
/proc/version: Linux version 2.6.28-omap1 (ddompe@Aleph) (gcc version 4.3.1 (GCC) ) #2 Thu Mar 5 08:55:58 CST 2009
The "tuck" is coming from the codec, when it is powered down (in the old twl4030 codec found in omap-2.6.28 branch of linux-omap). But, it still happens with the latest version, when the codec is muted only. I can observe the "tuck" on Headset output, but not on the PreDrive... The Headset enable and disable is implemented according to the TRM, but it seams that additional tweaking is needed..
On Thursday 07 May 2009 08:48:25 Ujfalusi Peter (Nokia-D/Tampere) wrote:
On Wednesday 06 May 2009 17:19:49 ext Todd Fischer wrote:
Hi,
FWIW: while developing a GSTreamer presentation using a BegleBoard (rev C), I noticed the same "tuck" sound. It also occurs a second or two after the GST application exits. I assumed it was some power management code that was disabling the audio codec after it had gone idle, but never looked into it. BeagleBoard also uses TWL4030.
GST command: gst-launch audiotestsrc freq=1000 num-buffers=100 ! alsasink
/proc/version: Linux version 2.6.28-omap1 (ddompe@Aleph) (gcc version 4.3.1 (GCC) ) #2 Thu Mar 5 08:55:58 CST 2009
The "tuck" is coming from the codec, when it is powered down (in the old twl4030 codec found in omap-2.6.28 branch of linux-omap). But, it still happens with the latest version, when the codec is muted only. I can observe the "tuck" on Headset output, but not on the PreDrive... The Headset enable and disable is implemented according to the TRM, but it seams that additional tweaking is needed..
I need to revisit this... After more testing and debugging, it seams that I can not confirm the existence of the "tuck" (with the latest twl4030 codec code). As soon as I receive my Beagle board I will test it again (can anyone test this with latest ASoC code on Beagle?)...
[Anuj]: What kernel are you using where you have the beep?
-----Original Message----- From: Peter Ujfalusi [mailto:peter.ujfalusi@nokia.com] Sent: Thursday, May 07, 2009 4:38 PM To: alsa-devel@alsa-project.org Cc: todd.fischer@ridgerun.com; Aggarwal, Anuj; linux-omap@vger.kernel.org Subject: Re: [alsa-devel] Beep sound in the end of audio file
On Thursday 07 May 2009 08:48:25 Ujfalusi Peter (Nokia-D/Tampere) wrote:
On Wednesday 06 May 2009 17:19:49 ext Todd Fischer wrote:
Hi,
FWIW: while developing a GSTreamer presentation using a BegleBoard
(rev
C), I noticed the same "tuck" sound. It also occurs a second or two after the GST application exits. I assumed it was some power
management
code that was disabling the audio codec after it had gone idle, but never looked into it. BeagleBoard also uses TWL4030.
GST command: gst-launch audiotestsrc freq=1000 num-buffers=100 !
alsasink
/proc/version: Linux version 2.6.28-omap1 (ddompe@Aleph) (gcc version 4.3.1 (GCC) ) #2 Thu Mar 5 08:55:58 CST 2009
The "tuck" is coming from the codec, when it is powered down (in the old twl4030 codec found in omap-2.6.28 branch of linux-omap). But, it still happens with the latest version, when the codec is muted only. I can observe the "tuck" on Headset output, but not on the PreDrive... The Headset enable and disable is implemented according to the TRM, but it seams that additional tweaking is needed..
I need to revisit this... After more testing and debugging, it seams that I can not confirm the existence of the "tuck" (with the latest twl4030 codec code). As soon as I receive my Beagle board I will test it again (can anyone test this with latest ASoC code on Beagle?)...
[Anuj]: What kernel are you using where you have the beep?
[Aggarwal, Anuj] 2.6.29-rc3
-- Péter
On Thursday 07 May 2009 14:16:12 ext Aggarwal, Anuj wrote:
[Anuj]: What kernel are you using where you have the beep?
[Aggarwal, Anuj] 2.6.29-rc3
That version still has the old power up/down code. Since than there were 23 patches for the twl4030 codec. The Headset enable/disable mantra could be still wrong in the latest version...
On Thu, May 7, 2009 at 4:54 PM, Peter Ujfalusi peter.ujfalusi@nokia.com wrote:
On Thursday 07 May 2009 14:16:12 ext Aggarwal, Anuj wrote:
[Anuj]: What kernel are you using where you have the beep?
[Aggarwal, Anuj] 2.6.29-rc3
That version still has the old power up/down code. Since than there were 23 patches for the twl4030 codec. The Headset enable/disable mantra could be still wrong in the latest version...
But i tried with latest linux-omap tree(2.6.30-rc4) copying twl4030.* files from latest linux sound tree. I can still hear the tuck noise of DAPM on omap3evm board.
Arun
-- Péter _______________________________________________ Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
On Thu, 7 May 2009 14:08:14 +0300 Peter Ujfalusi peter.ujfalusi@nokia.com wrote:
I need to revisit this... After more testing and debugging, it seams that I can not confirm the existence of the "tuck" (with the latest twl4030 codec code). As soon as I receive my Beagle board I will test it again (can anyone test this with latest ASoC code on Beagle?)...
I can hear somewhat audible (stetson guessed -20 db from /dev/urandom level) power-up/-down pop with "aplay -f dat /dev/zero" but no any other beeps or noises.
I cannot hear any difference in pop level am I using head of linux-omap or when merging sound-2.6/asoc on top of it.
Of cource this pop noise can be codec output & load dependent and also possible on-board amplifier with proper power sequencing can mask the noise. For reference, output jack of the Beagle is connected directly into HSOL and HSOR pins.
On Wed, May 6, 2009 at 1:33 AM, Peter Ujfalusi peter.ujfalusi@nokia.com wrote:
Hello,
On Tuesday 05 May 2009 20:03:57 ext Aggarwal, Anuj wrote:
Hi,
After playing out any audio file on OMAP3 EVM, having TWL4030 codec, I am hearing a beep sound. I have also tried implementing a mute function in which I disabled all the inputs/outputs but still that didn't help.
Any idea how this can be avoided?
I have not heard from this kind of problem so far, which does not mean, that it does not exist ;) Can you describe the beep sound?
After a quick look I can not pin point the soc board file used with the omap3evm board. Is it in the tree?
Does the beep happens in these cases also (after stopping it with Ctrl+C): aplay -f dat /dev/zero aplay -f dat /dev/urandom
I'm having this problem on PowerPC....
Audio is played via multiple period buffers Am interrupt is generated on the end of each period
The problem occurs at the end of the stream. The period containing the end of stream plays and generates an interrupt. ALSA then calls back with trigger(STOP)
But I can't shut off the DMA fast enough on these slower CPUs (not 3Ghz) to prevent the next period from starting to play. This next period contains data from earlier in the stream. When a small amount of it plays it sounds like a short tone beep.
The beep is only obvious if the last period being played mostly contains silence. In that case the silence will play, then you will be able to hear the burst of noise separated from the rest of the stream.
What I need to know is the address of the last valid sample in the stream. If I knew that I could just program the DMA hardware to stop after it played. I've been staring at ALSA core for a couple of days trying to figure out how to get the address for the end of the stream.
CC-ing alsa-devel...
Thanks and Regards, Anuj Aggarwal
Platform Support Products Texas Instruments Incorporated
-- Péter _______________________________________________ Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
On Wed, May 6, 2009 at 10:01 AM, Jon Smirl jonsmirl@gmail.com wrote:
On Wed, May 6, 2009 at 1:33 AM, Peter Ujfalusi peter.ujfalusi@nokia.com wrote:
Hello,
On Tuesday 05 May 2009 20:03:57 ext Aggarwal, Anuj wrote:
Hi,
After playing out any audio file on OMAP3 EVM, having TWL4030 codec, I am hearing a beep sound. I have also tried implementing a mute function in which I disabled all the inputs/outputs but still that didn't help.
Any idea how this can be avoided?
I have not heard from this kind of problem so far, which does not mean, that it does not exist ;) Can you describe the beep sound?
After a quick look I can not pin point the soc board file used with the omap3evm board. Is it in the tree?
Does the beep happens in these cases also (after stopping it with Ctrl+C): aplay -f dat /dev/zero aplay -f dat /dev/urandom
I'm having this problem on PowerPC....
Audio is played via multiple period buffers Am interrupt is generated on the end of each period
The problem occurs at the end of the stream. The period containing the end of stream plays and generates an interrupt. ALSA then calls back with trigger(STOP)
But I can't shut off the DMA fast enough on these slower CPUs (not 3Ghz) to prevent the next period from starting to play. This next period contains data from earlier in the stream. When a small amount of it plays it sounds like a short tone beep.
The beep is only obvious if the last period being played mostly contains silence. In that case the silence will play, then you will be able to hear the burst of noise separated from the rest of the stream.
PS - a simple way to see if this is your problem. In the ISR memset the buffer that just finished playing to zero. That will make the problem go away since the stale data is now just silence.
What I need to know is the address of the last valid sample in the stream. If I knew that I could just program the DMA hardware to stop after it played. I've been staring at ALSA core for a couple of days trying to figure out how to get the address for the end of the stream.
CC-ing alsa-devel...
Thanks and Regards, Anuj Aggarwal
Platform Support Products Texas Instruments Incorporated
-- Péter _______________________________________________ Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
-- Jon Smirl jonsmirl@gmail.com
participants (7)
-
Aggarwal, Anuj -
Arun KS -
Jarkko Nikula -
Jon Smirl -
Mark Brown -
Peter Ujfalusi -
Todd Fischer