Re: [PATCH V2] RFC: ARM: DaVinci: ASoc use iram to buffer sound
On Wednesday 01 July 2009 03:44:52 Steve Chen wrote: On Tue, 2009-06-30 at 15:54 -0700, David Brownell wrote: On Tuesday 30 June 2009, Steve Chen wrote: Can you try aplay -D hw:0,1 r441_c2.wav If you see something like Warning: rate is not accurate (requested = 44100Hz, got = 48000Hz) please, try the plug plugin That means McBSP/AIC33 are not setup to handle sample rate of 44.1K directly. The sample rates are covered by software. The problem is likely in the area of rate conversion. And ... seeking someone who has a bit of spare time, a DM6446 EVM, and interest in solving it: that EVM can switch audio clocking at runtime, among six different sample rates (of which those are two). So it would be interesting to get that working. :) Looking at the code, I think support for various sample rates for boards that uses aix3x are in place. The values to correctly divide down the clock are calculated in aic3x_hw_params. I think it is a matter of making AIC3X the clock master, advertise the rates, and test... simple right :-) By looking at the code, I can say that AIC3X is the master. It is defined in davinci-evm.c as: #define AUDIO_FORMAT (SND_SOC_DAIFMT_DSP_B | \ SND_SOC_DAIFMT_CBM_CFM | SND_SOC_DAIFMT_IB_NF) So I guess aic3x is responsible for this 44.1 khz problem here. I'm sorry if I'm missing something here, I'm totally dumb about this audio stuff. Thanks, Caglar ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH V2] RFC: ARM: DaVinci: ASoc use iram to buffer sound
On Tue, 2009-06-30 at 15:54 -0700, David Brownell wrote: On Tuesday 30 June 2009, Steve Chen wrote: Can you try aplay -D hw:0,1 r441_c2.wav If you see something like Warning: rate is not accurate (requested = 44100Hz, got = 48000Hz) please, try the plug plugin That means McBSP/AIC33 are not setup to handle sample rate of 44.1K directly. The sample rates are covered by software. The problem is likely in the area of rate conversion. And ... seeking someone who has a bit of spare time, a DM6446 EVM, and interest in solving it: that EVM can switch audio clocking at runtime, among six different sample rates (of which those are two). So it would be interesting to get that working. :) Looking at the code, I think support for various sample rates for boards that uses aix3x are in place. The values to correctly divide down the clock are calculated in aic3x_hw_params. I think it is a matter of making AIC3X the clock master, advertise the rates, and test... simple right :-) If you don't see the warning, McBSP/AIC33 is setup to handle 44.1K directly. You man want to check with clock settings (make sure AIC33 is setup as the master). ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH V2] RFC: ARM: DaVinci: ASoc use iram to buffer sound
On Wed, 2009-07-01 at 08:48 +0300, Yusuf Caglar AKYUZ wrote: Steve Chen wrote: I believe GStreamer uses the OSS emulation layer. It appears that the problem is at sample rate of 44.1k. I disabled CONFIG_SND_SUPPORT_OLD_API and tried with that. Results are the same. Is there a way to disable OSS emulation layer, Disable CONFIG_SND_MIXER_OSS and CONFIG_SND_PCM_OSS should disable OSS emulation. A quick check you can do is to verify /dev/dsp is no longer present. or should I check gstreamer handling of alsa? Yes, you can probably get around this issue by using ALSA within gstreamer. From these two examples it was clear(at least for me) that there were some problem with driver, especially at 44100 khz either 1 channel or 2 channel. Later I converted davincieffect.mp2 to wav at two different sample rates and played with aplay as such: $aplay r441_c2.wav Can you try aplay -D hw:0,1 r441_c2.wav If you see something like Warning: rate is not accurate (requested = 44100Hz, got = 48000Hz) please, try the plug plugin That means McBSP/AIC33 are not setup to handle sample rate of 44.1K directly. The sample rates are covered by software. The problem is likely in the area of rate conversion. If you don't see the warning, McBSP/AIC33 is setup to handle 44.1K directly. You man want to check with clock settings (make sure AIC33 is setup as the master). I tried and there was no warning: $aplay -v -D hw:0,0 r441_c2.wav Playing WAVE 'r441_c2.wav' : Signed 16 bit Little Endian, Rate 44100 Hz, Stereo Hardware PCM card 0 'DaVinci Beginning' device 0 subdevice 0 Its setup is: stream : PLAYBACK access : RW_INTERLEAVED format : S16_LE subformat: STD channels : 2 rate : 44100 exact rate : 44100 (44100/1) msbits : 16 buffer_size : 22400 period_size : 896 period_time : 20317 tstamp_mode : NONE period_step : 1 avail_min: 896 period_event : 0 start_threshold : 22400 stop_threshold : 22400 silence_threshold: 0 silence_size : 0 boundary : 1468006400 appl_ptr : 0 hw_ptr : 0 I started seeing this issue after applying this patch, maybe there is something wrong with ping-pong buffer handling as this problem is present only when sample rate is 44.1 khz. Another thing you may try is to dump AIC33 and McBSP registers and compare between ALSA and GStreamer. This will help eliminate hardware register setting as a possible cause. Regards, Caglar ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH V2] RFC: ARM: DaVinci: ASoc use iram to buffer sound
Troy Kisky wrote: Yusuf Caglar AKYUZ wrote: Troy Kisky wrote: Use the sram(iram) to avoid underrun on audio. I will clean this up after someone says it works for them. Hi, First of all, thanks for looking into this. This patch makes audio usable again for me on 2.6.30 kernel and overruns are gone. What I want to ask is, there is constant noise on the output on data rates higher than 8000 khz. Anything playing with a higher rate generates random artifacts on the output. I have no idea where to look or how to test further. Do you have any pointers? Thanks, Caglar I don't have any suggestions. But if you post the codec and processor that you're using, maybe someone can verify that they see the same thing. Also, if you make a recording of the real output, and what your trying to play available, I'll take a listen to it. Could you tell if these artifacts were present before this patch? Troy Aaah! There were some problem with my player, today I tested with aplay and everything is fine. It would be nice to have this patch included in mainline. Thanks again, Caglar ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH V2] RFC: ARM: DaVinci: ASoc use iram to buffer sound
On Tue, 2009-06-30 at 18:03 +0300, Yusuf Caglar AKYUZ wrote: Aaah! There were some problem with my player, today I tested with aplay and everything is fine. It would be nice to have this patch included in mainline. Can you provide some details on which player and the sample rate you used. A few months back, I noticed background noise with wavplay when playing at sample rates that are not supported by hardware. The issue was traced to ALSA OSS sample rate conversion code (commit id 5370d96f85962769ea3df3a81cc885f257c51589). I wonder if there are scenarios the code can still fail. Regards, Steve ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH V2] RFC: ARM: DaVinci: ASoc use iram to buffer sound
Steve Chen wrote: On Tue, 2009-06-30 at 18:03 +0300, Yusuf Caglar AKYUZ wrote: Aaah! There were some problem with my player, today I tested with aplay and everything is fine. It would be nice to have this patch included in mainline. Can you provide some details on which player and the sample rate you used. A few months back, I noticed background noise with wavplay when playing at sample rates that are not supported by hardware. The issue was traced to ALSA OSS sample rate conversion code (commit id 5370d96f85962769ea3df3a81cc885f257c51589). I wonder if there are scenarios the code can still fail. Regards, Steve In the beginning, I was using gstreamer(gst-launch). My pipelines were working on my PC so I thought they were ok. Today I converted some mpeg files to wav files and then tried aplay directly. For example: $gst-launch audiotestsrc ! audio/x-raw-int,endianness=1234,rate=44100,channels=1 ! alsasink $gst-launch audiotestsrc ! audio/x-raw-int,endianness=1234,rate=48000,channels=1 ! alsasink I can say that 1st one is not working whereas 2nd one is ok. Another example is playing and mp2 file: $gst-launch filesrc location=../davincieffect.mp2 ! mad ! audio/x-raw-int,endianness=1234,signed=true,rate=44100,channels=2 ! alsasink $gst-launch filesrc location=../davincieffect48.mp2 ! mad ! audio/x-raw-int,endianness=1234,signed=true,rate=48000,channels=2 ! alsasink Again 1st one is not working but 2nd is ok. In this example davincieffect.mp2 is 44100 khz file whereas davincieffect48.mp2 is 48 khz. I tried these 2 pipelines with TI mpeg codecs as well and results were the same. So I can say that there is nothing related to 'mad' mpeg codec. From these two examples it was clear(at least for me) that there were some problem with driver, especially at 44100 khz either 1 channel or 2 channel. Later I converted davincieffect.mp2 to wav at two different sample rates and played with aplay as such: $aplay r441_c2.wav $aplay r48_c2.wav Funny thing is that both played well. 441_c2 is 44100 2-ch and r48_c2 is 48000 2-ch. I can conduct further tests if you have any suggestions since I really want to see the bottom of this problem. Regards, Caglar P.S. Tests are performed on dm6446 EVM and on a dm6446 custom board. Both have the tlv320aic33 as the codec. Custom board has a different codec clock than the EVM, 27 mhz. ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH V2] RFC: ARM: DaVinci: ASoc use iram to buffer sound
On Tue, 2009-06-30 at 19:56 +0300, Yusuf Caglar AKYUZ wrote: Steve Chen wrote: On Tue, 2009-06-30 at 18:03 +0300, Yusuf Caglar AKYUZ wrote: Aaah! There were some problem with my player, today I tested with aplay and everything is fine. It would be nice to have this patch included in mainline. Can you provide some details on which player and the sample rate you used. A few months back, I noticed background noise with wavplay when playing at sample rates that are not supported by hardware. The issue was traced to ALSA OSS sample rate conversion code (commit id 5370d96f85962769ea3df3a81cc885f257c51589). I wonder if there are scenarios the code can still fail. Regards, Steve In the beginning, I was using gstreamer(gst-launch). My pipelines were working on my PC so I thought they were ok. Today I converted some mpeg files to wav files and then tried aplay directly. For example: $gst-launch audiotestsrc ! audio/x-raw-int,endianness=1234,rate=44100,channels=1 ! alsasink $gst-launch audiotestsrc ! audio/x-raw-int,endianness=1234,rate=48000,channels=1 ! alsasink I can say that 1st one is not working whereas 2nd one is ok. Another example is playing and mp2 file: $gst-launch filesrc location=../davincieffect.mp2 ! mad ! audio/x-raw-int,endianness=1234,signed=true,rate=44100,channels=2 ! alsasink $gst-launch filesrc location=../davincieffect48.mp2 ! mad ! audio/x-raw-int,endianness=1234,signed=true,rate=48000,channels=2 ! alsasink Again 1st one is not working but 2nd is ok. In this example davincieffect.mp2 is 44100 khz file whereas davincieffect48.mp2 is 48 khz. I tried these 2 pipelines with TI mpeg codecs as well and results were the same. So I can say that there is nothing related to 'mad' mpeg codec. I believe GStreamer uses the OSS emulation layer. It appears that the problem is at sample rate of 44.1k. From these two examples it was clear(at least for me) that there were some problem with driver, especially at 44100 khz either 1 channel or 2 channel. Later I converted davincieffect.mp2 to wav at two different sample rates and played with aplay as such: $aplay r441_c2.wav Can you try aplay -D hw:0,1 r441_c2.wav If you see something like Warning: rate is not accurate (requested = 44100Hz, got = 48000Hz) please, try the plug plugin That means McBSP/AIC33 are not setup to handle sample rate of 44.1K directly. The sample rates are covered by software. The problem is likely in the area of rate conversion. If you don't see the warning, McBSP/AIC33 is setup to handle 44.1K directly. You man want to check with clock settings (make sure AIC33 is setup as the master). $aplay r48_c2.wav Funny thing is that both played well. 441_c2 is 44100 2-ch and r48_c2 is 48000 2-ch. I can conduct further tests if you have any suggestions since I really want to see the bottom of this problem. Parts of ALSA and ALSA OSS emulation layer goes through different code path, so it is entirely possible that aplay works, but GStreamer can fail under some scenarios. Regards, Steve Regards, Caglar P.S. Tests are performed on dm6446 EVM and on a dm6446 custom board. Both have the tlv320aic33 as the codec. Custom board has a different codec clock than the EVM, 27 mhz. ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH V2] RFC: ARM: DaVinci: ASoc use iram to buffer sound
Can you try aplay -D hw:0,1 r441_c2.wav I mean to say aplay -D hw:0,0 r441_c2.wav Sorry. Steve ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH V2] RFC: ARM: DaVinci: ASoc use iram to buffer sound
On Tuesday 30 June 2009, Steve Chen wrote: Can you try aplay -D hw:0,1 r441_c2.wav If you see something like Warning: rate is not accurate (requested = 44100Hz, got = 48000Hz) please, try the plug plugin That means McBSP/AIC33 are not setup to handle sample rate of 44.1K directly. The sample rates are covered by software. The problem is likely in the area of rate conversion. And ... seeking someone who has a bit of spare time, a DM6446 EVM, and interest in solving it: that EVM can switch audio clocking at runtime, among six different sample rates (of which those are two). So it would be interesting to get that working. :) If you don't see the warning, McBSP/AIC33 is setup to handle 44.1K directly. You man want to check with clock settings (make sure AIC33 is setup as the master). ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH V2] RFC: ARM: DaVinci: ASoc use iram to buffer sound
Steve Chen wrote: I believe GStreamer uses the OSS emulation layer. It appears that the problem is at sample rate of 44.1k. I disabled CONFIG_SND_SUPPORT_OLD_API and tried with that. Results are the same. Is there a way to disable OSS emulation layer, or should I check gstreamer handling of alsa? From these two examples it was clear(at least for me) that there were some problem with driver, especially at 44100 khz either 1 channel or 2 channel. Later I converted davincieffect.mp2 to wav at two different sample rates and played with aplay as such: $aplay r441_c2.wav Can you try aplay -D hw:0,1 r441_c2.wav If you see something like Warning: rate is not accurate (requested = 44100Hz, got = 48000Hz) please, try the plug plugin That means McBSP/AIC33 are not setup to handle sample rate of 44.1K directly. The sample rates are covered by software. The problem is likely in the area of rate conversion. If you don't see the warning, McBSP/AIC33 is setup to handle 44.1K directly. You man want to check with clock settings (make sure AIC33 is setup as the master). I tried and there was no warning: $aplay -v -D hw:0,0 r441_c2.wav Playing WAVE 'r441_c2.wav' : Signed 16 bit Little Endian, Rate 44100 Hz, Stereo Hardware PCM card 0 'DaVinci Beginning' device 0 subdevice 0 Its setup is: stream : PLAYBACK access : RW_INTERLEAVED format : S16_LE subformat: STD channels : 2 rate : 44100 exact rate : 44100 (44100/1) msbits : 16 buffer_size : 22400 period_size : 896 period_time : 20317 tstamp_mode : NONE period_step : 1 avail_min: 896 period_event : 0 start_threshold : 22400 stop_threshold : 22400 silence_threshold: 0 silence_size : 0 boundary : 1468006400 appl_ptr : 0 hw_ptr : 0 I started seeing this issue after applying this patch, maybe there is something wrong with ping-pong buffer handling as this problem is present only when sample rate is 44.1 khz. Regards, Caglar ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH V2] RFC: ARM: DaVinci: ASoc use iram to buffer sound
David Brownell wrote: On Tuesday 30 June 2009, Steve Chen wrote: Can you try aplay -D hw:0,1 r441_c2.wav If you see something like Warning: rate is not accurate (requested = 44100Hz, got = 48000Hz) please, try the plug plugin That means McBSP/AIC33 are not setup to handle sample rate of 44.1K directly. The sample rates are covered by software. The problem is likely in the area of rate conversion. And ... seeking someone who has a bit of spare time, a DM6446 EVM, and interest in solving it: that EVM can switch audio clocking at runtime, among six different sample rates (of which those are two). So it would be interesting to get that working. :) Do you mean controlling PLL1705 with i2c expander u18? I always wonder why this is necessary for evm. Isn't AIC33 able to create common audio frequencies internally from a reasonable input clock, say 27 Mhz? Regards, Caglar ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH V2] RFC: ARM: DaVinci: ASoc use iram to buffer sound
Troy Kisky wrote: Use the sram(iram) to avoid underrun on audio. I will clean this up after someone says it works for them. Hi, First of all, thanks for looking into this. This patch makes audio usable again for me on 2.6.30 kernel and overruns are gone. What I want to ask is, there is constant noise on the output on data rates higher than 8000 khz. Anything playing with a higher rate generates random artifacts on the output. I have no idea where to look or how to test further. Do you have any pointers? Thanks, Caglar Signed-off-by: Troy Kisky troy.ki...@boundarydevices.com --- I fixed 2 bugs in this version. 1. I ensure that buffer size is a multiple of period size. 2. Disable asp rx on shutdown. If it is not disabled on shutdown, you cannot initialize it to different settings. include/sound/soc-dai.h |2 + sound/soc/davinci/davinci-i2s.c | 337 - sound/soc/davinci/davinci-pcm.c | 521 ++- sound/soc/davinci/davinci-pcm.h |3 +- 4 files changed, 624 insertions(+), 239 deletions(-) ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH V2] RFC: ARM: DaVinci: ASoc use iram to buffer sound
Yusuf Caglar AKYUZ wrote: Troy Kisky wrote: Use the sram(iram) to avoid underrun on audio. I will clean this up after someone says it works for them. Hi, First of all, thanks for looking into this. This patch makes audio usable again for me on 2.6.30 kernel and overruns are gone. What I want to ask is, there is constant noise on the output on data rates higher than 8000 khz. Anything playing with a higher rate generates random artifacts on the output. I have no idea where to look or how to test further. Do you have any pointers? Thanks, Caglar I don't have any suggestions. But if you post the codec and processor that you're using, maybe someone can verify that they see the same thing. Also, if you make a recording of the real output, and what your trying to play available, I'll take a listen to it. Could you tell if these artifacts were present before this patch? Troy ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH V2] RFC: ARM: DaVinci: ASoc use iram to buffer sound
On Monday 25 May 2009, Troy Kisky wrote: Use the sram(iram) to avoid underrun on audio. I will clean this up after someone says it works for them. Doesn't apply against current kernels though ... ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: [PATCH V2] RFC: ARM: DaVinci: ASoc use iram to buffer sound
On Tue, May 26, 2009 at 08:04:02, Troy Kisky wrote: Signed-off-by: Troy Kisky troy.ki...@boundarydevices.com --- I fixed 2 bugs in this version. 1. I ensure that buffer size is a multiple of period size. 2. Disable asp rx on shutdown. If it is not disabled on shutdown, you cannot initialize it to different settings. With this version of the patch, the set of underrun messages which were coming on DM644x EVM initially when loopback is started, are not coming. I observed one strange problem on DM644x. Noise is observed when loopback is run at 44100 KHz sample rate. When loopback is restarted, the noise goes away. On DM355 EVM though, I see one or two underrun messages when loopback is started. Recording and playback are working fine without any issues both on DM644x and DM355 EVMs. Regards, Sudhakar ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
