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

[alsa-devel] [RFC] ALSA vs. dedicated char device for a USB Audio Class gadget driver
by Laurent Pinchart 14 May '09

14 May '09

Hi everybody. Linux provides a USB Audio Class (UAC) driver on the USB host side, but a UAC gadget driver on the USB device side is currently missing. Considering plugging in this hole, I'm looking at userspace <-> kernelspace APIs. In a nutshell (let's consider recording, where the device appears to the host as a USB microphone), the kernel driver needs to be fed with audio data from a userspace application and stream those data on USB. Audio data can come from a real microphone (through an ALSA driver), a file, a network socket, ... the driver will not care. I need an API to transfer audio data from userspace to kernelspace. I initially thought about ALSA, but it turns out some assumptions made by ALSA are not fulfilled by my system. One of the most serious problems is that the UAC gadget driver doesn't have any audio clock. The only hardware clock available is the USB device controller interrupts generated at the USB transfer rate, and those are much faster than the audio sample rate. This will cause buffer underruns that I need to handle. I can thing of 3 solutions to solve this issue, and I'd like your opinion on them. 1. Get the userspace application to provide a clock to the driver. This could be done by writing to a /proc file, a special char device, or even by adding an ioctl to ALSA. Every time the driver receives a clock tick it would transfer one period of data. 2. Find out how much data is available in the ALSA ring buffer. I could then throttle USB interrupts when no data is available in the buffer and try again later. ALSA maintains a read and a write pointer (hw_ptr and appl_ptr) that can be accessed through the snd_pcm_*_avail() functions. However, I'm not sure how to handle proper locking, and I don't understand how runtime->boundary interacts with those functions. I've also heard that there's a free-running mode that will make those functions return bogus values. I'd appreciate help on this. 3. Use another API (dedicated character device, socket, ...) to transfer audio data from userspace to kernelspace. ALSA is way too big for my requirements (2 layers of abstraction, architectured around assumptions that make sense for real sound cards but not for my hardware, ...). On the other hand, it would be handy to use existing ALSA applications to driver the device. I'd appreciate comments regarding the API choice. How do you all expect to push data from a userspace application to a UAC driver on the device side ? If ALSA is *the* way, is one of the above solutions practical or is there a better way ? Best regards, Laurent Pinchart

1 0

[alsa-devel] [PATCH] keywest: Get rid of useless i2c_device_name() macro
by Jean Delvare 14 May '09

14 May '09

The i2c_device_name() macro is used only once and doesn't have much value, it hurts redability more than it helps. Get rid of it. Signed-off-by: Jean Delvare <khali(a)linux-fr.org> Cc: Benjamin Herrenschmidt <benh(a)kernel.crashing.org> --- sound/ppc/keywest.c | 6 +----- 1 file changed, 1 insertion(+), 5 deletions(-) --- linux-2.6.30-rc1.orig/sound/ppc/keywest.c 2009-04-10 16:22:08.000000000 +0200 +++ linux-2.6.30-rc1/sound/ppc/keywest.c 2009-04-10 16:25:16.000000000 +0200 @@ -33,10 +33,6 @@ static struct pmac_keywest *keywest_ctx; -#ifndef i2c_device_name -#define i2c_device_name(x) ((x)->name) -#endif - static int keywest_probe(struct i2c_client *client, const struct i2c_device_id *id) { @@ -56,7 +52,7 @@ static int keywest_attach_adapter(struct if (! keywest_ctx) return -EINVAL; - if (strncmp(i2c_device_name(adapter), "mac-io", 6)) + if (strncmp(adapter->name, "mac-io", 6)) return 0; /* ignored */ memset(&info, 0, sizeof(struct i2c_board_info)); -- Jean Delvare

2 1

[alsa-devel] AC97 reset fail after suspend
by Tomas 'Sleep_Walker' Cech 14 May '09

14 May '09

Hi, I've got following error on Palm LifeDrive and PalmTX after suspend & resume: pxa2xx_ac97_try_warm_reset: warm reset timeout (GSR=0x0) pxa2xx_ac97_read: read error (ac97_reg=0 GSR=0x0) pxa2xx_ac97_try_cold_reset: cold reset timeout (GSR=0x44) pxa2xx_ac97_read: read error (ac97_reg=0 GSR=0x44) WM9712 AC97 reset failed could not reset AC97 codec That completely disable whole AC97 communication, so touchscreen, sound and battery doesn't work any longer. I also tried this with Treo680 (code will be sent soon). HW is very similar, only codec is different - LD/T5/TX use WM9712, Treo680 use WM9713. On Treo680 there is no problem with that. Thanks for any hint about that. Tomas 'Sleep_Walker' Cech Attaching config for LD/TX and dmesg output.

4 10

[alsa-devel] DMA over run on playback
by Jon Smirl 14 May '09

14 May '09

There's a long thread over on the pulse list about glitch free playback. The glitches they are encountering are caused by CPU scheduling latency. They are trying to fix this by setting HZ up to 1000 and constantly polling the audio DMA queue to keep it 99% full. This doesn't seem like the right solution to me. It is fixing the symptom not the cause. The cause is 200-300ms scheduling latency. The source of that needs to be tracked down and fixed in the kernel. But we have to live with the latencies until they are fixed. The strategy of checking the queue at 1000Hz works but it is very inefficient. The underlying problem is that the buffer ALSA is using is too small on systems with 300ms latency. The buffer is just big enough to cover 300ms so they rapidly check and fill it at 1000Hz to ensure that it is full if the 300ms latency strikes. On my hardware with period interrupts ALSA is only checking the buffer at 8Hz. Since I'm checking appl_ptr I know when DMA over runs the buffers. This allows me to insert silence and I could indicated this condition to ALSA if there was a mechanism for doing so. ALSA could use this over run knowledge to measure scheduling latency and adjust the buffering. But the DMA interface between ALSA and the driver has been fixed at stream creation time. There's no way to dynamically alter it (like window size changes in TCP/IP). With networking you get a list of buffers to send. As you send these buffers you mark them sent. The core is free to hand you buffers straight from user space or do copies and use internal ring buffers. The network driver just gets a list of physical addresses to send. This buffer bookkeeping could occur in snd_pcm_period_elapsed(). A dynamic chaining mechanism allows you to alter the buffering mid-stream. If the driver indication a DMA over run error this tells ALSA that it needs to insert another buffer. After a while these errors will stop and ALSA will have measured worst case CPU scheduling latency. From then on it will know the exact size of buffering needed for the kernel it it running on and it can use this knowledge at stream creation time. Now filling the buffer at 8Hz or lower will work and you don't have to spend the power associated with 1000Hz timer interrupts. -- Jon Smirl jonsmirl(a)gmail.com

4 10

[alsa-devel] [PATCH 1/4 v2] pxa2xx-i2s: Proper hw initialization
by Karl Beldan 14 May '09

14 May '09

Make sure we are in a know good state at end of probe : Reset FIFO logic and registers, and make sure REC and RPL functions along with FIFO service are disabled (SACR0_RST enables REC and RPL). Resetting loses current settings so remove reset from stream startup. Now reset occurs only at probe. Signed-off-by: Karl Beldan <karl.beldan(a)mobile-devices.fr> --- sound/soc/pxa/pxa2xx-i2s.c | 17 ++++++++++++++--- 1 files changed, 14 insertions(+), 3 deletions(-) diff --git a/sound/soc/pxa/pxa2xx-i2s.c b/sound/soc/pxa/pxa2xx-i2s.c index 2f4b6e4..59cc4f5 100644 --- a/sound/soc/pxa/pxa2xx-i2s.c +++ b/sound/soc/pxa/pxa2xx-i2s.c @@ -106,10 +106,8 @@ static int pxa2xx_i2s_startup(struct snd_pcm_substream *substream, if (IS_ERR(clk_i2s)) return PTR_ERR(clk_i2s); - if (!cpu_dai->active) { - SACR0 |= SACR0_RST; + if (!cpu_dai->active) SACR0 = 0; - } return 0; } @@ -346,6 +344,19 @@ static int pxa2xx_i2s_probe(struct platform_device *dev) if (ret != 0) clk_put(clk_i2s); + /* + * PXA Developer's Manual: + * If SACR0[ENB] is toggled in the middle of a normal operation, + * the SACR0[RST] bit must also be set and cleared to reset all + * I2S controller registers. + */ + SACR0 = SACR0_RST; + SACR0 = 0; + /* Make sure RPL and REC are disabled */ + SACR1 = SACR1_DRPL | SACR1_DREC; + /* Along with FIFO servicing */ + SAIMR &= ~(SAIMR_RFS | SAIMR_TFS); + return ret; } -- 1.6.3.rc1.34.g0be9b -- Karl

2 2

[alsa-devel] [PATCH] riptide: postfix increment and off by one
by Roel Kluin 14 May '09

14 May '09

With a postfix increment these variables are incremented beyond CMDIF_TIMEOUT / MAX_WRITE_RETRY. Signed-off-by: Roel Kluin <roel.kluin(a)gmail.com> --- diff --git a/sound/pci/riptide/riptide.c b/sound/pci/riptide/riptide.c index 6f10344..e51a5ef 100644 --- a/sound/pci/riptide/riptide.c +++ b/sound/pci/riptide/riptide.c @@ -889,7 +889,7 @@ static int sendcmd(struct cmdif *cif, u32 flags, u32 cmd, u32 parm, spin_lock_irqsave(&cif->lock, irqflags); while (i++ < CMDIF_TIMEOUT && !IS_READY(cif->hwport)) udelay(10); - if (i >= CMDIF_TIMEOUT) { + if (i > CMDIF_TIMEOUT) { err = -EBUSY; goto errout; } @@ -907,8 +907,10 @@ static int sendcmd(struct cmdif *cif, u32 flags, u32 cmd, u32 parm, WRITE_PORT_ULONG(cmdport->data1, cmd); /* write cmd */ if ((flags & RESP) && ret) { while (!IS_DATF(cmdport) && - time++ < CMDIF_TIMEOUT) + time < CMDIF_TIMEOUT) { udelay(10); + time++; + } if (time < CMDIF_TIMEOUT) { /* read response */ ret->retlongs[0] = READ_PORT_ULONG(cmdport->data1); @@ -1454,7 +1456,7 @@ static int snd_riptide_trigger(struct snd_pcm_substream *substream, int cmd) SEND_GPOS(cif, 0, data->id, &rptr); udelay(1); } while (i != rptr.retlongs[1] && j++ < MAX_WRITE_RETRY); - if (j >= MAX_WRITE_RETRY) + if (j > MAX_WRITE_RETRY) snd_printk(KERN_ERR "Riptide: Could not stop stream!"); break; case SNDRV_PCM_TRIGGER_PAUSE_PUSH: @@ -1783,7 +1785,7 @@ snd_riptide_codec_write(struct snd_ac97 *ac97, unsigned short reg, SEND_SACR(cif, val, reg); SEND_RACR(cif, reg, &rptr); } while (rptr.retwords[1] != val && i++ < MAX_WRITE_RETRY); - if (i == MAX_WRITE_RETRY) + if (i > MAX_WRITE_RETRY) snd_printdd("Write AC97 reg failed\n"); }

2 1

[alsa-devel] WM9712 - Big and little endian format conversion.
by Jon Smirl 14 May '09

14 May '09

I have three areas specifying audio formats. The WM9712 AC97 codec is S16_LE. My DMA hardware is S32_BE. All samples need to be in 32b words even if they are 8,16,24b. The cpu's AC97 system sends the first 20 big endian bits down the AC97 link in the proper order. How can I force the DMA engine setting to override what the codec is saying? Or should the codec be changed to specify all bit lengths and both endians? My DMA platform: static const struct snd_pcm_hardware psc_dma_hardware = { .info = SNDRV_PCM_INFO_MMAP | SNDRV_PCM_INFO_MMAP_VALID | SNDRV_PCM_INFO_INTERLEAVED | SNDRV_PCM_INFO_BLOCK_TRANSFER | SNDRV_PCM_INFO_BATCH, .formats = SNDRV_PCM_FMTBIT_S32_BE, .rate_min = 8000, .rate_max = 48000, .channels_min = 1, .channels_max = 2, .period_bytes_max = 1024 * 1024, .period_bytes_min = 32, .periods_min = 2, .periods_max = 256, .buffer_bytes_max = 2 * 1024 * 1024, .fifo_size = 512, }; CPU DAI: static struct snd_soc_dai psc_ac97_dai_template[] = { { .name = "%s analog", .suspend = psc_ac97_suspend, .resume = psc_ac97_resume, .playback = { .channels_min = 1, .channels_max = 6, .rates = SNDRV_PCM_RATE_8000_48000, .formats = SNDRV_PCM_FMTBIT_S8 | SNDRV_PCM_FMTBIT_S16_BE | SNDRV_PCM_FMTBIT_S24_BE | SNDRV_PCM_FMTBIT_S32_BE, }, .capture = { .channels_min = 1, .channels_max = 2, .rates = SNDRV_PCM_RATE_8000_48000, .formats = SNDRV_PCM_FMTBIT_S8 | SNDRV_PCM_FMTBIT_S16_BE | SNDRV_PCM_FMTBIT_S24_BE | SNDRV_PCM_FMTBIT_S32_BE, }, .ops = &psc_ac97_analog_ops, }, Codec: struct snd_soc_dai wm9712_dai[] = { { .name = "AC97 HiFi", .ac97_control = 1, .playback = { .stream_name = "HiFi Playback", .channels_min = 1, .channels_max = 2, .rates = WM9712_AC97_RATES, .formats = SNDRV_PCM_FMTBIT_S16_LE, }, .capture = { .stream_name = "HiFi Capture", .channels_min = 1, .channels_max = 2, .rates = WM9712_AC97_RATES, .formats = SNDRV_PCM_FMTBIT_S16_LE, }, .ops = &wm9712_dai_ops_hifi, }, { -- Jon Smirl jonsmirl(a)gmail.com

2 7

[alsa-devel] Avoiding buffer underruns in the hardware interrupt handler
by Laurent Pinchart 14 May '09

14 May '09

Hi everybody. Disclaimer: I'm new with ALSA development and I'm trying to digest the large amount of information I'm overflowed with, so please bear with possibly stupid help requests. I'm writing an ALSA driver for a playback device. Unlike most sound cards, this device uses private memory for its audio buffer. I thus need to manually copy data from the ALSA buffer to the device buffer in the driver. The device audio buffer is quite small, and for this reason I'd rather not use the copy/silence callbacks, but copy data from the ALSA buffer to the device in interrupt. The device might generate interrupts a bit faster than what would be expected from sampling rate, so I need to check in the interrupt handler how much data the ALSA buffer holds. To do so I need to maintain a "hardware pointer" in the driver and to access the "user pointer" on the other side of the buffer. I haven't found a clear API to access that second pointer. What is the best/preferred way to find out how much data the ALSA buffer holds ? I suppose I will need to perform some locking when accessing the "user pointer", I will also appreciate advices regarding which mutex/spinlock I should use for that purpose. Best regards, Laurent Pinchart

1 0

[alsa-devel] [PATCH 4/4 v2] pxa2xx-i2s: Fix suspend/resume
by Karl Beldan 13 May '09

13 May '09

pxa2xx_i2s_resume is : - unconditionnaly setting SACR0_ENB - unsetting SACR0_ENB in saved SACR0 pxa_i2s.sacr0 fix these. In pxa2xx_i2s_{resume,suspend}, save/restore registers even when !dai->active. Signed-off-by: Karl Beldan <karl.beldan(a)mobile-devices.fr> --- sound/soc/pxa/pxa2xx-i2s.c | 11 +++-------- 1 files changed, 3 insertions(+), 8 deletions(-) diff --git a/sound/soc/pxa/pxa2xx-i2s.c b/sound/soc/pxa/pxa2xx-i2s.c index a423637..efe499e 100644 --- a/sound/soc/pxa/pxa2xx-i2s.c +++ b/sound/soc/pxa/pxa2xx-i2s.c @@ -262,9 +262,6 @@ static void pxa2xx_i2s_shutdown(struct snd_pcm_substream *substream, #ifdef CONFIG_PM static int pxa2xx_i2s_suspend(struct snd_soc_dai *dai) { - if (!dai->active) - return 0; - /* store registers */ pxa_i2s.sacr0 = SACR0; pxa_i2s.sacr1 = SACR1; @@ -279,16 +276,14 @@ static int pxa2xx_i2s_suspend(struct snd_soc_dai *dai) static int pxa2xx_i2s_resume(struct snd_soc_dai *dai) { - if (!dai->active) - return 0; - pxa_i2s_wait(); - SACR0 = pxa_i2s.sacr0 &= ~SACR0_ENB; + SACR0 = pxa_i2s.sacr0 & ~SACR0_ENB; SACR1 = pxa_i2s.sacr1; SAIMR = pxa_i2s.saimr; SADIV = pxa_i2s.sadiv; - SACR0 |= SACR0_ENB; + + SACR0 = pxa_i2s.sacr0; return 0; } -- 1.6.3.rc1.34.g0be9b -- Karl

1 0

[alsa-devel] [PATCH 3/4 v2] pxa2xx-i2s: Fix inappropriate release of i2s clock
by Karl Beldan 13 May '09

13 May '09

i2s_clk is 'put' for no reason in pxa2xx_i2s_shutdown. Now we 'get' i2s_clk at probe and 'put' it at driver removal or when probe fails. Signed-off-by: Karl Beldan <karl.beldan(a)mobile-devices.fr> --- sound/soc/pxa/pxa2xx-i2s.c | 2 -- 1 files changed, 0 insertions(+), 2 deletions(-) diff --git a/sound/soc/pxa/pxa2xx-i2s.c b/sound/soc/pxa/pxa2xx-i2s.c index a461c8d..a423637 100644 --- a/sound/soc/pxa/pxa2xx-i2s.c +++ b/sound/soc/pxa/pxa2xx-i2s.c @@ -257,8 +257,6 @@ static void pxa2xx_i2s_shutdown(struct snd_pcm_substream *substream, pxa_i2s_wait(); clk_disable(clk_i2s); } - - clk_put(clk_i2s); } #ifdef CONFIG_PM -- 1.6.3.rc1.34.g0be9b -- Karl

1 0