- Alsa-devel - mailman.alsa-project.org

[alsa-devel] What am i doing wrong?
by Neil Jones 29 Oct '09

29 Oct '09

Im developing ASoC Driver for an SoC (I2S based). When testing playback with aplay, I get 1 buffers worth of data played back (10 periods) then playback stops due to a XRUN when my dma list wraps back to the start because the available data >= stop_threshold ?? Here are my logs, interrupts are occurring at the correct time and my buffer pointer increments by period size each time. Any help would be appreciated Aplay log: # /usr/bin/aplay -vvv /var/sample96KHz_edit.wav Playing WAVE '/var/sample96KHz_edit.wav' : Signed 16 bit Little Endian, Rate 96000 Hz, Stereo Plug PCM: Route conversion PCM (sformat=S16_LE) Transformation table: 0 <- 0*0.5 + 1*0.5 Its setup is: stream : PLAYBACK access : RW_INTERLEAVED format : S16_LE subformat : STD channels : 2 rate : 96000 exact rate : 96000 (96000/1) msbits : 16 buffer_size : 48000 period_size : 4096 period_time : 42666 tstamp_mode : NONE period_step : 1 avail_min : 4096 period_event : 0 start_threshold : 48000 stop_threshold : 48000 silence_threshold: 0 silence_size : 0 boundary : 1572864000 Slave: Hardware PCM card 0 'Metamorph-Base' device 0 subdevice 0 Its setup is: stream : PLAYBACK access : MMAP_INTERLEAVED format : S16_LE subformat : STD channels : 1 rate : 96000 exact rate : 96000 (96000/1) msbits : 16 buffer_size : 48000 period_size : 4096 period_time : 42666 tstamp_mode : NONE period_step : 1 avail_min : 4096 period_event : 0 start_threshold : 48000 stop_threshold : 48000 silence_threshold: 0 silence_size : 0 boundary : 1572864000 Max peak (8192 samples): 0x00002594 ###### 29% Max peak (8192 samples): 0x00000df8 ### 10% Max peak (8192 samples): 0x00007fff #################### 99% Max peak (8192 samples): 0x00006074 ################ 75% Max peak (8192 samples): 0x00003bff ########## 46% Max peak (8192 samples): 0x00003e7b ########## 48% Max peak (8192 samples): 0x00001abf ##### 20% Max peak (8192 samples): 0x000009e0 ## 7% Max peak (8192 samples): 0x000067df ################# 81% Max peak (8192 samples): 0x00001b45 ##### 21% Max peak (8192 samples): 0x00000b91 ## 9% Max peak (5888 samples): 0x000044a5 ########### 53% underrun!!! (at least 83.448 ms long) Status: state : XRUN trigger_time: 4784.5629989 tstamp : 4784.88220967 delay : 0 avail : 48000 avail_max : 48000 Kernel Log: PCM DMA IRQ: status 100000, timestamp 4483380 ms, ALSA sound/core/pcm_lib.c:250: period_update: pcmC0D0p:0: pos=0x1000/0x1000/0xbb80, hwptr=0x0, hw_base=0x0, hw_intr=0x0 PCM DMA IRQ: status 120000, timestamp 4483430 ms, ALSA sound/core/pcm_lib.c:250: period_update: pcmC0D0p:0: pos=0x2000/0x1000/0xbb80, hwptr=0x1000, hw_base=0x0, hw_intr=0x1000 PCM DMA IRQ: status 120000, timestamp 4483480 ms, ALSA sound/core/pcm_lib.c:250: period_update: pcmC0D0p:0: pos=0x3000/0x1000/0xbb80, hwptr=0x2000, hw_base=0x0, hw_intr=0x2000 PCM DMA IRQ: status 120000, timestamp 4483530 ms, ALSA sound/core/pcm_lib.c:250: period_update: pcmC0D0p:0: pos=0x4000/0x1000/0xbb80, hwptr=0x3000, hw_base=0x0, hw_intr=0x3000 PCM DMA IRQ: status 120000, timestamp 4483580 ms, ALSA sound/core/pcm_lib.c:250: period_update: pcmC0D0p:0: pos=0x5000/0x1000/0xbb80, hwptr=0x4000, hw_base=0x0, hw_intr=0x4000 PCM DMA IRQ: status 120000, timestamp 4483630 ms, ALSA sound/core/pcm_lib.c:250: period_update: pcmC0D0p:0: pos=0x6000/0x1000/0xbb80, hwptr=0x5000, hw_base=0x0, hw_intr=0x5000 PCM DMA IRQ: status 120000, timestamp 4483680 ms, ALSA sound/core/pcm_lib.c:250: period_update: pcmC0D0p:0: pos=0x7000/0x1000/0xbb80, hwptr=0x6000, hw_base=0x0, hw_intr=0x6000 PCM DMA IRQ: status 120000, timestamp 4483730 ms, ALSA sound/core/pcm_lib.c:250: period_update: pcmC0D0p:0: pos=0x8000/0x1000/0xbb80, hwptr=0x7000, hw_base=0x0, hw_intr=0x7000 PCM DMA IRQ: status 120000, timestamp 4483790 ms, ALSA sound/core/pcm_lib.c:250: period_update: pcmC0D0p:0: pos=0x9000/0x1000/0xbb80, hwptr=0x8000, hw_base=0x0, hw_intr=0x8000 PCM DMA IRQ: status 120000, timestamp 4483840 ms, ALSA sound/core/pcm_lib.c:250: period_update: pcmC0D0p:0: pos=0xa000/0x1000/0xbb80, hwptr=0x9000, hw_base=0x0, hw_intr=0x9000 PCM DMA IRQ: status 120000, timestamp 4483890 ms, ALSA sound/core/pcm_lib.c:250: period_update: pcmC0D0p:0: pos=0x0/0x1000/0xbb80, hwptr=0xa000, hw_base=0x0, hw_intr=0xa000 ALSA sound/core/pcm_lib.c:160: XRUN: pcmC0D0p:0 - This message is subject to Imagination Technologies' e-mail terms: http://www.imgtec.com/e-mail.htm Imagination Technologies Ltd is a limited company registered in England No: 1306335 Registered Office: Imagination House, Home Park Estate, Kings Langley, Hertfordshire, WD4 8LZ. Email to and from the company may be monitored for compliance and other administrative purposes. -

3 2

[alsa-devel] [PATCH] ASoC: TWL4030: Add APLL supply for the capture path
by Peter Ujfalusi 29 Oct '09

29 Oct '09

Capture path also need the APLL enabled, adding DAPM_SUPPLY for the Virtual ADCs. Signed-off-by: Peter Ujfalusi <peter.ujfalusi(a)nokia.com> --- I have forgot to run git add, so the capture path DAPM_SUPPLY was missing from the previous series. This also applies on top of Mark's tree, for-2.6.33-pending branch at: git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound-2.6.git and depends on the "ASoC: TWL4030: Change codec_muted to apll_enabled" patch. Sorry about this. sound/soc/codecs/twl4030.c | 5 +++++ 1 files changed, 5 insertions(+), 0 deletions(-) diff --git a/sound/soc/codecs/twl4030.c b/sound/soc/codecs/twl4030.c index 277e99c..f9121ef 100644 --- a/sound/soc/codecs/twl4030.c +++ b/sound/soc/codecs/twl4030.c @@ -1449,6 +1449,11 @@ static const struct snd_soc_dapm_route intercon[] = { {"ADC Virtual Left2", NULL, "TX2 Capture Route"}, {"ADC Virtual Right2", NULL, "TX2 Capture Route"}, + {"ADC Virtual Left1", NULL, "APLL Enable"}, + {"ADC Virtual Right1", NULL, "APLL Enable"}, + {"ADC Virtual Left2", NULL, "APLL Enable"}, + {"ADC Virtual Right2", NULL, "APLL Enable"}, + /* Analog bypass routes */ {"Right1 Analog Loopback", "Switch", "Analog Right"}, {"Left1 Analog Loopback", "Switch", "Analog Left"}, -- 1.6.5.1

2 2

[alsa-devel] [PATCH 0/2] ASoC: TWL4030: Vibra and APLL fixes
by Peter Ujfalusi 29 Oct '09

29 Oct '09

Hello, Audio driven vibrator output fix: To have correct audio routed to the vibra output, we also need to configure the VIBRA_SET register, which in theory has nothing to do with the vibra, when it is driven with audio. and fix for the APLL powering sequence: The APLL in the past was enabled at set_dai_sysclk function, but it has been fixed, which introduced some really strange signals on the outputs. This series applies on top of Mark's tree, for-2.6.33 branch at: git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound-2.6.git Since the underlying twl4030 patches are not yet in the topic/asoc of Takashi's tree. --- Jari Vanhala (1): ASoC: TWL4030: Vibra motor stop fix when it is driven with audio Peter Ujfalusi (1): ASoC: TWL4030: Change APLL powering sequence sound/soc/codecs/twl4030.c | 38 ++++++++++++++++++++++++++++++++++---- 1 files changed, 34 insertions(+), 4 deletions(-)

2 3

[alsa-devel] [PATCH] ASoC: OMAP3EVM: Use the twl4030_setup_data for headset pop-removal
by Anuj Aggarwal 29 Oct '09

29 Oct '09

The pop-removal specific values are configured for TWL4030 codec for OMAP3EVM through this patch. Signed-off-by: Anuj Aggarwal <anuj.aggarwal(a)ti.com> --- sound/soc/omap/omap3evm.c | 7 +++++++ 1 files changed, 7 insertions(+), 0 deletions(-) diff --git a/sound/soc/omap/omap3evm.c b/sound/soc/omap/omap3evm.c index 9114c26..8deb59b 100644 --- a/sound/soc/omap/omap3evm.c +++ b/sound/soc/omap/omap3evm.c @@ -93,10 +93,17 @@ static struct snd_soc_card snd_soc_omap3evm = { .num_links = 1, }; +/* twl4030 setup */ +static struct twl4030_setup_data twl4030_setup = { + .ramp_delay_value = 4, + .sysclk = 26000, +}; + /* Audio subsystem */ static struct snd_soc_device omap3evm_snd_devdata = { .card = &snd_soc_omap3evm, .codec_dev = &soc_codec_dev_twl4030, + .codec_data = &twl4030_setup, }; static struct platform_device *omap3evm_snd_device; -- 1.6.2.4

4 3

[alsa-devel] [PATCH] ALSA: ASoC: CS4270: export de-emphasis filter as ALSA control
by Daniel Mack 29 Oct '09

29 Oct '09

The CS4270 codec features an de-emphasis filter for compensation of audio material filtered by an 50/15 uS algorithm. Not sure whether we should always enable it for 44100Hz sampling frequency, but it should at least be configurable by the user. Signed-off-by: Daniel Mack <daniel(a)caiaq.de> Cc: Timur Tabi <timur(a)freescale.com> Cc: Mark Brown <broonie(a)opensource.wolfsonmicro.com> --- sound/soc/codecs/cs4270.c | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/sound/soc/codecs/cs4270.c b/sound/soc/codecs/cs4270.c index ca1e24a..8069023 100644 --- a/sound/soc/codecs/cs4270.c +++ b/sound/soc/codecs/cs4270.c @@ -520,6 +520,7 @@ static const struct snd_kcontrol_new cs4270_snd_controls[] = { SOC_SINGLE("Digital Sidetone Switch", CS4270_FORMAT, 5, 1, 0), SOC_SINGLE("Soft Ramp Switch", CS4270_TRANS, 6, 1, 0), SOC_SINGLE("Zero Cross Switch", CS4270_TRANS, 5, 1, 0), + SOC_SINGLE("De-emphasis filter", CS4270_TRANS, 0, 1, 0), SOC_SINGLE("Popguard Switch", CS4270_MODE, 0, 1, 1), SOC_SINGLE("Auto-Mute Switch", CS4270_MUTE, 5, 1, 0), SOC_DOUBLE("Master Capture Switch", CS4270_MUTE, 3, 4, 1, 1), -- 1.6.5

3 2

[alsa-devel] Digital distortion when converting Mono to Stereo?
by Daniel Mack 29 Oct '09

29 Oct '09

While testing with our ASoC enabled embedded platform, we observed a strange phenomena with Mono audio files. We used external audio test equipment for SNR/THD analysis and used a mono wav file (16bit, 44.1 KHz) which plays a simple sweep from ~10Hz to ~20KHz. As the hardware output is Stereo, an implicit conversion takes places (don't know which part of ALSA actually does it, though). Strangely, the measurement showed a phantom frequency which looks like the sweeping test signal frequency was somehow 'mirrored' at 11.025KHz (fs/4). This phantom noise becomes stronger the lower its frequency gets. So while sweeping, those two peaks were approaching each other, they met at 11KHz, and when the 'real' peak aproached 20KHz, the phantom was at something like 1KHz and had comparable level than the 'real' signal. All that was much stronger on one channel and barely there, but still measurable, on the other one. We first though about an analog filter issue, then suspected the digital input stream, but eventually it turned out that with the same test file in stereo, all these effects suddenly went away. So there must be something in the chain from aplay to the actual PXA SSP ports which adds considerable digital distortion to one channel when converting from Mono to Stereo. I didn't dig any deeper, but still wanted to let you know. Can anyone think of a possible reason for that? It doesn't harm us in our application as we will never play Mono audio eventually, but I guess it could affect others. Thanks, Daniel

1 0

[alsa-devel] aloop / asym (ttable-bindings) Merging audio stream with SIP/Skype - .asoundrc struggle
by yvonne barrymore 28 Oct '09

28 Oct '09

(NOTE: RESENT as received an email the alsa-devel mailinglist had moved.) OBJECTIVE: merge (mplayer cli or aplay) audio stream with SIP/Skype so that music can be heard during chat. Really need help from a developer I think as alsa-users mailinglist not able to help during past 2 weeks. 2 weeks happily studying alsa/plugins, posted/searched on mailing lists and tried irc as well. Could really use a guru assist. I get the parts mostly, though obviously not how it all comes together in an .asoundrc. - aloop driver is installed. After scores of attempts now wondering: maybe having the music track playing on it's own soundcard or loopback and having that merge into the microphone? channel of sip/skype's soundcard. Like, have the music play out on the intel card 0, and loopback through aloop card 1, then merge that with asym/dmix onto sip/skype's headset card 2 ???? I kinda know what the plugs do, though not how to hook-up through .asoundrc. I've found 3 or 4 great posts on alsa-devel and alsa-users though ultimately for me just glimmers of working. Rather than glut up the list here I've only posted my aplay -l Can anyone comment on exactly what I'd put in my .asoundrc? What the flow/parts would be even? To stop stuttering (fighting for card control ? etc.) I guessed that the music playing on it's own card might be good? Very happy to post what I've got though thought I should ask first if anyone has found a best practice for this. **** List of PLAYBACK Hardware Devices **** card 0: Intel [HDA Intel], device 0: ALC1200 Analog [ALC1200 Analog] Subdevices: 1/1 Subdevice #0: subdevice #0 card 0: Intel [HDA Intel], device 1: ALC1200 Digital [ALC1200 Digital] Subdevices: 1/1 Subdevice #0: subdevice #0 card 0: Intel [HDA Intel], device 6: Si3054 Modem [Si3054 Modem] Subdevices: 1/1 Subdevice #0: subdevice #0 card 1: Loopback [Loopback], device 0: Loopback PCM [Loopback PCM] Subdevices: 8/8 Subdevice #0: subdevice #0 Subdevice #1: subdevice #1 Subdevice #2: subdevice #2 Subdevice #3: subdevice #3 Subdevice #4: subdevice #4 Subdevice #5: subdevice #5 Subdevice #6: subdevice #6 Subdevice #7: subdevice #7 card 1: Loopback [Loopback], device 1: Loopback PCM [Loopback PCM] Subdevices: 8/8 Subdevice #0: subdevice #0 Subdevice #1: subdevice #1 Subdevice #2: subdevice #2 Subdevice #3: subdevice #3 Subdevice #4: subdevice #4 Subdevice #5: subdevice #5 Subdevice #6: subdevice #6 Subdevice #7: subdevice #7 card 2: default [C-Media USB Headphone Set ], device 0: USB Audio [USB Audio] Subdevices: 1/1 Subdevice #0: subdevice #0

1 0

[alsa-devel] A question about the soc jack status
by Joonyoung Shim 28 Oct '09

28 Oct '09

Hi, all. I have a question about soc jack. I know the soc jack reports the jack status when the jack status is change only. For example when the jack is inserted or released, the soc jack reports the jack status to user via input subsystem. But i want to know the jack status always regardless of the event to insert or release a jack. For example we can check the jack status always if the jack status is reported via sysfs file. So, is there how to know the jack status always the currently?

2 1

[alsa-devel] [PATCH 0/2] ASoC: TWL4030: bypass magic removal and cleanup patch
by Peter Ujfalusi 28 Oct '09

28 Oct '09

Hello, Since the soc core is now handling the codec bias state based on the complete paths as well, there is no need for the bypass tracking in the codec. The second patch replaces the missleading codec_muted to apll_enabled, which is what actually is handled by it. This series applies on top of Mark's tree, for-2.6.33-pending branch at: git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound-2.6.git Since the underlying twl4030 patches are not yet in the topic/asoc of Takashi's tree. --- Peter Ujfalusi (2): ASoC: TWL4030: Remove bypass tracking ASoC: TWL4030: Change codec_muted to apll_enabled sound/soc/codecs/twl4030.c | 146 ++++++++++++-------------------------------- 1 files changed, 39 insertions(+), 107 deletions(-)

2 3

[alsa-devel] still: clicking noise on Sigmatel 9202 - how can I use patches for 2.6.24 kernel on 2.6.30?
by Christian Steffen 28 Oct '09

28 Oct '09

Hello, I still have my problem that I have a constant clicking noise coming out of my boxes with a sigmatel 9202 sound chip on intel-hda (Poulsbo) soundcard. I now found two patches for the alsa driver that can be applied on a 2.6.24 kernel. Those patches are exactly for the sigmatel 9202, so possibly they would fix my problem. http://redirectingat.com/?id=593X1004&url=http%3A%2F%2Flists.moblin.org%2Fpi permail%2Fcommits%2F2007-December%2F001232.html and http://redirectingat.com/?id=593X1004&url=http%3A%2F%2Fwww.google.com%2Furl% 3Fsa%3Dt%26source%3Dweb%26ct%3Dres%26cd%3D9%26ved%3D0CDAQFjAI%26url%3Dhttp%2 53A%252F%252Fwww.soulinfo.com%252F~hugang%252Ftmp%252Fubuntu-hardy%25252Btux onice%252Fdebian%252Fbinary-custom.d%252Flpia%252Fpatchset%252F0010-hda_sigm atel.patch%26ei%3D4AfoSs24OpeG_Abfy7yGCA%26usg%3DAFQjCNH-mrDdDcgvhNh_eM5hy4W hepUtUQ%26sig2%3D2fK3ED_DyaLSexlPlkFufQ I found both patches here: http://software.intel.com/en-us/articles/patches-for-moblin-kernel-on-menlow / I think these patches aren't yet completely integrated into alsa driver 1.0.21? I tried to manually insert them into the files of my kernel 2.6.30 source files but without any expertise this is "impossible" to me. I think this is not the easiest job but I appreciate any help! :) Thank you very much, Cheers Christian

1 0