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

Re: [alsa-devel] [PATCH] ASoC: Remove unreachable code in au1xac97c_drvprobe and au1xi2s_drvprobe
by Mark Brown 17 Aug '11

17 Aug '11

On Wed, Aug 17, 2011 at 03:14:33PM +0800, Axel Lin wrote: > Signed-off-by: Axel Lin <axel.lin(a)gmail.com> Applied, thanks.

1 0

[alsa-devel] [PATCH] ASoC: Fix check for symmetric rate enforcement
by Sascha Hauer 17 Aug '11

17 Aug '11

The ASoC core tries to not enforce symmetric rates when two streams open simultaneously. It does so by checking rtd->rate being zero. This works exactly once after booting because it is not set to zero again when the streams close. Fix this by clearing rtd->rate when no active stream is left. Signed-off-by: Sascha Hauer <s.hauer(a)pengutronix.de> --- sound/soc/soc-core.c | 3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/sound/soc/soc-core.c b/sound/soc/soc-core.c index d75043e..c25649a 100644 --- a/sound/soc/soc-core.c +++ b/sound/soc/soc-core.c @@ -746,6 +746,9 @@ static int soc_codec_close(struct snd_pcm_substream *substream) codec_dai->active--; codec->active--; + if (!cpu_dai->active && !codec_dai->active) + rtd->rate = 0; + /* Muting the DAC suppresses artifacts caused during digital * shutdown, for example from stopping clocks. */ -- 1.7.5.4 -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |

2 6

[alsa-devel] [PATCH] ASoC: fsl: fix build warning in fsl_dma
by Timur Tabi 17 Aug '11

17 Aug '11

The previous patch to fsl_dma.c ("fix initialization of DMA buffers") left behind an unused local variable that causes a build warning. Signed-off-by: Timur Tabi <timur(a)freescale.com> --- sound/soc/fsl/fsl_dma.c | 1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/sound/soc/fsl/fsl_dma.c b/sound/soc/fsl/fsl_dma.c index 732208c..0efc04a 100644 --- a/sound/soc/fsl/fsl_dma.c +++ b/sound/soc/fsl/fsl_dma.c @@ -297,7 +297,6 @@ static irqreturn_t fsl_dma_isr(int irq, void *dev_id) static int fsl_dma_new(struct snd_soc_pcm_runtime *rtd) { struct snd_card *card = rtd->card->snd_card; - struct snd_soc_dai *dai = rtd->cpu_dai; struct snd_pcm *pcm = rtd->pcm; static u64 fsl_dma_dmamask = DMA_BIT_MASK(36); int ret; -- 1.7.4.4

2 1

Re: [alsa-devel] USB Audio questions
by Torsten Schenk 17 Aug '11

17 Aug '11

Hi Pierre, I also spent some time learning about USB and audio while developing the sound/usb/6fire driver. I made the following discoveries: >What I had in mind is a case where the ring buffer is divided in separate >periods, which would each correspond to an integer number of URBs/packets. >This way there is _never_ a case of wrap-around and no need for memcpys. >It's probably less generic than the current driver but a whole lot >simpler/efficient. I was also not very happy to implement the double buffering with memcpy's. But from the experience with the 6fire device I can say this: - The device/driver sends per urb a constant number of packets (as you already also discovered). The number of samples per packet differ however (+- 1 sample per packet). I accuse the asynchronousity between the urb interval and the sound card's internal clock for this fact. The device expects the driver to send back an urb with exactly the same structure. The device produced crackling noise if the samples per packet were not equal. I cannot say to what extend this is true (i.e. if you could wait some packets until catching up the difference without producing crackles) but due to this fact it's at least not a simple task to send urbs exactly corresponding to the period limit. - Another thing came into my mind while reading your post, but I'm not sure if that would apply in praxis: If sending an urb is scheduled with the alsa buffer, it might be possible that the buffer is overwritten before the urb is sent, leading to complete audio-rubbish. - And: at least the 6fire requires a header for each packet, which couldn't be placed directly in the alsa buffer. But perhaps this doesn't apply to most cards. Greets, Torsten

3 2

[alsa-devel] WM8727 & AT91SAM9G45: not enough memory
by conn intel 17 Aug '11

17 Aug '11

Dear Friends, I am using WM8727 codec with AT91SAM9G45 processor. I have implemented machine code as http://pastebin.com/axadqGhd . After insterting the module I got following output: # insmod sam9g45_wm8727.ko atmel-pcm:preallocate_dma_buffer: area=ffadf000, addr=77c40000, size=32768 asoc: WM8727 <-> atmel-ssc0 mapping ok I am getting following error when I tried to play the wav file using command "aplay -D default sample_16.wav ": atmel_ssc_startup: SSC_SR=0x192 Playing WAVE 'sample_16.wav' : Signed 16 bit Little Endian, Rate 44100 Hz, Stereo atmel_ssc_hw_params: RCMR=00010721 RFMR=0000008f TCMR=00010702 TFMR=0000008f atmel_ssc_dai: Starting clock atmel_ssc_dai,hw_params: SSC initialized atmel-pcm: hw_params: DMA for SSC0 PCM out initialized (dma_bytes=32768, period_size=8192) transmit enabled SSC_SR=0x000104c3 aplayatmel_ssc_shutdown: transmit disabled SSC_SR=0x000000c3 :atmel_ssc_dau: Stopping clock set_params:1167: not enough memory Does anyone throw some light where and how to solve the issue? Kindly share if one needs further information. Have a Good Day, Thank you, Ankur.

2 2

[alsa-devel] [PATCH] ASoC: Fix backport of WM8994 thermal warning
by Mark Brown 17 Aug '11

17 Aug '11

Signed-off-by: Mark Brown <broonie(a)opensource.wolfsonmicro.com> Reported-by: Stephen Rothwell <sfr(a)canb.auug.org.au> --- sound/soc/codecs/wm8994.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/sound/soc/codecs/wm8994.c b/sound/soc/codecs/wm8994.c index 9412491..e537267 100644 --- a/sound/soc/codecs/wm8994.c +++ b/sound/soc/codecs/wm8994.c @@ -3141,9 +3141,9 @@ static int wm8994_codec_probe(struct snd_soc_codec *codec) wm8994_request_irq(codec->control_data, WM8994_IRQ_FIFOS_ERR, wm8994_fifo_error, "FIFO error", codec); - wm8994_request_irq(wm8994->wm8994, WM8994_IRQ_TEMP_WARN, + wm8994_request_irq(wm8994->control_data, WM8994_IRQ_TEMP_WARN, wm8994_temp_warn, "Thermal warning", codec); - wm8994_request_irq(wm8994->wm8994, WM8994_IRQ_TEMP_SHUT, + wm8994_request_irq(wm8994->control_data, WM8994_IRQ_TEMP_SHUT, wm8994_temp_shut, "Thermal shutdown", codec); ret = wm8994_request_irq(codec->control_data, WM8994_IRQ_DCS_DONE, -- 1.7.5.4

1 0

[alsa-devel] Playback PCM drain and card fifos
by Eliot Blennerhassett 17 Aug '11

17 Aug '11

Greetings, I am seeing playback audio get truncated at the end of playback. The amount lost is about what is in the on-card fifo. (asihpi driver) For example in a specific test this is about 100ms of audio, though in theory could go much higher if I let the card fifo fill completely. The current driver calls snd_pcm_period_elapsed when the card has read from the alsa ringbuffer. I.e. it is notifying that the buffer is available for more data to be written. As soon as the driver notifies that the final data has been read by the card, the trigger stop is called, which in turn stops the card playback immediately. However, the data just read has not been played back yet so the audio is truncated. During playback the driver sets runtime->delay = on_card_bytes I'm trying to work out what I can do in the driver (or in alsa mid layer if necessary), to make this work better? regards -- Eliot Blennerhassett AudioScience Inc.

1 0

[alsa-devel] [PATCH] [v2] ASoC: claim the IRQ when the fsl_ssi device is probed, not opened
by Timur Tabi 17 Aug '11

17 Aug '11

The PowerPC Freescale SSI driver is claiming the IRQ when the IRQ when the device is opened, which means that the /proc/interrupts entry for the SSI exists only during playback or capture. This also meant that the user won't know that the IRQ number is wrong until he tries to use the device. Instead, we should claim the IRQ when the device is probed. Signed-off-by: Timur Tabi <timur(a)freescale.com> --- sound/soc/fsl/fsl_ssi.c | 61 ++++++++++++++++++++++++++++------------------ 1 files changed, 37 insertions(+), 24 deletions(-) diff --git a/sound/soc/fsl/fsl_ssi.c b/sound/soc/fsl/fsl_ssi.c index d48afea..06ac2b9 100644 --- a/sound/soc/fsl/fsl_ssi.c +++ b/sound/soc/fsl/fsl_ssi.c @@ -289,16 +289,6 @@ static int fsl_ssi_startup(struct snd_pcm_substream *substream, */ if (!ssi_private->playback && !ssi_private->capture) { struct ccsr_ssi __iomem *ssi = ssi_private->ssi; - int ret; - - /* The 'name' should not have any slashes in it. */ - ret = request_irq(ssi_private->irq, fsl_ssi_isr, 0, - ssi_private->name, ssi_private); - if (ret < 0) { - dev_err(substream->pcm->card->dev, - "could not claim irq %u\n", ssi_private->irq); - return ret; - } /* * Section 16.5 of the MPC8610 reference manual says that the @@ -522,15 +512,12 @@ static void fsl_ssi_shutdown(struct snd_pcm_substream *substream, ssi_private->second_stream = NULL; /* - * If this is the last active substream, disable the SSI and release - * the IRQ. + * If this is the last active substream, disable the SSI. */ if (!ssi_private->playback && !ssi_private->capture) { struct ccsr_ssi __iomem *ssi = ssi_private->ssi; clrbits32(&ssi->scr, CCSR_SSI_SCR_SSIEN); - - free_irq(ssi_private->irq, ssi_private); } } @@ -675,17 +662,30 @@ static int __devinit fsl_ssi_probe(struct platform_device *pdev) ret = of_address_to_resource(np, 0, &res); if (ret) { dev_err(&pdev->dev, "could not determine device resources\n"); - kfree(ssi_private); - return ret; + goto error_kmalloc; } ssi_private->ssi = of_iomap(np, 0); if (!ssi_private->ssi) { dev_err(&pdev->dev, "could not map device resources\n"); - kfree(ssi_private); - return -ENOMEM; + ret = -ENOMEM; + goto error_kmalloc; } ssi_private->ssi_phys = res.start; + ssi_private->irq = irq_of_parse_and_map(np, 0); + if (ssi_private->irq == NO_IRQ) { + dev_err(&pdev->dev, "no irq for node %s\n", np->full_name); + ret = -ENXIO; + goto error_iomap; + } + + /* The 'name' should not have any slashes in it. */ + ret = request_irq(ssi_private->irq, fsl_ssi_isr, 0, ssi_private->name, + ssi_private); + if (ret < 0) { + dev_err(&pdev->dev, "could not claim irq %u\n", ssi_private->irq); + goto error_irqmap; + } /* Are the RX and the TX clocks locked? */ if (of_find_property(np, "fsl,ssi-asynchronous", NULL)) @@ -711,7 +711,7 @@ static int __devinit fsl_ssi_probe(struct platform_device *pdev) if (ret) { dev_err(&pdev->dev, "could not create sysfs %s file\n", ssi_private->dev_attr.attr.name); - goto error; + goto error_irq; } /* Register with ASoC */ @@ -720,7 +720,7 @@ static int __devinit fsl_ssi_probe(struct platform_device *pdev) ret = snd_soc_register_dai(&pdev->dev, &ssi_private->cpu_dai_drv); if (ret) { dev_err(&pdev->dev, "failed to register DAI: %d\n", ret); - goto error; + goto error_dev; } /* Trigger the machine driver's probe function. The platform driver @@ -741,18 +741,28 @@ static int __devinit fsl_ssi_probe(struct platform_device *pdev) if (IS_ERR(ssi_private->pdev)) { ret = PTR_ERR(ssi_private->pdev); dev_err(&pdev->dev, "failed to register platform: %d\n", ret); - goto error; + goto error_dai; } return 0; -error: +error_dai: snd_soc_unregister_dai(&pdev->dev); + +error_dev: dev_set_drvdata(&pdev->dev, NULL); - if (dev_attr) - device_remove_file(&pdev->dev, dev_attr); + device_remove_file(&pdev->dev, dev_attr); + +error_irq: + free_irq(ssi_private->irq, ssi_private); + +error_irqmap: irq_dispose_mapping(ssi_private->irq); + +error_iomap: iounmap(ssi_private->ssi); + +error_kmalloc: kfree(ssi_private); return ret; @@ -766,6 +776,9 @@ static int fsl_ssi_remove(struct platform_device *pdev) snd_soc_unregister_dai(&pdev->dev); device_remove_file(&pdev->dev, &ssi_private->dev_attr); + free_irq(ssi_private->irq, ssi_private); + irq_dispose_mapping(ssi_private->irq); + kfree(ssi_private); dev_set_drvdata(&pdev->dev, NULL); -- 1.7.4.4

2 1

[alsa-devel] [PATCH] ASoC: claim the IRQ when the fsl_ssi device is probed, not opened
by Timur Tabi 17 Aug '11

17 Aug '11

The PowerPC Freescale SSI driver is claiming the IRQ when the IRQ when the device is opened, which means that the /proc/interrupts entry for the SSI exists only during playback or capture. This also meant that the user won't know that the IRQ number is wrong until he tries to use the device. Instead, we should claim the IRQ when the device is probed. Signed-off-by: Timur Tabi <timur(a)freescale.com> --- arch/powerpc/configs/mpc85xx_defconfig | 1 + arch/powerpc/configs/mpc85xx_smp_defconfig | 1 + 2 files changed, 2 insertions(+), 0 deletions(-) diff --git a/arch/powerpc/configs/mpc85xx_defconfig b/arch/powerpc/configs/mpc85xx_defconfig index fcd85d2..a3467bf 100644 --- a/arch/powerpc/configs/mpc85xx_defconfig +++ b/arch/powerpc/configs/mpc85xx_defconfig @@ -139,6 +139,7 @@ CONFIG_SND=y CONFIG_SND_INTEL8X0=y # CONFIG_SND_PPC is not set # CONFIG_SND_USB is not set +CONFIG_SND_SOC=y CONFIG_HID_A4TECH=y CONFIG_HID_APPLE=y CONFIG_HID_BELKIN=y diff --git a/arch/powerpc/configs/mpc85xx_smp_defconfig b/arch/powerpc/configs/mpc85xx_smp_defconfig index 908c941..9693f6e 100644 --- a/arch/powerpc/configs/mpc85xx_smp_defconfig +++ b/arch/powerpc/configs/mpc85xx_smp_defconfig @@ -140,6 +140,7 @@ CONFIG_SND=y CONFIG_SND_INTEL8X0=y # CONFIG_SND_PPC is not set # CONFIG_SND_USB is not set +CONFIG_SND_SOC=y CONFIG_HID_A4TECH=y CONFIG_HID_APPLE=y CONFIG_HID_BELKIN=y -- 1.7.4.4

2 1

Re: [alsa-devel] USB Audio questions
by Torsten Schenk 17 Aug '11

17 Aug '11

> Thanks for sharing your experience. > > > - The device/driver sends per urb a constant number of packets (as you > > already also discovered). The number of samples per packet differ > > however (+- 1 sample per packet). I accuse the asynchronousity between > > the urb interval and the sound card's internal clock for this fact. The > > device expects the driver to send back an urb with exactly the same > > structure. The device produced crackling noise if the samples per > > packet were not equal. I cannot say to what extend this is true (i.e. > > if you could wait some packets until catching up the difference without > > producing crackles) but due to this fact it's at least not a simple > > task to send urbs exactly corresponding to the period limit. > > I am still unclear on what makes the number of samples per packet vary, I > didn't see this in the code. I understand that it could vary for 44.1 but > for 48kHz (my case) I'd think it should be constant. The variation is not directly in the code. I remember that the caiaq driver enlightened me since this behaviour is commented there. The variation comes from the device and these steps lead to this variation: 1. the driver sends n urbs containing m packets with size 0 (i.e. no audio) to the device 2. the device sends back each of the n urbs one-by-one, filled with the captured audio; the urbs will contain m packets, each packet having an individual number of samples s_p ("sample" being defined here as: 1 sample contains one value for each channel) 3. for each urb returned from the device, the driver sends another urb containing again m packets, but this time with s_p samples per packet (corresponding to the packet-dependent s_p received from the device) I indeed found out that when using 48kHz, I first thought that the number of samples per packet were identical every time. When using this heuristic, crackling noise occured in the sound output and I looked at the number of samples per packet. They varied not very often but sometimes - around once per 2 seconds. My explanation for this problem is, that the sound card has its own clock, that will not oscillate at exactly an integer multiple as the computer's/usb's internal clock. Even temperature will change the frequency a little bit, meaning that 48kHz is not always exactly 48kHz. I would have to start speculating about which clock drives the usb urb scheduling, so this question should be left for the more experienced USB programmers. > > > - Another thing came into my mind while reading your post, but I'm not > > sure if that would apply in praxis: If sending an urb is scheduled with > > the alsa buffer, it might be possible that the buffer is overwritten > > before the urb is sent, leading to complete audio-rubbish. > > Indeed there could be some issues with pulseaudio rewinds, but the fact is > that rewinds are broken anyway when the data is copied... I gave this another thought and came to the conclusion: if you'd call snd_pcm_period_elapsed in the output urb retire callback, the theoretical problem wouldn't occur. Torsten

1 0