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

[alsa-devel] snd_pcm_rewind() weirdness
by Lennart Poettering 24 Apr '08

24 Apr '08

Hey! On ALSA 1.0.16 with the HDA driver I am experiencing some weird things with snd_pcm_rewind() which I think are the result of a kernel bug, but I am not sure. Here's what I do to trigger this: I play some PCM. Eventually I want to rewrite what I already have written. I call snd_pcm_hwsync() and then snd_pcm_avail_update() to determine how "empty" the playback buffer is. I subtract that value from the total buffer size. The resulting value should be something resembling the number of frames that I might be able to rewind. I then subtract enough frames to keep away from the playback pointer far enough (50ms, the playback buffer is 370ms, period is 185ms). Now I pass that value to snd_pcm_rewind() and it returns something that is higher than what I passed in. Which I find quite surprising. I had expected that the returned value could be equal or smaller than what I passed in, but never higher! So, my interpretation of the API was apparently wrong. It looks like on HDA the snd_pcm_rewind() parameter is apparently rounded *up* to the next period boundary (which in this case was equivalent to the *entire* buffer)? Of course, rewinding that far immediately caused an XRUN. Which is why I think rounding up in this cases is a bad idea and the API shouldn't work this way. Rounding down is OK, rounding up is call for trouble. To tape over this I added some code to immediately call snd_pcm_forward() with the difference if I noticed that the device forwarded more than I requested. This value also got rounded up -- to twice the period size. So with this backward+forward operation I ended up at a frame index that is farther ahead than where I originally came from! So, what's the expected behaviour of snd_pcm_rewind()? Always round up? What's the rationale behind this? If this is not a bug but expected behaviour, could we at least add something for passing the direction to round to? What I am working on is the "glitch-free" playback model in PulseAudio (http://0pointer.de/blog/projects/pulse-glitch-free.html). To do this I am writing blocks smaller than the period size to the device via the mmap interface all the time. Given that on HDA _rewind() is apparently not granular to the frame size, is writing via mmap in small blocks like that OK? If it's not, how can I learn about this in advance? Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net ICQ# 11060553 http://0pointer.net/lennart/ GnuPG 0x1A015CC4

2 3

[alsa-devel] [RFC/PATCH 0/1] ALSA SoC support for OMAP
by Jarkko Nikula 24 Apr '08

24 Apr '08

Hi Here is the second version of ASoC support for OMAP. Now based to dev branch of git://opensource.wolfsonmicro.com/linux-2.6-asoc but applies to linux-omap by modifying Kconfig and Makefile in sound/soc/. Code hasn't changed a very much. Some minor clean-ups etc and support for OMAP2430 and 3430 is not included until we have updated arch/arm/plat-omap/mcbsp.c module in place supporting them (work in progress). This have the same issues than first version [1] but TODO list is different: - Pin multiplexing: This belongs to .../plat-omap/mcbsp.c, not here - Multiformat & multilink McBSP DAI: ASoC v2 - omap_mcbsp_start & _stop API change: Probably with or after updated mcbsp.c Note that include/asm-arm/arch-omap/control.h is missing from vanilla kernel at the moment but that's queued for 2.6.26. -- Jarkko 1. http://marc.info/?l=linux-omap&m=120643770810683&w=2

3 7

[alsa-devel] [PATCH 01/11] soc - s3c24xx-i2s - Use linux/io.h
by Mark Brown 23 Apr '08

23 Apr '08

Signed-off-by: Mark Brown <broonie(a)opensource.wolfsonmicro.com> --- sound/soc/s3c24xx/s3c24xx-i2s.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/sound/soc/s3c24xx/s3c24xx-i2s.c b/sound/soc/s3c24xx/s3c24xx-i2s.c index 0de211c..c95ebe2 100644 --- a/sound/soc/s3c24xx/s3c24xx-i2s.c +++ b/sound/soc/s3c24xx/s3c24xx-i2s.c @@ -25,6 +25,7 @@ #include <linux/delay.h> #include <linux/clk.h> #include <linux/jiffies.h> +#include <linux/io.h> #include <sound/core.h> #include <sound/pcm.h> #include <sound/pcm_params.h> @@ -32,7 +33,6 @@ #include <sound/soc.h> #include <asm/hardware.h> -#include <asm/io.h> #include <asm/arch/regs-gpio.h> #include <asm/arch/regs-clock.h> #include <asm/arch/audio.h> -- 1.5.5.1

2 15

[alsa-devel] [PATCH 1/5] soc - Support PXA3xx AC97
by Mark Brown 23 Apr '08

23 Apr '08

The PXA3xx does not support the use of interrupts during reset and access to the GPIO status requires similar handling to that for PXA27x. Signed-off-by: Mark Brown <broonie(a)opensource.wolfsonmicro.com> --- sound/soc/pxa/pxa2xx-ac97.c | 29 +++++++++++++++++++++++++++-- 1 files changed, 27 insertions(+), 2 deletions(-) diff --git a/sound/soc/pxa/pxa2xx-ac97.c b/sound/soc/pxa/pxa2xx-ac97.c index 815c153..95ae509 100644 --- a/sound/soc/pxa/pxa2xx-ac97.c +++ b/sound/soc/pxa/pxa2xx-ac97.c @@ -55,7 +55,7 @@ static unsigned short pxa2xx_ac97_read(struct snd_ac97 *ac97, mutex_lock(&car_mutex); /* set up primary or secondary codec/modem space */ -#ifdef CONFIG_PXA27x +#if defined(CONFIG_PXA27x) || defined(CONFIG_PXA3xx) reg_addr = ac97->num ? &SAC_REG_BASE : &PAC_REG_BASE; #else if (reg == AC97_GPIO_STATUS) @@ -105,7 +105,7 @@ static void pxa2xx_ac97_write(struct snd_ac97 *ac97, unsigned short reg, mutex_lock(&car_mutex); /* set up primary or secondary codec/modem space */ -#ifdef CONFIG_PXA27x +#if defined(CONFIG_PXA27x) || defined(CONFIG_PXA3xx) reg_addr = ac97->num ? &SAC_REG_BASE : &PAC_REG_BASE; #else if (reg == AC97_GPIO_STATUS) @@ -128,6 +128,9 @@ static void pxa2xx_ac97_write(struct snd_ac97 *ac97, unsigned short reg, static void pxa2xx_ac97_warm_reset(struct snd_ac97 *ac97) { +#ifdef CONFIG_PXA3xx + int timeout = 100; +#endif gsr_bits = 0; #ifdef CONFIG_PXA27x @@ -138,6 +141,11 @@ static void pxa2xx_ac97_warm_reset(struct snd_ac97 *ac97) GCR |= GCR_WARM_RST; pxa_gpio_mode(113 | GPIO_ALT_FN_2_OUT); udelay(500); +#elif defined(CONFIG_PXA3xx) + /* Can't use interrupts */ + GCR |= GCR_WARM_RST; + while (!((GSR | gsr_bits) & (GSR_PCR | GSR_SCR)) && timeout--) + mdelay(1); #else GCR |= GCR_WARM_RST | GCR_PRIRDY_IEN | GCR_SECRDY_IEN; wait_event_timeout(gsr_wq, gsr_bits & (GSR_PCR | GSR_SCR), 1); @@ -153,6 +161,16 @@ static void pxa2xx_ac97_warm_reset(struct snd_ac97 *ac97) static void pxa2xx_ac97_cold_reset(struct snd_ac97 *ac97) { +#ifdef CONFIG_PXA3xx + int timeout = 1000; + + /* Hold CLKBPB for 100us */ + GCR = 0; + GCR = GCR_CLKBPB; + udelay(100); + GCR = 0; +#endif + GCR &= GCR_COLD_RST; /* clear everything but nCRST */ GCR &= ~GCR_COLD_RST; /* then assert nCRST */ @@ -164,6 +182,13 @@ static void pxa2xx_ac97_cold_reset(struct snd_ac97 *ac97) pxa_set_cken(CKEN_AC97CONF, 0); GCR = GCR_COLD_RST; udelay(50); +#elif defined(CONFIG_PXA3xx) + /* Can't use interrupts on PXA3xx */ + GCR &= ~(GCR_PRIRDY_IEN|GCR_SECRDY_IEN); + + GCR = GCR_WARM_RST | GCR_COLD_RST; + while (!(GSR & (GSR_PCR | GSR_SCR)) && timeout--) + mdelay(10); #else GCR = GCR_COLD_RST; GCR |= GCR_CDONE_IE|GCR_SDONE_IE; -- 1.5.5

4 23

[alsa-devel] Detecting when user is calling himself
by Mathieu Monney 23 Apr '08

23 Apr '08

Hi all I'm trying to figure out how to detect if the user is trying to call himself because it is making some weird unwanted things on my UI when user do this. Any idea? Thank you. Regards, Mathieu Monney

2 1

[alsa-devel] [PATCH 1/3] soc - s3c24xx-i2s - Replace __FUNCTION__ with __func__
by Mark Brown 22 Apr '08

22 Apr '08

__FUNCTION__ is GCC specific and checkpatch won't let us submit with it. Signed-off-by: Mark Brown <broonie(a)opensource.wolfsonmicro.com> --- sound/soc/s3c24xx/s3c24xx-i2s.c | 20 ++++++++++---------- 1 files changed, 10 insertions(+), 10 deletions(-) diff --git a/sound/soc/s3c24xx/s3c24xx-i2s.c b/sound/soc/s3c24xx/s3c24xx-i2s.c index 6b3cbbf..7d38f55 100644 --- a/sound/soc/s3c24xx/s3c24xx-i2s.c +++ b/sound/soc/s3c24xx/s3c24xx-i2s.c @@ -89,7 +89,7 @@ static void s3c24xx_snd_txctrl(int on) u32 iiscon; u32 iismod; - DBG("Entered %s\n", __FUNCTION__); + DBG("Entered %s\n", __func__); iisfcon = readl(s3c24xx_i2s.regs + S3C2410_IISFCON); iiscon = readl(s3c24xx_i2s.regs + S3C2410_IISCON); @@ -134,7 +134,7 @@ static void s3c24xx_snd_rxctrl(int on) u32 iiscon; u32 iismod; - DBG("Entered %s\n", __FUNCTION__); + DBG("Entered %s\n", __func__); iisfcon = readl(s3c24xx_i2s.regs + S3C2410_IISFCON); iiscon = readl(s3c24xx_i2s.regs + S3C2410_IISCON); @@ -182,7 +182,7 @@ static int s3c24xx_snd_lrsync(void) u32 iiscon; int timeout = 50; /* 5ms */ - DBG("Entered %s\n", __FUNCTION__); + DBG("Entered %s\n", __func__); while (1) { iiscon = readl(s3c24xx_i2s.regs + S3C2410_IISCON); @@ -202,7 +202,7 @@ static int s3c24xx_snd_lrsync(void) */ static inline int s3c24xx_snd_is_clkmaster(void) { - DBG("Entered %s\n", __FUNCTION__); + DBG("Entered %s\n", __func__); return (readl(s3c24xx_i2s.regs + S3C2410_IISMOD) & S3C2410_IISMOD_SLAVE) ? 0:1; } @@ -215,7 +215,7 @@ static int s3c24xx_i2s_set_fmt(struct snd_soc_cpu_dai *cpu_dai, { u32 iismod; - DBG("Entered %s\n", __FUNCTION__); + DBG("Entered %s\n", __func__); iismod = readl(s3c24xx_i2s.regs + S3C2410_IISMOD); DBG("hw_params r: IISMOD: %lx \n", iismod); @@ -251,7 +251,7 @@ static int s3c24xx_i2s_hw_params(struct snd_pcm_substream *substream, struct snd_soc_pcm_runtime *rtd = substream->private_data; u32 iismod; - DBG("Entered %s\n", __FUNCTION__); + DBG("Entered %s\n", __func__); if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) rtd->dai->cpu_dai->dma_data = &s3c24xx_i2s_pcm_stereo_out; @@ -279,7 +279,7 @@ static int s3c24xx_i2s_trigger(struct snd_pcm_substream *substream, int cmd) { int ret = 0; - DBG("Entered %s\n", __FUNCTION__); + DBG("Entered %s\n", __func__); switch (cmd) { case SNDRV_PCM_TRIGGER_START: @@ -321,7 +321,7 @@ static int s3c24xx_i2s_set_sysclk(struct snd_soc_cpu_dai *cpu_dai, { u32 iismod = readl(s3c24xx_i2s.regs + S3C2410_IISMOD); - DBG("Entered %s\n", __FUNCTION__); + DBG("Entered %s\n", __func__); iismod &= ~S3C2440_IISMOD_MPLL; @@ -347,7 +347,7 @@ static int s3c24xx_i2s_set_clkdiv(struct snd_soc_cpu_dai *cpu_dai, { u32 reg; - DBG("Entered %s\n", __FUNCTION__); + DBG("Entered %s\n", __func__); switch (div_id) { case S3C24XX_DIV_BCLK: @@ -382,7 +382,7 @@ EXPORT_SYMBOL_GPL(s3c24xx_i2s_get_clockrate); static int s3c24xx_i2s_probe(struct platform_device *pdev) { - DBG("Entered %s\n", __FUNCTION__); + DBG("Entered %s\n", __func__); s3c24xx_i2s.regs = ioremap(S3C2410_PA_IIS, 0x100); if (s3c24xx_i2s.regs == NULL) -- 1.5.5

2 3

[alsa-devel] envy24control can't set sample rate on Delta 1010
by John Rigg 22 Apr '08

22 Apr '08

envy24control in alsa-tools-1.0.16 cannot set sample rate on the M-Audio Delta 1010. The Actual Rate window appears to be functioning correctly, as is the "S/PDIF in" button, but none of the internal clock sample rate buttons do anything. Setting the sample rate as a jackd parameter works as normal. I tried it with 2.6.20 and 2.6.25 kernels. Behaviour was the same on both. I've made a bug report (0003915). John

2 4

Re: [alsa-devel] [PATCH] asoc tlv320aic3x: add GPIO support
by Daniel Mack 22 Apr '08

22 Apr '08

On Fri, Apr 18, 2008 at 11:26:28PM +0300, Jarkko Nikula wrote: > No any show stopper either but I just started to think about gpiolib if > AIC3x GPIOs are used as a GPIO. I agree in general and thought about alternatives as well, but in this case, it turns out to be a thing the aic3x driver is responsible to as the registers in questions are purely in its scope. So the idea is to set up the GPIO's functions via alsa controls and handle its events in some board-related code as this is really not abstractable. One could, however, do this setup in machine-related code within the asoc environment. My changes don't cast any problems on the existing implementation either, so I would suggest to just take this patch until someone comes up with a more suitable solution :) Best regards, Daniel

4 11

[alsa-devel] [PATCH] ALSA: Fix capturing for envy1724ht based "audiophile 192"
by Karsten Wiese 22 Apr '08

22 Apr '08

The 1st hunk changes snd_ice1712_gpio_write_bits() to not affect the gpio's mask register. Lets gpio writers that are unaware of a changed mask register successfully write the gpio. The 2nd and 3rd hunks toggle "chip reset" and "eeprom based setup" sequence so "chip reset" becomes first. Increasement of the "chip reset" related timeout leads to correctly read eeprom's contents here. Also corrects some arguments in calls to snd_ice1712_gpio_write_bits() from ap192_set_rate_val(). Signed-off-by: Karsten Wiese <fzu(a)wemgehoertderstaat.de> --- Hi, patch might hamper cards that actually relied on snd_ice1712_gpio_write_bits() setting the gpio's mask register. Cscope tells me terratec ews and m-audio rev51 are might be candidates. I guess they are ok ;-) regards, Karsten diff -pur alsa.hg/alsa-kernel/pci/ice1712/ice1712.h fixed/alsa-kernel/pci/ice1712/ice1712.h --- alsa.hg/alsa-kernel/pci/ice1712/ice1712.h 2008-03-20 12:25:01.000000000 +0100 +++ fixed/alsa-kernel/pci/ice1712/ice1712.h 2008-04-19 23:21:31.000000000 +0200 @@ -438,10 +438,14 @@ int snd_ice1712_gpio_put(struct snd_kcon static inline void snd_ice1712_gpio_write_bits(struct snd_ice1712 *ice, unsigned int mask, unsigned int bits) { + unsigned val; + ice->gpio.direction |= mask; snd_ice1712_gpio_set_dir(ice, ice->gpio.direction); - snd_ice1712_gpio_set_mask(ice, ~mask); - snd_ice1712_gpio_write(ice, mask & bits); + val = snd_ice1712_gpio_read(ice); + val &= ~mask; + val |= mask & bits; + snd_ice1712_gpio_write(ice, val); } static inline int snd_ice1712_gpio_read_bits(struct snd_ice1712 *ice, diff -pur alsa.hg/alsa-kernel/pci/ice1712/ice1724.c fixed/alsa-kernel/pci/ice1712/ice1724.c --- alsa.hg/alsa-kernel/pci/ice1712/ice1724.c 2008-03-20 12:25:01.000000000 +0100 +++ fixed/alsa-kernel/pci/ice1712/ice1724.c 2008-04-19 23:07:29.000000000 +0200 @@ -2045,12 +2045,16 @@ static int __devinit snd_vt1724_read_eep -static int __devinit snd_vt1724_chip_init(struct snd_ice1712 *ice) +static void __devinit snd_vt1724_chip_reset(struct snd_ice1712 *ice) { outb(VT1724_RESET , ICEREG1724(ice, CONTROL)); - udelay(200); + msleep(10); outb(0, ICEREG1724(ice, CONTROL)); - udelay(200); + msleep(10); +} + +static int __devinit snd_vt1724_chip_init(struct snd_ice1712 *ice) +{ outb(ice->eeprom.data[ICE_EEP2_SYSCONF], ICEREG1724(ice, SYS_CFG)); outb(ice->eeprom.data[ICE_EEP2_ACLINK], ICEREG1724(ice, AC97_CFG)); outb(ice->eeprom.data[ICE_EEP2_I2S], ICEREG1724(ice, I2S_FEATURES)); @@ -2223,6 +2227,7 @@ static int __devinit snd_vt1724_create(s ice->irq = pci->irq; + snd_vt1724_chip_reset(ice); if (snd_vt1724_read_eeprom(ice, modelname) < 0) { snd_vt1724_free(ice); return -EIO; diff -pur alsa.hg/alsa-kernel/pci/ice1712/revo.c fixed/alsa-kernel/pci/ice1712/revo.c --- alsa.hg/alsa-kernel/pci/ice1712/revo.c 2008-03-17 09:25:02.000000000 +0100 +++ fixed/alsa-kernel/pci/ice1712/revo.c 2008-04-19 23:12:33.000000000 +0200 @@ -327,7 +327,7 @@ static void ap192_set_rate_val(struct sn revo_set_rate_val(ak, rate); /* reset CKS */ - snd_ice1712_gpio_write_bits(ice, 1 << 8, rate > 96000 ? 1 : 0); + snd_ice1712_gpio_write_bits(ice, 1 << 8, rate > 96000 ? 1 << 8 : 0); /* reset DFS pins of AK5385A for ADC, too */ if (rate > 96000) dfs = 2; @@ -338,7 +338,7 @@ static void ap192_set_rate_val(struct sn snd_ice1712_gpio_write_bits(ice, 3 << 9, dfs << 9); /* reset ADC */ snd_ice1712_gpio_write_bits(ice, 1 << 11, 0); - snd_ice1712_gpio_write_bits(ice, 1 << 11, 1); + snd_ice1712_gpio_write_bits(ice, 1 << 11, 1 << 11); } static const struct snd_akm4xxx_dac_channel ap192_dac[] = {

2 6

Re: [alsa-devel] snd_pcm_ops - .copy
by Harsha priya gupta 22 Apr '08

22 Apr '08

On Tue, Apr 22, 2008 at 8:07 AM, Harsha priya gupta <harshapriya(a)gmail.com> wrote: > I am not using the mmap method. How can i make sure that everytime a user > buffer is passed to driver, my copy function would be called? > > > On Mon, Apr 21, 2008 at 9:30 PM, Takashi Iwai <tiwai(a)suse.de> wrote: > > > At Mon, 21 Apr 2008 19:27:45 +0530, > > Harsha priya gupta wrote: > > > > > > Hi, > > > I am trying to implement the .copy function of playack_ops in my > > driver. But > > > when I try playing an mp3 file, my .copy's function code path was > > executing. > > > Suddenly I do not see that function being called. Can anyone help me > > > understand when the following code path will be executed > > > > > > snd_pcm_lib_write_transfer > > > substream->ops->copy > > > > Do you use a mmap method? If so, the copy callback won't be called. > > The copy callback is only for copying the data from the user-space > > buffer to the driver buffer, which is skipped via mmap. > > > > > > Takashi > > > > > > -- > -Harsha -- -Harsha

1 0