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

[alsa-devel] underruns over network
by Preston Kulaga 13 May '10

13 May '10

Hello, I am quite new to ALSA and am having a bit of trouble with underruns. I am working on a voice communication system via udp sockets and am getting underruns on receiving end very sporadically (capture end is fine). Have done a great deal of reading and searching on reasons for this but am not sure what approach is best to limit the underruns. I must not be transferring the data quickly enough over the network before the ring buffer runs out of data, which makes sense, but how would you accommodate for this? I am able to buffer a large amount of network data and then playback successfully, but obviously the delay induced is so significant that it makes real-time communication impossible. If I just recover/prepare the stream after an underrun the audio is horribly distorted. Is there a normal way of dealing with this issue that I am unable to find? I would appreciate any insight, guidance, references for any help you can give me. Thank You.

1 0

[alsa-devel] ALSA and Ubuntu addendum
by Andreas Falkenhahn 13 May '10

13 May '10

Addendum: I forgot one thing that doesn't work on Ubuntu either (but works on openSUSE): PCM streams in signed 8 bit format have terrible sound artefacts on Ubuntu. If I convert them to unsigned 8 bit format, they are played correctly. But in signed format, it sounds totally broken.

1 0

[alsa-devel] ALSA and Ubuntu
by Andreas Falkenhahn 13 May '10

13 May '10

Hi, I just downloaded the latest Ubuntu Live CD (10.04) to try my app on it. It is a plain X11 app using ALSA for sound output. I developed it on openSUSE 11.2 and thought to give it a try on Ubuntu... that was a mistake, because on Ubuntu, there seem to be lots of errors with ALSA. Here are some observations: 1) snd_pcm_status_get_tstamp() always returns 0 for sec/usec. 2) snd_pcm_status_get_state() always returns SND_PCM_STATE_RUNNING, even when the PCM stream has long reached a buffer underrun. 3) snd_pcm_delay()'s return value doesn't fall below ~7000 samples or so. Even when the buffer has underrun, the return value is not 0 but about ~7000 samples. This makes it nearly impossible to detect when I should start writing new samples to the buffer... Could someone enlighten me what's going on there? Is this a known issue with Ubuntu? I'm not using any weird addons or stuff. It's really just the latest Ubuntu live CD. As I said, on openSUSE everything is working just fine. But on Ubuntu, hell is really breaking loose here... Thanks for help, Andreas

1 0

[alsa-devel] [PATCH] OMAP: McBSP: Add 32-bit mode support
by Sergey Lapin 13 May '10

13 May '10

This patchs should allow to use 32-bit samples on e.g. TLV320AIC3x codec, or others. Signed-off-by: Sergey Lapin <slapin(a)ossfans.org> --- sound/soc/omap/omap-mcbsp.c | 30 ++++++++++++++++++++++++++---- 1 files changed, 26 insertions(+), 4 deletions(-) diff --git a/sound/soc/omap/omap-mcbsp.c b/sound/soc/omap/omap-mcbsp.c index 8ad9dc9..a875d5d 100644 --- a/sound/soc/omap/omap-mcbsp.c +++ b/sound/soc/omap/omap-mcbsp.c @@ -295,8 +295,20 @@ static int omap_mcbsp_dai_hw_params(struct snd_pcm_substream *substream, omap_mcbsp_dai_dma_params[id][substream->stream].dma_req = dma; omap_mcbsp_dai_dma_params[id][substream->stream].port_addr = port; omap_mcbsp_dai_dma_params[id][substream->stream].sync_mode = sync_mode; - omap_mcbsp_dai_dma_params[id][substream->stream].data_type = - OMAP_DMA_DATA_TYPE_S16; + switch(params_format(params)) { + case SNDRV_PCM_FORMAT_S16_LE: + omap_mcbsp_dai_dma_params[id][substream->stream].data_type = + OMAP_DMA_DATA_TYPE_S16; + break; + case SNDRV_PCM_FORMAT_S32_LE: + omap_mcbsp_dai_dma_params[id][substream->stream].data_type = + OMAP_DMA_DATA_TYPE_S32; + break; + default: + omap_mcbsp_dai_dma_params[id][substream->stream].data_type = + OMAP_DMA_DATA_TYPE_S16; + break; + } snd_soc_dai_set_dma_data(cpu_dai, substream, &omap_mcbsp_dai_dma_params[id][substream->stream]); @@ -330,6 +342,14 @@ static int omap_mcbsp_dai_hw_params(struct snd_pcm_substream *substream, regs->xcr2 |= XWDLEN2(OMAP_MCBSP_WORD_16); regs->xcr1 |= XWDLEN1(OMAP_MCBSP_WORD_16); break; + case SNDRV_PCM_FORMAT_S32_LE: + /* Set word lengths */ + wlen = 32; + regs->rcr2 |= RWDLEN2(OMAP_MCBSP_WORD_32); + regs->rcr1 |= RWDLEN1(OMAP_MCBSP_WORD_32); + regs->xcr2 |= XWDLEN2(OMAP_MCBSP_WORD_32); + regs->xcr1 |= XWDLEN1(OMAP_MCBSP_WORD_32); + break; default: /* Unsupported PCM format */ return -EINVAL; @@ -623,13 +643,15 @@ static struct snd_soc_dai_ops omap_mcbsp_dai_ops = { .channels_min = 1, \ .channels_max = 16, \ .rates = OMAP_MCBSP_RATES, \ - .formats = SNDRV_PCM_FMTBIT_S16_LE, \ + .formats = SNDRV_PCM_FMTBIT_S16_LE | \ + SNDRV_PCM_FMTBIT_S32_LE, \ }, \ .capture = { \ .channels_min = 1, \ .channels_max = 16, \ .rates = OMAP_MCBSP_RATES, \ - .formats = SNDRV_PCM_FMTBIT_S16_LE, \ + .formats = SNDRV_PCM_FMTBIT_S16_LE | \ + SNDRV_PCM_FMTBIT_S32_LE, \ }, \ .ops = &omap_mcbsp_dai_ops, \ .private_data = &mcbsp_data[(link_id)].bus_id, \ -- 1.7.0.4

2 2

[alsa-devel] broken microphone
by mutenmaster＠tiscali.it 13 May '10

13 May '10

hello everyone, mi microphone is broken. the os version is the latest, but this bug exists from, 2.6.33 or something. i mailed a message describing the bisection i did back then to vger. Here it is again! $ sudo git bisect bad f5271101faf1655d862849f42518c2a88ef394fb is the first bad commit commit f5271101faf1655d862849f42518c2a88ef394fb Author: Lydia Wang <lydiawang(a)viatech.com.cn> Date: Sat Oct 10 19:07: 35 2009 +0800 ALSA HDA VIA: Add VIA_CTL_WIDGET_ANALOG_MUTE control type Enter low power state if AA-Path volume is muted. Signed-off-by: Lydia Wang <lydiawang(a)viatech.com.cn> Signed-off-by: Logan Li <loganli(a)viatech.com.cn> Signed-off-by: Takashi Iwai <tiwai(a)suse.de> :040000 040000 ab1ae14ff67f0b08848faeb3ad68def7f3e727f0 0bfbfde11fe32e87e8edbdb3c4d03c2d30370393 M sound after reverting this, everything works fine. i already posted a message with all of my system info attached, but it got moderated. If you need any info, please ask. bye, vasilis. Risparmia con Tutto Incluso Light: telefono + adsl 8 mega a soli 14,95 € al mese. Gratis la Sim Tiscali Mobile con 25 euro di traffico! L'offerta è valida solo se attivi entro il 13/05/10 http://abbonati.tiscali.it/telefono-adsl/prodotti/tc/tuttoincluso_light/?WT…

1 0

[alsa-devel] HP dv series mute LED problems?
by Kunal Gangakhedkar 13 May '10

13 May '10

Hi Takashi, The commit 26ebe0a28986f4845b2c5bea43ac5cc0b9f27f0a seems to undo the mute LED gpio fixes - at least on my dv6 series laptop. Maybe, we need to come up with a better solution to accommodate the problem reported in this thread: http://mailman.alsa-project.org/pipermail/alsa-devel/2010-May/027352.html I believe, that's the reason for the commit, right? Let me do a bit more digging. Thanks, Kunal

3 8

[alsa-devel] Use of start_frame in usbusx2yaudio.c
by Sarah Sharp 12 May '10

12 May '10

Are there any drivers in the kernel that set urb->start_frame on every URB? Could those drivers handle it if only the first URB they submitted to the host controller was scheduled for that frame ID, and all the rest of the URBs were scheduled ASAP? I see there are three drivers that set start_frame (while not setting URB_ISO_ASAP): - drivers/isdn/hisax/st5481_d.c - drivers/usb/core/devio.c - sound/usb/usx2y/usbusx2yaudio.c I'm not really sure what usbusx2yaudio.c is doing. I think when one URB completes, it sets the next URB's start_frame to the previous URB's start_frame plus the number of URBs (2 by default) times the number of packets (4 by default). Isn't this basically like setting URB_ISO_ASAP? I really can't tell what fall back method is if this submission fails. What is usbusx2yaudio.c attempting to do? I've tried to get an overall picture of what it expects the isochronous scheduling to look like, but I'm finding the driver a bit hard to read. I'm not too worried about the other two drivers. The code in st5481_d.c seems to fall back fine to URB_ISO_ASAP if the submission with the start_frame set failed. devio.c is usbfs, and I can't tell what userspace drivers do. (It could be argued that if they needed such tight control over isoc, they should have written a kernel driver.) Sarah Sharp

3 3

[alsa-devel] ESI Maya44 PCI – mixer code errors
by Alex Chernyshoff 12 May '10

12 May '10

Hello! In the current release of ESI Maya44 PCI ALSA driver (1.0.23) selection of “Mic In” capture source is impossible. “Microphone” check in the “Switches “ mixer tab actually does not select anything – no recording audio at all, and the Phantom power switch does not perform correctly too. Original, Rainer Zimmermann patch (for ALSA 1.0.19) performs well, but can`t be compiled with the current ALSA and kernel26. Sadly... I've look into current, rewritten, code in the file ./alsa-driver-1.0.23/alsa-kernel/pci/ice1712/maya44.c and found some interesting details. Further, I've add some changes, and “Mic In” selection now works, but only partially. (Below) In the original maya44.c file, from Rainer Zimmermann patch, some definitions of I/O flags seems as a simple mask: #define GPIO_PHANTOM_OFF (1<<2) #define GPIO_MIC_RELAY (1<<4) #define GPIO_SPDIF_IN_INV (1<<5) /* CHECK! */ #define GPIO_MUST_BE_0 (1<<7) Current branch of Maya44 code is rewritten, and these definitions look like the indexes #define GPIO_PHANTOM_OFF 2 #define GPIO_MIC_RELAY 4 #define GPIO_SPDIF_IN_INV 5 #define GPIO_MUST_BE_0 7 So, at the row 396 of the current branch - maya44.c changed = maya_set_gpio_bits(chip->ice, GPIO_MIC_RELAY, sel ? GPIO_MIC_RELAY : 0); I change this code to: changed = maya_set_gpio_bits(chip->ice, (1 << GPIO_MIC_RELAY), sel ? (1 << GPIO_MIC_RELAY) : 0); And finally, at the row 348 of the current maya44.c /* known working input slots (0-4) */ #define MAYA_LINE_IN 1 /* in-2 */ #define MAYA_MIC_IN 4 /* in-5 */ but usable channels are 2 and 4 (from datasheet), therefore I change defines to #define MAYA_LINE_IN 1 /* in-2 */ #define MAYA_MIC_IN 3 /* in-4 */ After that, we can get some usability from mixer. Now, the “Microphone” check can select “Mic In”, and real audio path from microphone to ADC works! But only once. After that, in the “Capture” tab of mixer, “Mute” knob visually change state to muted. Some kind of strange cross influence between mixer tabs :-) Pressing to this “Mute” knob switches back “Mic In” capture source to “Line”, and clear Phantom Power check. (Very strange) And finally, if we check “Microphone” again - “Mic In” became selected again, and “Mute” enter in “unpressed” state again too. But microphone capture became again operable. Circle is closed. Excuse me for some kind of messed story and poor English (my native is Russian), but such description of mixer behavior maybe useful for understanding... I can't resolve more mistakes in the code. Perhaps, author can do it more better than me. I have a hardware – ESI Maya44 PCI audio board installed to working and usable Arch Linux i686 system. I'm ready for testing, and glad to do it! Sincerely Alex Chernyshoff

2 1

[alsa-devel] [patch 0/6] kirkwood openrd client audio support
by apatard＠mandriva.com 12 May '10

12 May '10

This patchset aims at adding ASoC support to ARM kirkwood systems and more precisely to openrd client boards. Arnaud Patard

7 22

[alsa-devel] [PATCH] ASoC: TWL4030: Add control for digimic Left Right swap
by Peter Ujfalusi 12 May '10

12 May '10

The codec has support for swapping the left and right channels in the digimic interface. New kcontrol to handle this bit. Signed-off-by: Peter Ujfalusi <peter.ujfalusi(a)nokia.com> --- sound/soc/codecs/twl4030.c | 12 ++++++++++++ 1 files changed, 12 insertions(+), 0 deletions(-) diff --git a/sound/soc/codecs/twl4030.c b/sound/soc/codecs/twl4030.c index 0fe74d1..6a34f56 100644 --- a/sound/soc/codecs/twl4030.c +++ b/sound/soc/codecs/twl4030.c @@ -1102,6 +1102,16 @@ static const struct soc_enum twl4030_vibradir_enum = ARRAY_SIZE(twl4030_vibradir_texts), twl4030_vibradir_texts); +/* Digimic Left and right swapping */ +static const char *twl4030_digimicswap_texts[] = { + "Not swapped", "Swapped", +}; + +static const struct soc_enum twl4030_digimicswap_enum = + SOC_ENUM_SINGLE(TWL4030_REG_MISC_SET_1, 0, + ARRAY_SIZE(twl4030_digimicswap_texts), + twl4030_digimicswap_texts); + static const struct snd_kcontrol_new twl4030_snd_controls[] = { /* Codec operation mode control */ SOC_ENUM_EXT("Codec Operation Mode", twl4030_op_modes_enum, @@ -1178,6 +1188,8 @@ static const struct snd_kcontrol_new twl4030_snd_controls[] = { SOC_ENUM("Vibra H-bridge mode", twl4030_vibradirmode_enum), SOC_ENUM("Vibra H-bridge direction", twl4030_vibradir_enum), + + SOC_ENUM("Digimic LR Swap", twl4030_digimicswap_enum), }; static const struct snd_soc_dapm_widget twl4030_dapm_widgets[] = { -- 1.7.1

3 2