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

[alsa-devel] [PATCH] ARM: DaVinci: Audio support for DA850/OMAP-L138 EVM
by Chaithrika U S 20 Jan '10

20 Jan '10

Define resources for McASP used on DA850/OMAP-L138 EVM, add platform device defintion and Pin Mux configurations. Signed-off-by: Chaithrika U S <chaithrika(a)ti.com> --- Applies on DaVinci GIT tree. This patch is dependent on the following patch which I have submitted earlier: [PATCH v2] ARM: DaVinci: Audio support for DA830 EVM arch/arm/mach-davinci/board-da850-evm.c | 29 ++++++++++++++++++++++ arch/arm/mach-davinci/da850.c | 39 ++++++++++++++++++++++++++++++ arch/arm/mach-davinci/devices-da8xx.c | 34 +++++++++++++++++++++++++- arch/arm/mach-davinci/include/mach/asp.h | 7 +++++ arch/arm/mach-davinci/include/mach/mux.h | 25 +++++++++++++++++++ 5 files changed, 133 insertions(+), 1 deletions(-) diff --git a/arch/arm/mach-davinci/board-da850-evm.c b/arch/arm/mach-davinci/board-da850-evm.c index d989346..52bfe4c 100644 --- a/arch/arm/mach-davinci/board-da850-evm.c +++ b/arch/arm/mach-davinci/board-da850-evm.c @@ -38,6 +38,28 @@ static struct davinci_uart_config da850_evm_uart_config __initdata = { .enabled_uarts = 0x7, }; +/* davinci da850 evm audio machine driver */ +static u8 da850_iis_serializer_direction[] = { + INACTIVE_MODE, INACTIVE_MODE, INACTIVE_MODE, INACTIVE_MODE, + INACTIVE_MODE, INACTIVE_MODE, INACTIVE_MODE, INACTIVE_MODE, + INACTIVE_MODE, INACTIVE_MODE, INACTIVE_MODE, TX_MODE, + RX_MODE, INACTIVE_MODE, INACTIVE_MODE, INACTIVE_MODE, +}; + +static struct snd_platform_data da850_evm_snd_data = { + .tx_dma_offset = 0x2000, + .rx_dma_offset = 0x2000, + .op_mode = DAVINCI_MCASP_IIS_MODE, + .num_serializer = ARRAY_SIZE(da850_iis_serializer_direction), + .tdm_slots = 2, + .serial_dir = da850_iis_serializer_direction, + .eventq_no = EVENTQ_1, + .version = MCASP_VERSION_2, + .txnumevt = 1, + .rxnumevt = 1, +}; + + static __init void da850_evm_init(void) { struct davinci_soc_info *soc_info = &davinci_soc_info; @@ -86,6 +108,13 @@ static __init void da850_evm_init(void) */ __raw_writel(0, IO_ADDRESS(DA8XX_UART1_BASE) + 0x30); __raw_writel(0, IO_ADDRESS(DA8XX_UART0_BASE) + 0x30); + + ret = da8xx_pinmux_setup(da850_mcasp_pins); + if (ret) + pr_warning("da850_evm_init: mcasp mux setup failed: %d\n", + ret); + + da8xx_init_mcasp(0, &da850_evm_snd_data); } #ifdef CONFIG_SERIAL_8250_CONSOLE diff --git a/arch/arm/mach-davinci/da850.c b/arch/arm/mach-davinci/da850.c index 4a43ae2..e33b226 100644 --- a/arch/arm/mach-davinci/da850.c +++ b/arch/arm/mach-davinci/da850.c @@ -289,6 +289,13 @@ static struct clk emac_clk = { .lpsc = DA8XX_LPSC1_CPGMAC, }; +static struct clk mcasp_clk = { + .name = "mcasp", + .parent = &pll0_sysclk2, + .lpsc = DA8XX_LPSC1_McASP0, + .psc_ctlr = 1, +}; + static struct davinci_clk da850_clks[] = { CLK(NULL, "ref", &ref_clk), CLK(NULL, "pll0", &pll0_clk), @@ -326,6 +333,7 @@ static struct davinci_clk da850_clks[] = { CLK(NULL, "arm", &arm_clk), CLK(NULL, "rmii", &rmii_clk), CLK("davinci_emac.1", NULL, &emac_clk), + CLK("davinci-mcasp.0", NULL, &mcasp_clk), CLK(NULL, NULL, NULL), }; @@ -370,6 +378,30 @@ static const struct mux_config da850_pins[] = { MUX_CFG(DA850, MII_RXD_2, 3, 20, 15, 8, false) MUX_CFG(DA850, MII_RXD_1, 3, 24, 15, 8, false) MUX_CFG(DA850, MII_RXD_0, 3, 28, 15, 8, false) + /* McASP function */ + MUX_CFG(DA850, ACLKR, 0, 0, 15, 1, false) + MUX_CFG(DA850, ACLKX, 0, 4, 15, 1, false) + MUX_CFG(DA850, AFSR, 0, 8, 15, 1, false) + MUX_CFG(DA850, AFSX, 0, 12, 15, 1, false) + MUX_CFG(DA850, AHCLKR, 0, 16, 15, 1, false) + MUX_CFG(DA850, AHCLKX, 0, 20, 15, 1, false) + MUX_CFG(DA850, AMUTE, 0, 24, 15, 1, false) + MUX_CFG(DA850, AXR_15, 1, 0, 15, 1, false) + MUX_CFG(DA850, AXR_14, 1, 4, 15, 1, false) + MUX_CFG(DA850, AXR_13, 1, 8, 15, 1, false) + MUX_CFG(DA850, AXR_12, 1, 12, 15, 1, false) + MUX_CFG(DA850, AXR_11, 1, 16, 15, 1, false) + MUX_CFG(DA850, AXR_10, 1, 20, 15, 1, false) + MUX_CFG(DA850, AXR_9, 1, 24, 15, 1, false) + MUX_CFG(DA850, AXR_8, 1, 28, 15, 1, false) + MUX_CFG(DA850, AXR_7, 2, 0, 15, 1, false) + MUX_CFG(DA850, AXR_6, 2, 4, 15, 1, false) + MUX_CFG(DA850, AXR_5, 2, 8, 15, 1, false) + MUX_CFG(DA850, AXR_4, 2, 12, 15, 1, false) + MUX_CFG(DA850, AXR_3, 2, 16, 15, 1, false) + MUX_CFG(DA850, AXR_2, 2, 20, 15, 1, false) + MUX_CFG(DA850, AXR_1, 2, 24, 15, 1, false) + MUX_CFG(DA850, AXR_0, 2, 28, 15, 1, false) #endif }; @@ -406,6 +438,13 @@ const short da850_cpgmac_pins[] __initdata = { -1 }; +const short da850_mcasp_pins[] __initdata = { + DA850_AHCLKX, DA850_ACLKX, DA850_AFSX, + DA850_AHCLKR, DA850_ACLKR, DA850_AFSR, DA850_AMUTE, + DA850_AXR_11, DA850_AXR_12, + -1 +}; + /* FIQ are pri 0-1; otherwise 2-7, with 7 lowest priority */ static u8 da850_default_priorities[DA850_N_CP_INTC_IRQ] = { [IRQ_DA8XX_COMMTX] = 7, diff --git a/arch/arm/mach-davinci/devices-da8xx.c b/arch/arm/mach-davinci/devices-da8xx.c index fe0baaf..1882eef 100644 --- a/arch/arm/mach-davinci/devices-da8xx.c +++ b/arch/arm/mach-davinci/devices-da8xx.c @@ -309,6 +309,34 @@ static struct platform_device da830_mcasp1_device = { .resource = da830_mcasp1_resources, }; +static struct resource da850_mcasp_resources[] = { + { + .name = "mcasp", + .start = DAVINCI_DA8XX_MCASP0_REG_BASE, + .end = DAVINCI_DA8XX_MCASP0_REG_BASE + (SZ_1K * 12) - 1, + .flags = IORESOURCE_MEM, + }, + /* TX event */ + { + .start = DAVINCI_DA8XX_DMA_MCASP0_AXEVT, + .end = DAVINCI_DA8XX_DMA_MCASP0_AXEVT, + .flags = IORESOURCE_DMA, + }, + /* RX event */ + { + .start = DAVINCI_DA8XX_DMA_MCASP0_AREVT, + .end = DAVINCI_DA8XX_DMA_MCASP0_AREVT, + .flags = IORESOURCE_DMA, + }, +}; + +static struct platform_device da850_mcasp_device = { + .name = "davinci-mcasp", + .id = 0, + .num_resources = ARRAY_SIZE(da850_mcasp_resources), + .resource = da850_mcasp_resources, +}; + int __init da8xx_register_emac(void) { return platform_device_register(&da8xx_emac_device); @@ -316,8 +344,12 @@ int __init da8xx_register_emac(void) void __init da8xx_init_mcasp(int id, struct snd_platform_data *pdata) { - if (id == 1) { /* DA830/OMAP-L137 has 3 instances of McASP */ + /* DA830/OMAP-L137 has 3 instances of McASP */ + if (cpu_is_davinci_da830() && id == 1) { da830_mcasp1_device.dev.platform_data = pdata; platform_device_register(&da830_mcasp1_device); + } else if (cpu_is_davinci_da850()) { + da850_mcasp_device.dev.platform_data = pdata; + platform_device_register(&da850_mcasp_device); } } diff --git a/arch/arm/mach-davinci/include/mach/asp.h b/arch/arm/mach-davinci/include/mach/asp.h index f3c97ac..18e4ce3 100644 --- a/arch/arm/mach-davinci/include/mach/asp.h +++ b/arch/arm/mach-davinci/include/mach/asp.h @@ -15,6 +15,9 @@ #define DAVINCI_DM646X_MCASP0_REG_BASE 0x01D01000 #define DAVINCI_DM646X_MCASP1_REG_BASE 0x01D01800 +/* Bases of da850/da830 McASP0 register banks */ +#define DAVINCI_DA8XX_MCASP0_REG_BASE 0x01D00000 + /* Bases of da830 McASP1 register banks */ #define DAVINCI_DA830_MCASP1_REG_BASE 0x01D04000 @@ -29,6 +32,10 @@ #define DAVINCI_DM646X_DMA_MCASP0_AREVT0 9 #define DAVINCI_DM646X_DMA_MCASP1_AXEVT1 12 +/* EDMA channels of da850/da830 McASP0 */ +#define DAVINCI_DA8XX_DMA_MCASP0_AREVT 0 +#define DAVINCI_DA8XX_DMA_MCASP0_AXEVT 1 + /* EDMA channels of da830 McASP1 */ #define DAVINCI_DA830_DMA_MCASP1_AREVT 2 #define DAVINCI_DA830_DMA_MCASP1_AXEVT 3 diff --git a/arch/arm/mach-davinci/include/mach/mux.h b/arch/arm/mach-davinci/include/mach/mux.h index a676b2f..f50f5b2 100644 --- a/arch/arm/mach-davinci/include/mach/mux.h +++ b/arch/arm/mach-davinci/include/mach/mux.h @@ -748,6 +748,31 @@ enum davinci_da850_index { DA850_MII_RXD_2, DA850_MII_RXD_1, DA850_MII_RXD_0, + + /* McASP function */ + DA850_ACLKR, + DA850_ACLKX, + DA850_AFSR, + DA850_AFSX, + DA850_AHCLKR, + DA850_AHCLKX, + DA850_AMUTE, + DA850_AXR_15, + DA850_AXR_14, + DA850_AXR_13, + DA850_AXR_12, + DA850_AXR_11, + DA850_AXR_10, + DA850_AXR_9, + DA850_AXR_8, + DA850_AXR_7, + DA850_AXR_6, + DA850_AXR_5, + DA850_AXR_4, + DA850_AXR_3, + DA850_AXR_2, + DA850_AXR_1, + DA850_AXR_0, }; #ifdef CONFIG_DAVINCI_MUX -- 1.5.6

3 3

[alsa-devel] MSM DSP
by GNUtoo 17 Jan '10

17 Jan '10

hi, I've bought an HTC dream,before buying I looked at the feasibility of porting GNU/Linux on it(so not Android). There is a patch(for maing the driver standard) or a standard(everything is non-standard in android) driver for most of the components. The biggest problem seems the sound. So knowing that codeaurora( https://www.codeaurora.org/gitweb/quic/le/?p=kernel/msm.git ) had alsa in its kenrel I first tried to compile that kernel...but due to numerous bugs(It didn't compile and needed too much fixing) in it android-msm-2.6.29 branch I decided to import alsa in the linuxtogo kernel,and I pushed the sources at a temporary htc-alsa branch at git://gitorious.org/replicant/gnulinuxkernel.git (it's called gnulinux in order to differentiate from an android kernel,I didn't find a good name for it) from the commit message available here : http://gitorious.org/replicant/gnulinuxkernel/commit/92945ccd0921e940fc2675… I had to change snd_rpc_ids.vers = 0x00020001 into snd_rpc_ids.vers = 0xaa2b1a44 ,and to make minor build system changes and I had aplay working rapidely... but only aplay... mplayer was waiting indefinitely for the following system call: ioctl(6, 0x400c4150 ls -l /proc/$(pido mplayer)/fd/6 gave /dev/snd/pcmC0D0p and 0x400c4150 gave that: SNDRV_PCM_IOCTL_WRITEI_FRAMES = _IOW('A', 0x50, struct snd_xferi) Then with printks(I had no serial cable(I've looked for a craddle/docking station with the special HTC connector for easy soldering...but I didn't found one) so I couldn't use kgdb) I went until that point: rc = wait_event_interruptible(the_locks.write_wait, (frame->used == 0)|| (prtd->stopped)); That's in the alsa_send_buffer function in /sound/soc/msm/msm-pcm.c Then I continued the tracing puting printks everywhere...and I found that: with aplay: msm_pcm_playback_copy in the /sound/soc/msm/msm7k-pcm.c was called rc = alsa_send_buffer(prtd, buf, fbytes, NULL); was called once inside alsa_send_buffer (in /sound/soc/msm/msm-pcm.c) the count loop was only executed once because count was exhausted on the first run then copy_count is incremented and the audio is configured then at second call of the alsa_send_buffer the audio is configured and works. here's an output of the aplay parameters: $ aplay -v 05\ -\ Jet\ Set.wav Playing WAVE '05 - Jet Set.wav' : Signed 16 bit Little Endian, Rate 44100 Hz, Stereo Plug PCM: Hardware PCM card 0 'msm-audio' device 0 subdevice 0 Its setup is: stream : PLAYBACK access : RW_INTERLEAVED format : S16_LE subformat : STD channels : 2 rate : 44100 exact rate : 44100 (44100/1) msbits : 16 buffer_size : 4800 period_size : 1200 period_time : 27210 tick_time : 0 tstamp_mode : NONE period_step : 1 sleep_min : 0 avail_min : 1200 xfer_align : 1200 start_threshold : 4800 stop_threshold : 4800 silence_threshold: 0 silence_size : 0 boundary : 1258291200 note that frame = prtd->out + prtd->out_tail; makes frame->used have a bad value the first time it is run but as the count is only run once it doesn't import. the next runs prtd->out + prtd->out_tail have a good value with mplayer the story was quite different,even if the beginning was the same : msm_pcm_playback_copy in the /sound/soc/msm/msm7k-pcm.c was also called,rc = alsa_send_buffer(prtd, buf, fbytes, NULL); was also called inside alsa_send_buffer (in /sound/soc/msm/msm-pcm.c) but once in alsa_send_buffer,more precisely under the count loop the story changes: count is not exhausted the first time,because in "xfer = count > frame->size ? frame->size : count;" the smallest between count and frame->size is assigned,and so after it does "count -= xfer" and so count is not 0,because the buffer size detected by mplayer is 19200 insterad of 4800 so here what it does in detail: it passes 19200 as count here: fbytes = frames_to_bytes(runtime, frames); rc = alsa_send_buffer(prtd, buf, fbytes, NULL); that goes into that: ssize_t alsa_send_buffer(struct msm_audio *prtd, const char __user *buf, size_t count, loff_t *pos) and then the count variable is 19200 in alsa_send_buffer then there is xfer = count > frame->size ? frame->size : count; so it assigns the minimum between count and frame->size to xfer count is still 19200 frame->size is 4800 so xfer becomes 4800 then count -= xfer decrement count but only of 4800 so count is not exhausted and runs another time then : frame = prtd->out + prtd->out_tail; makes frame->used have a bad value,and then it blocks here: rc = wait_event_interruptible(the_locks.write_wait,(frame->used == 0) || (prtd->stopped)); because frame->used is not 0. here an mplayer output: Forced audio codec: mad Opening audio decoder: [pcm] Uncompressed PCM audio decoder dec_audio: Allocating 2048 + 65536 = 67584 bytes for output buffer. AUDIO: 44100 Hz, 2 ch, s16le, 1411.2 kbit/100.00% (ratio: 176400->176400) Selected audio codec: [pcm] afm: pcm (Uncompressed PCM) ========================================================================== Building audio filter chain for 44100Hz/2ch/s16le -> 0Hz/0ch/??... [libaf] Adding filter dummy [dummy] Was reinitialized: 44100Hz/2ch/s16le [dummy] Was reinitialized: 44100Hz/2ch/s16le Trying preferred audio driver 'alsa', options '[none]' alsa-init: requested format: 44100 Hz, 2 channels, 9 alsa-init: using ALSA 1.0.15 alsa-init: setup for 1/2 channel(s) alsa-init: using device default alsa-init: pcm opened in blocking mode alsa-init: got buffersize=19200 alsa-init: got period size 300 alsa: 44100 Hz/2 channels/4 bpf/19200 bytes buffer/Signed 16 bit Little Endian AO: [alsa] 44100Hz 2ch s16le (2 bytes per sample) AO: Description: ALSA-0.9.x-1.x audio output AO: Author: Alex Beregszaszi, Zsolt Barat <joy(a)streamminister.de> AO: Comment: under developement Building audio filter chain for 44100Hz/2ch/s16le -> 44100Hz/2ch/s16le... [dummy] Was reinitialized: 44100Hz/2ch/s16le [dummy] Was reinitialized: 44100Hz/2ch/s16le Video: no video Freeing 0 unused video chunks. Starting playback... Increasing filtered audio buffer size from 0 to 21248 so the quick solution was to force mplayer to use 4800 as buffer size with something like that: diff --git a/sound/soc/msm/msm7k-pcm.c b/sound/soc/msm/msm7k-pcm.c index 38e8283..bfbc66d 100644 --- a/sound/soc/msm/msm7k-pcm.c +++ b/sound/soc/msm/msm7k-pcm.c @@ -115,7 +115,7 @@ static struct snd_pcm_hardware msm_pcm_playback_hardware = { .rate_max = USE_RATE_MAX, .channels_min = USE_CHANNELS_MIN, .channels_max = USE_CHANNELS_MAX, - .buffer_bytes_max = MAX_BUFFER_PLAYBACK_SIZE, + .buffer_bytes_max = 4800, .period_bytes_min = 64, .period_bytes_max = MAX_PERIOD_SIZE, .periods_min = USE_PERIODS_MIN, but then mplayer seem to loop on an ioctl: mplayer is frozen here and doesn't respond to other input than ctrl+c: 0.0 (00.0) of 206.0 (03:26.0) ??,?% strace shows a lot of : nanosleep followed by SNDRV_PCM_IOCTL_STATUS (ioctl(6, 0x806c4120, 0xbe8bc9c8) = 0) an analyse of the status shows a constant : status->delay is 1200,and status->avail is 0,they don't vary over time and are printed just after that code in snd_pcm_status in sound/core/pcm_native.c if (runtime->status->state == SNDRV_PCM_STATE_RUNNING || runtime->status->state == SNDRV_PCM_STATE_DRAINING) status->delay = runtime->buffer_size - status->avail; else status->delay = 0; I was told in #mplayerdev that it was because the DSP didn't play the frames...indeed I hear no sound.... So how should I fix that mess? *did the quick and dirty fix cause the second problem? *should I use the DSP directly and make a pulseaudio plugin that talks to the android driver, instead(the driver seems very buggy) The good would be support for mp3 and similar things within the DSP,and that it should be more stable. The bad is that I already spent *a lot* of time with the alsa kernel driver...and that writing that will also require some userspaces changes such as: *modification of the phone routing in the "FSO" ( http://www.freesmartphone.org/index.php/Main_Page ) dbus framework to use pulseaudio *would require changes in the build system for using pulseaudio(openembedded(http://wiki.openembedded.net/index.php/Main_Page )) *may be slow...openmoko stopped to use pulseaudio because of speed issues. Denis

7 18

[alsa-devel] Audio buffer mmap-ing on sh arch vs. cache aliasing problem
by Pawel MOLL 16 Jan '10

16 Jan '10

Hi Guys, Recently I was investigating an issue with capturing audio using USB Audio Class device on a sh4-based board. "Bad voice quality" was reported... Finally I have traced the problem to something which is (unfortunately) well known to sh developers as a D-cache aliasing (or synonym) problem. Briefly speaking: due to some MMU design decisions, one can have two different virtual address pointing to the same physical location, which is fine, but going via different cache slots! So if there was a value of "0" in the memory and user "A" will write "1" there, user "B" will still read "0"... The solution is to ensure all TLB entries (so virtual memory areas) are beginning from a 16kB-aligned virtual address. Otherwise it is necessary to flush the cache between accesses from "A" and "B" sides. And now. The USB Audio Class driver (sound/usb/usbaudio.c) is allocating the sound buffer like this... static int snd_pcm_alloc_vmalloc_buffer(struct snd_pcm_substream *subs, size_t size) { [...] runtime->dma_area = vmalloc(size); [...] } ... and vmalloc will return a page(4k)-aligned pointer, possibly not 16k-aligned one. This is the source of all evil ;-) When using RW transfers everything is fine, as data is memcopied between two independent buffers. In a case of MMAP mode we will end up with such a situation: 1. The driver will memcpy data from an URB to the buffer. It will populate several cache lines. Let's call it a "kernel cache". 2. As the library has mapped the non-16k-aligned address via different cache line ("user cache"), it will read some rubbish from the physical memory, populating the "user cache" by the way. 3. Some time later the "kernel cache" is flushed, writing the data to the memory. 4. Some new data from URB is entering "kernel cache". 5. The library will access mmap-ed area again, going via the "user cache", which may or may not reflect the correct data (depending on the fact was the "user cache" flushed or not) etc. Of course this cycle is completely not deterministic, so some of the "kernel cache" lines will be flushed before being accessed from user space, other not... The final effect is... hmm... bizarre :-) First, of course, you will get a (probably loud) glitch (rubbish from buffer's underlying memory, before the first valid data is written back), and then something that could be described as an "echo" ;-) I mean - you are capturing "1 2 3 4 5 6 7..." and the result is (G stands for Glitch ;-) "G 1 23 3 4 4 6 67..." As a quick-and-dirty work-around I have modified snd_pcm_alloc_vmalloc_buffer() to allocate always 12kB more and then use 16k-aligned pointer: static int snd_pcm_alloc_vmalloc_buffer(struct snd_pcm_substream *subs, size_t size) { struct snd_pcm_runtime *runtime = subs->runtime; if (runtime->dma_addr) { if (runtime->dma_bytes >= size) return 0; /* already large enough */ vfree((void *)runtime->dma_addr); } runtime->dma_addr = (unsigned long)vmalloc(size + 12 * 1024); if (!runtime->dma_addr) return -ENOMEM; runtime->dma_area = (void *)ALIGN(runtime->dma_addr, 16 * 1024); runtime->dma_bytes = size; return 0; } Of course it cannot be regarded as anything more as a hack. And definitely not as a solution... So my question is: Any idea how the "proper solution" should look like? I see no obvious method to get an arch-independent "mmap-compliant" buffer. This problem was found on a sh arch, using an USB Audio Class device, however out there some other architectures are suffering from this MMU "feature" as well (ie. see http://docs.hp.com/en/B3906-90006/ch07s09.html) and possibly other drivers could behave "wrongly" (quoted as the driver is actually innocent...) To be honest I just have absolutely no idea what to do with this all! :-O I hope I was clear enough in the description... Any feedback, advise, idea etc. will be more than appreciated. Cheers Paweł

3 11

Re: [alsa-devel] snd-hdsp driver error?
by Raymond Yau 14 Jan '10

14 Jan '10

AFAIK , alsa-lib use the driver name to find the name of corresponding conf file from /usr/share/alsa/cards/aliases.conf In your case , H-DSP.conf does not exist and there is no aliases in /usr/share/alsa/cards/aliases.conf You have to ask Takashi or Jaroslav to fix this issue for your card open("/usr/share/alsa/cards/aliases.conf", O_RDONLY) = 3 access("/usr/share/alsa/cards/H-DSP.conf", R_OK) = -1 ENOENT (No such file or directory) open("/dev/snd/controlC1", O_RDONLY) = 3 close(3) = 0 write(2, "ALSA lib confmisc.c:1286:(snd_fu"..., 42ALSA lib confmisc.c:1286:(snd_func_refer) ) = 42 write(2, "Unable to find definition 'cards"..., 58Unable to find definition 'cards.H-DSP.pcm.front.0:CARD=0') = 58 write(2, "\n", 1 2009/11/7 Lars Zobbe <fedesensfar(a)gmail.com> > It is a clean install. > lars@lars-desktop:~$ lsb_release -a && uname -a > No LSB modules are available. > Distributor ID: Ubuntu > Description: Ubuntu 9.10 > Release: 9.10 > Codename: karmic > Linux lars-desktop 2.6.31-14-generic #48-Ubuntu SMP Fri Oct 16 14:05:01 UTC > 2009 x86_64 GNU/Linux > > It didn't work with pulseaudio in any previos version (of ubuntu or any > other distro I've tried) either. > And the standard answer from people "out there" is "forget about pulse it > doesn't work with the HDSP" f.x. this guy > http://ubuntuforums.org/showpost.php?p=7578331&postcount=10 > And that's why I contacted pulseaudio developers first when I found out the > it was because snd_hdsp didn't load with the preferred udev but only with > module-detect (se my first post). They said that I should inform Alsa > developers as there seems to be a problem with the alsa driver. > > I've attached the strace output. > > Thanks. > Lars. > > > > > On Fri, Nov 6, 2009 at 2:53 AM, Raymond Yau <superquad.vortex2(a)gmail.com>wrote: > >> Is it a clean install of Ubuntu 9.10 or upgrade from previous Ubuntu ? >> >> you may need to find out why aplay -v -Dfront 32bit.wav fail ? >> >> strace aplay -v -Dfront 32bit.wav >> >> >> >> >> >> !!Linux Distribution >> >> !!------------------ >> >> Ubuntu 9.10 \n \l DISTRIB_ID=Ubuntu DISTRIB_DESCRIPTION="Ubuntu 9.10" >> >> !!Sound Servers on this system >> !!---------------------------- >> >> Pulseaudio: >> Installed - Yes (/usr/bin/pulseaudio) >> >> >> Running - Yes >> >> ESound Daemon: >> Installed - Yes (/usr/bin/esd) >> Running - No >> >> Jack: >> Installed - Yes (/usr/bin/jackd) >> Running - No >> >> >> !!ALSA configuration files >> >> >> !!------------------------ >> >> !!User specific config file (~/.asoundrc) >> >> pcm.!default { >> type plug >> slave { pcm "jack" } >> } >> >> pcm.jack { >> type jack >> playback_ports { >> >> 0 alsa_pcm:playback_1 >> >> 1 alsa_pcm:playback_2 >> } >> capture_ports { >> 0 alsa_pcm:capture_1 >> 1 alsa_pcm:capture_2 >> } >> } >> >> ctl.mixer0 { >> type hw >> card 0 >> } >> >> >> lars@lars-desktop:~$ aplay -v -Dfront:0 32bit.wav >> ALSA lib confmisc.c:1286:(snd_func_refer) Unable to find definition >> 'cards.H-DSP.pcm.front.0:CARD=0' >> ALSA lib conf.c:3513:(_snd_config_evaluate) function snd_func_refer >> returned error: No such file or directory >> ALSA lib conf.c:3985:(snd_config_expand) Evaluate error: No such file or >> directory >> ALSA lib pcm.c:2211:(snd_pcm_open_noupdate) Unknown PCM front:0 >> aplay: main:608: audio open error: No such file or directory >> >> >> Did PA developer tell you not to load oss module ? >> >> >> >> D: alsa-util.c: Checking for subset analog-mono (hw:%f) >> D: alsa-util.c: Trying hw:0 with SND_PCM_NO_AUTO_FORMAT ... >> D: alsa-util.c: Managed to open hw:0 >> D: alsa-util.c: snd_pcm_hw_params_set_access() failed: Invalid argument >> D: alsa-util.c: Trying hw:0 without SND_PCM_NO_AUTO_FORMAT ... >> D: alsa-util.c: Managed to open hw:0 >> D: alsa-util.c: snd_pcm_hw_params_set_access() failed: Invalid argument >> D: alsa-util.c: Trying plug:hw:0 with SND_PCM_NO_AUTO_FORMAT ... >> D: alsa-util.c: Managed to open plug:hw:0 >> D: alsa-util.c: snd_pcm_hw_params_set_format(Signed 16 bit Little Endian) >> failed: Invalid argument >> D: alsa-util.c: snd_pcm_hw_params_set_format(Signed 16 bit Big Endian) >> failed: Invalid argument >> D: alsa-util.c: snd_pcm_hw_params_set_format(Float 32 bit Little Endian) >> failed: Invalid argument >> D: alsa-util.c: snd_pcm_hw_params_set_format(Float 32 bit Big Endian) >> failed: Invalid argument >> D: alsa-util.c: snd_pcm_hw_params_set_channels(1) failed: Invalid argument >> D: alsa-util.c: Trying plug:hw:0 without SND_PCM_NO_AUTO_FORMAT ... >> D: alsa-util.c: Managed to open plug:hw:0 >> D: alsa-util.c: snd_pcm_hw_params_set_channels(1) failed: Invalid argument >> I: alsa-util.c: Failed to set hardware parameters on plug:hw:0: Invalid >> argument >> D: alsa-util.c: Trying hw:0 as last resort... >> D: alsa-util.c: Trying hw:0 with SND_PCM_NO_AUTO_FORMAT ... >> D: alsa-util.c: Managed to open hw:0 >> D: alsa-util.c: snd_pcm_hw_params_set_access() failed: Invalid argument >> D: alsa-util.c: Trying hw:0 without SND_PCM_NO_AUTO_FORMAT ... >> D: alsa-util.c: Managed to open hw:0 >> D: alsa-util.c: snd_pcm_hw_params_set_access() failed: Invalid argument >> D: alsa-util.c: Trying plug:hw:0 with SND_PCM_NO_AUTO_FORMAT ... >> D: alsa-util.c: Managed to open plug:hw:0 >> D: alsa-util.c: snd_pcm_hw_params_set_format(Signed 16 bit Little Endian) >> failed: Invalid argument >> D: alsa-util.c: snd_pcm_hw_params_set_format(Signed 16 bit Big Endian) >> failed: Invalid argument >> D: alsa-util.c: snd_pcm_hw_params_set_format(Float 32 bit Little Endian) >> failed: Invalid argument >> D: alsa-util.c: snd_pcm_hw_params_set_format(Float 32 bit Big Endian) >> failed: Invalid argument >> D: alsa-util.c: Maximum hw buffer size is 371 ms >> I: (alsa-lib)pcm_hw.c: SNDRV_PCM_IOCTL_HW_PARAMS failed >> I: (alsa-lib)pcm_hw.c: SNDRV_PCM_IOCTL_HW_PARAMS failed >> I: (alsa-lib)pcm_hw.c: SNDRV_PCM_IOCTL_HW_PARAMS failed >> I: (alsa-lib)pcm_hw.c: SNDRV_PCM_IOCTL_HW_PARAMS failed >> D: alsa-util.c: Set neither period nor buffer size. >> I: (alsa-lib)pcm_hw.c: SNDRV_PCM_IOCTL_HW_PARAMS failed >> I: alsa-util.c: snd_pcm_hw_params failed: Device or resource busy >> D: alsa-util.c: Trying plug:hw:0 without SND_PCM_NO_AUTO_FORMAT ... >> D: alsa-util.c: Managed to open plug:hw:0 >> D: alsa-util.c: Maximum hw buffer size is 371 ms >> I: (alsa-lib)pcm_hw.c: SNDRV_PCM_IOCTL_HW_PARAMS failed >> I: (alsa-lib)pcm_hw.c: SNDRV_PCM_IOCTL_HW_PARAMS failed >> I: (alsa-lib)pcm_hw.c: SNDRV_PCM_IOCTL_HW_PARAMS failed >> I: (alsa-lib)pcm_hw.c: SNDRV_PCM_IOCTL_HW_PARAMS failed >> D: alsa-util.c: Set neither period nor buffer size. >> I: (alsa-lib)pcm_hw.c: SNDRV_PCM_IOCTL_HW_PARAMS failed >> I: alsa-util.c: snd_pcm_hw_params failed: Device or resource busy >> I: alsa-util.c: Failed to set hardware parameters on plug:hw:0: Device or >> resource busy >> E: module.c: Failed to load module "module-alsa-source" (argument: >> "device_id=0"): initialization failed. >> W: module.c: module-oss is deprecated: Please use module-alsa-card instead >> of module-oss! >> D: oss-util.c: capabilities: MMAP REALTIME TRIGGER >> I: module-oss.c: Device opened in O_RDONLY mode. >> D: oss-util.c: Asking for 4 fragments of size 512 (requested 880) >> E: oss-util.c: SNDCTL_DSP_SETFMT: Device or resource busy >> E: module.c: Failed to load module "module-oss" (argument: >> "device=/dev/dsp"): initialization failed. >> W: module-detect.c: failed to detect any sound hardware. >> >> >> 2009/11/6 Lars Zobbe <fedesensfar(a)gmail.com> >> >> Sorry. I didn't realise that it was a bash script. Here is the link to my >>> alsa-info >>> >>> http://www.alsa-project.org/db/?f=d3728557be71067e2ed0920747118ae7efff2829 >>> >>> Thanks again. >>> Lars. >>> >>> >>> On Thu, Nov 5, 2009 at 5:29 AM, Raymond Yau <superquad.vortex2(a)gmail.com >>> > wrote: >>> >>>> Please provide the full pulseaudio log and output of alsa-info.sh >>>> >>>> http://www.pulseaudio.org/wiki/Troubleshooting >>>> >>>> pulseaudio -k; pulseaudio -vvv >>>> >>>> and >>>> >>>> aplay -v -Dfront:0 32bit.wav >>>> >>>> aplay -v -M -Dfront:0 32bit.wav >>>> >>>> aplay -v -Dplughw:0 any.wav >>>> >>>> aplay -v -M -Dplughw:0 any.wav >>>> >>>> >>>> 2009/11/4 Lars Zobbe <fedesensfar(a)gmail.com> >>>> >>>> > Hi Raymond. >>>> > >>>> > I so sorry Raymond. But I'm not sure what to do with this info. Is >>>> there >>>> > something more I have to tell you? Is there anything I can do to make >>>> > pulseaudio able to detect via udev? Can I copy-paste that bit of code >>>> you >>>> > sent me somewhere? >>>> > Please tell me if there's more you need to know. >>>> > Greetings. >>>> > Lars. >>>> > >>>> > >>>> > >>>> > >>>> > On Tue, Nov 3, 2009 at 7:48 AM, Raymond Yau < >>>> superquad.vortex2(a)gmail.com>wrote: >>>> > >>>> >> I guess route plugin used by RME96*.conf does not support mmap when >>>> there >>>> >> is >>>> >> channel conversion since minimum channels supported by hdsp is 14 >>>> >> >>>> >> >>>> >> static struct snd_pcm_hardware snd_hdsp_playback_subinfo = >>>> >> { >>>> >> .info = (SNDRV_PCM_INFO_MMAP | >>>> >> SNDRV_PCM_INFO_MMAP_VALID | >>>> >> SNDRV_PCM_INFO_NONINTERLEAVED | >>>> >> SNDRV_PCM_INFO_SYNC_START | >>>> >> SNDRV_PCM_INFO_DOUBLE), >>>> >> #ifdef SNDRV_BIG_ENDIAN >>>> >> .formats = SNDRV_PCM_FMTBIT_S32_BE, >>>> >> #else >>>> >> .formats = SNDRV_PCM_FMTBIT_S32_LE, >>>> >> #endif >>>> >> .rates = (SNDRV_PCM_RATE_32000 | >>>> >> SNDRV_PCM_RATE_44100 | >>>> >> SNDRV_PCM_RATE_48000 | >>>> >> SNDRV_PCM_RATE_64000 | >>>> >> SNDRV_PCM_RATE_88200 | >>>> >> SNDRV_PCM_RATE_96000), >>>> >> .rate_min = 32000, >>>> >> .rate_max = 96000, >>>> >> .channels_min = 14, >>>> >> .channels_max = HDSP_MAX_CHANNELS, >>>> >> .buffer_bytes_max = HDSP_CHANNEL_BUFFER_BYTES * HDSP_MAX_CHANNELS, >>>> >> .period_bytes_min = (64 * 4) * 10, >>>> >> .period_bytes_max = (8192 * 4) * HDSP_MAX_CHANNELS, >>>> >> .periods_min = 2, >>>> >> .periods_max = 2, >>>> >> .fifo_size = 0 >>>> >> }; >>>> >> >>>> >> 2009/11/2 Lars Zobbe <fedesensfar(a)gmail.com> >>>> >> >>>> >> > Hi. >>>> >> > >>>> >> > Talking to one of the pulseaudio developers (*Colin Guthrie*) about >>>> a >>>> >> > problem with pulseaudio loading modules and my sound card (RME HDSP >>>> >> 9632), >>>> >> > I >>>> >> > was adviced to inform you about the problem. >>>> >> > >>>> >> > I'm on ubuntu 9.10, 64bit, kernel 2.6.31 with an amd64 x2 3800+ >>>> >> processor. >>>> >> > >>>> >> > >>>> >> > Symptoms are: >>>> >> > Can only make pulseaudio load modules with the deprecated >>>> load-module >>>> >> > module-detect command, module-udev-detect doesn't detect anything >>>> (no >>>> >> sound >>>> >> > - only null sink output in padevchooser). >>>> >> > I get terrible stuttering. >>>> >> > I can remove pulseaudio and make things work, more or less. >>>> However, >>>> >> that >>>> >> > leaves me without software mixing and apps fighting for the rights >>>> to >>>> >> make >>>> >> > sound. And more inconveniences (fx. no volume-control). >>>> >> > I can play sound from audacity without stuttering by choosing the >>>> >> cardname >>>> >> > directly in output HDSP, not ALSA, not pulseaudio. >>>> >> > >>>> >> > >>>> >> > When trying to run alsa-info.sh I get a lot of "not found" errors. >>>> So >>>> >> > you'll >>>> >> > get some manual info (they might have moved som files around in >>>> ubuntu >>>> >> > 9.10). >>>> >> > >>>> >> > This is part of my syslog during a boot. (I did the formatting to >>>> bold). >>>> >> > >>>> >> > Nov 2 10:57:32 lars-desktop pulseaudio[1524]: module.c: >>>> module-detect >>>> >> is >>>> >> > deprecated: Please use module-udev-detect instead of module-detect! >>>> >> > Nov 2 10:57:37 lars-desktop pulseaudio[1524]: ratelimit.c: 27 >>>> events >>>> >> > suppressed >>>> >> > Nov 2 10:57:39 lars-desktop pulseaudio[1612]: module.c: >>>> module-detect >>>> >> is >>>> >> > deprecated: Please use module-udev-detect instead of module-detect! >>>> >> > Nov 2 10:57:44 lars-desktop pulseaudio[1612]: ratelimit.c: 23 >>>> events >>>> >> > suppressed >>>> >> > Nov 2 10:57:44 lars-desktop pulseaudio[1612]: alsa-sink.c: ALSA >>>> woke us >>>> >> up >>>> >> > to write new data to the device, but there was actually nothing to >>>> >> write! >>>> >> > Nov 2 10:57:44 lars-desktop pulseaudio[1612]: alsa-sink.c: *Most >>>> likely >>>> >> > this is a bug in the ALSA driver 'snd_hdsp'. Please report this >>>> issue to >>>> >> > the >>>> >> > ALSA developers.* >>>> >> > Nov 2 10:57:44 lars-desktop pulseaudio[1612]: alsa-sink.c: We were >>>> >> woken >>>> >> > up >>>> >> > with POLLOUT set -- however a subsequent snd_pcm_avail() returned 0 >>>> or >>>> >> > another value < min_avail. >>>> >> > Nov 2 10:57:49 lars-desktop pulseaudio[1612]: ratelimit.c: 99 >>>> events >>>> >> > suppressed >>>> >> > >>>> >> > Later if I try to play audio I get terrible skipping or stuttering >>>> and >>>> >> my >>>> >> > syslog (in less than a minute) writes: >>>> >> > Nov 2 11:55:16 lars-desktop pulseaudio[1612]: ratelimit.c: 16 >>>> events >>>> >> > suppressed >>>> >> > Nov 2 11:55:21 lars-desktop pulseaudio[1612]: ratelimit.c: 34 >>>> events >>>> >> > suppressed >>>> >> > Nov 2 11:55:26 lars-desktop pulseaudio[1612]: ratelimit.c: 70 >>>> events >>>> >> > suppressed >>>> >> > Nov 2 11:55:31 lars-desktop pulseaudio[1612]: ratelimit.c: 29 >>>> events >>>> >> > suppressed >>>> >> > Nov 2 11:55:36 lars-desktop pulseaudio[1612]: ratelimit.c: 43 >>>> events >>>> >> > suppressed >>>> >> > Nov 2 11:55:41 lars-desktop pulseaudio[1612]: ratelimit.c: 161 >>>> events >>>> >> > suppressed >>>> >> > Nov 2 11:55:46 lars-desktop pulseaudio[1612]: ratelimit.c: 28 >>>> events >>>> >> > suppressed >>>> >> > Nov 2 11:55:51 lars-desktop pulseaudio[1612]: ratelimit.c: 18 >>>> events >>>> >> > suppressed >>>> >> > Nov 2 11:55:56 lars-desktop pulseaudio[1612]: ratelimit.c: 16 >>>> events >>>> >> > suppressed >>>> >> > >>>> >> > Here's the relevant part (concerning my sound card) of lspci -vvv >>>> >> > >>>> >> > 02:09.0 Multimedia audio controller: Xilinx Corporation RME >>>> Hammerfall >>>> >> DSP >>>> >> > (rev 9a) >>>> >> > Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- >>>> ParErr- >>>> >> > Stepping- SERR- FastB2B- DisINTx- >>>> >> > Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- >>>> >> > <TAbort- <MAbort- >SERR- <PERR- INTx- >>>> >> > Latency: 255 >>>> >> > Interrupt: pin A routed to IRQ 19 >>>> >> > Region 0: Memory at fdff0000 (32-bit, non-prefetchable) >>>> [size=64K] >>>> >> > Kernel driver in use: RME Hammerfall DSP >>>> >> > Kernel modules: snd-hdsp >>>> >> > >>>> >> > And: >>>> >> > lars@lars-desktop:~$ aplay -l >>>> >> > **** List of PLAYBACK Hardware Devices **** >>>> >> > card 0: DSP [Hammerfall DSP], device 0: RME Hammerfall HDSP 9632 >>>> [RME >>>> >> > Hammerfall HDSP 9632] >>>> >> > Subdevices: 1/1 >>>> >> > Subdevice #0: subdevice #0 >>>> >> > >>>> >> > >>>> >> > lars@lars-desktop:~$ cat /proc/asound/version >>>> >> > Advanced Linux Sound Architecture Driver Version 1.0.21. >>>> >> > Compiled on Oct 15 2009 for kernel 2.6.31-14-generic (SMP). >>>> >> > >>>> >> > lars@lars-desktop:~$ cat /proc/asound/cards >>>> >> > 0 [DSP ]: H-DSP - Hammerfall DSP >>>> >> > RME Hammerfall HDSP 9632 at 0xfdff0000, irq 19 >>>> >> > >>>> >> > >>>> >> > lars@lars-desktop:~$ cat /proc/asound/modules >>>> >> > 0 snd_hdsp >>>> >> > >>>> >> > I don't have .asound.conf files. >>>> >> > >>>> >> > lars@lars-desktop:~$ hdsploader >>>> >> > hdsploader - firmware loader for RME Hammerfall DSP cards >>>> >> > Looking for HDSP + Multiface or Digiface cards : >>>> >> > Card 0 : RME Hammerfall HDSP 9632 at 0xfdff0000, irq 19 >>>> >> > >>>> >> > And of course. My computer makes no sound if I don't load the >>>> hdspmixer >>>> >> at >>>> >> > startup. I guess that's just normal for this card though. >>>> >> > >>>> >> > Please let me know, if you need more info. I really hope you can >>>> help >>>> >> out >>>> >> > here. And that this might help you to. >>>> >> > >>>> >> > Thanks for the great work you do. Greetings. >>>> >> > Lars Zobbe. >>>> >> > _______________________________________________ >>>> >> > Alsa-devel mailing list >>>> >> > Alsa-devel(a)alsa-project.org >>>> >> > http://mailman.alsa-project.org/mailman/listinfo/alsa-devel >>>> >> > >>>> >> _______________________________________________ >>>> >> Alsa-devel mailing list >>>> >> Alsa-devel(a)alsa-project.org >>>> >> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel >>>> >> >>>> > >>>> > >>>> _______________________________________________ >>>> Alsa-devel mailing list >>>> Alsa-devel(a)alsa-project.org >>>> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel >>>> >>> >>> >> >

3 4

Re: [alsa-devel] [PATCH] OMAP: Exporting functions doing common register access
by Aggarwal, Anuj 13 Jan '10

13 Jan '10

> -----Original Message----- > From: Paul Walmsley [mailto:paul@pwsan.com] > Sent: Tuesday, November 17, 2009 2:46 AM > To: Aggarwal, Anuj > Cc: linux-omap(a)vger.kernel.org > Subject: Re: [PATCH] OMAP: Exporting functions doing common register > access > > Hello Anuj, > > On Mon, 16 Nov 2009, Anuj Aggarwal wrote: > > > These functions need to be exported so that drivers (e.g. McBSP) can > > be configured as modules. > > > > McBSP driver gets built as a module when ASoC driver for OMAP3 EVM > > is configured as module. McBSP driver uses functions like > > omap_ctrl_readl/omap_ctrl_writel, which are defined in control.c > > file but not exported. Without that, McBSP driver fails to build as > > a module. > > > > Signed-off-by: Anuj Aggarwal <anuj.aggarwal(a)ti.com> > > This will prevent the McBSP driver from being usable across chips. For > example, if a future OMAP comes out with McBSP clock source switching > implemented in a different way, or if a DaVinci chip comes out with a > McBSP block but no SCM block, this either won't build or won't run. > > A better approach would be to move the OMAP2/3-specific functions from the > McBSP driver into the OMAP McBSP integration code, > arch/arm/*omap*/mcbsp.c, and to define function pointers in > struct platform_data for these functions, and to pass them from the > integration code into the device driver code. That will make these > drivers independent of chip integration details. Sorry to confuse you, I was talking about the platform specific ASoC-McBSP code for OMAP (file - sound/soc/omap/omap-mcbsp.c) platform. The McBSP driver - both platform and machine specific - doesn't use the functions exported by the patch. Including alsa-devel list too... > > > - Paul

3 7

[alsa-devel] X-Fi notebook support
by The Source 12 Jan '10

12 Jan '10

Hello. I have some info on that card, but not much. I have discovered that this card is detected connected via USB rather than PCI-E (the slot is ExpressCard). snd_ctxfi uses PCI interfaces right? Can X-Fi support be also added to snd_usb_audio? Or can snd_ctxfi support USB? lsusb -v output on that card is attached (sorry for duplicate mail, forgot to attach it first time). I now have this card and willing to help to test (or perhaps create) proper driver.

1 4

[alsa-devel] hda-intel: no codecs found
by Ozan Çağlayan 12 Jan '10

12 Jan '10

Hi, Does that warning can be interpreted as a hardware failure? I'm reverting to older alsa-driver snapshots that I'm sure was working OK but still having this warning. I'm suspecting the power outage that the system suffered on Friday. Is there a way to understand whether it's driver related or HW related? Thanks, Ozan

2 2

[alsa-devel] alsa-util.c: snd_pcm_avail() returned a value that is exceptionally large: 349696 bytes (1821 ms).
by Chris 11 Jan '10

11 Jan '10

Mandriva 2010.0, Gnome 2.28, pulseaudio 0.9.19-7mdv2010.0. With pulseaudio enabled in MCC periodically the hd light will constantly be on for a period of 4 or 5 minutes and system will slow down to a crawl. Also these comments will be in syslog: pulseaudio[4331]: alsa-util.c: snd_pcm_avail() returned a value that is exceptionally large: 349696 bytes (1821 ms). Dec 14 20:26:29 localhost pulseaudio[4331]: alsa-util.c: Most likely this is a bug in the ALSA driver 'snd_via82xx'. Please report this issue to the ALSA developers. Dec 14 20:26:29 localhost pulseaudio[4331]: alsa-util.c: snd_pcm_dump(): Dec 14 20:26:29 localhost pulseaudio[4331]: alsa-util.c: Hardware PCM card 1 'VIA 8237' device 0 subdevice 0 Dec 14 20:26:29 localhost pulseaudio[4331]: alsa-util.c: Its setup is: Dec 14 20:26:29 localhost pulseaudio[4331]: alsa-util.c: stream : PLAYBACK Dec 14 20:26:29 localhost pulseaudio[4331]: alsa-util.c: access : MMAP_INTERLEAVED Dec 14 20:26:29 localhost pulseaudio[4331]: alsa-util.c: format : S16_LE Dec 14 20:26:29 localhost pulseaudio[4331]: alsa-util.c: subformat : STD Dec 14 20:26:29 localhost pulseaudio[4331]: alsa-util.c: channels : 2 Dec 14 20:26:29 localhost pulseaudio[4331]: alsa-util.c: rate : 48000 Dec 14 20:26:29 localhost pulseaudio[4331]: alsa-util.c: exact rate : 48000 (48000/1) Dec 14 20:26:29 localhost pulseaudio[4331]: alsa-util.c: msbits : 16 Dec 14 20:26:29 localhost pulseaudio[4331]: alsa-util.c: buffer_size : 16384 Dec 14 20:26:29 localhost pulseaudio[4331]: alsa-util.c: period_size : 8192 Dec 14 20:26:29 localhost pulseaudio[4331]: alsa-util.c: period_time : 170666 Dec 14 20:26:29 localhost pulseaudio[4331]: alsa-util.c: tstamp_mode : ENABLE Dec 14 20:26:29 localhost pulseaudio[4331]: alsa-util.c: period_step : 1 Dec 14 20:26:29 localhost pulseaudio[4331]: alsa-util.c: avail_min : 9665 Dec 14 20:26:29 localhost pulseaudio[4331]: alsa-util.c: period_event : 0 Dec 14 20:26:29 localhost pulseaudio[4331]: alsa-util.c: start_threshold : -1 Dec 14 20:26:29 localhost pulseaudio[4331]: alsa-util.c: stop_threshold : 1073741824 Dec 14 20:26:29 localhost pulseaudio[4331]: alsa-util.c: silence_threshold: 0 Dec 14 20:26:29 localhost pulseaudio[4331]: alsa-util.c: silence_size : 0 Dec 14 20:26:29 localhost pulseaudio[4331]: alsa-util.c: boundary : 1073741824 Dec 14 20:26:29 localhost pulseaudio[4331]: alsa-util.c: appl_ptr : 767919576 Dec 14 20:26:29 localhost pulseaudio[4331]: alsa-util.c: hw_ptr : 767990616 Dec 14 20:26:29 localhost pulseaudio[4331]: ratelimit.c: 7 events suppressed Dec 14 20:26:31 localhost pulseaudio[4331]: asyncq.c: q overrun, queuing locally I also see this quite frequently: Dec 14 20:15:29 localhost pulseaudio[4331]: asyncq.c: q overrun, queuing locally Dec 14 20:15:34 localhost pulseaudio[4331]: ratelimit.c: 657 events suppressed Dec 14 20:15:34 localhost pulseaudio[4331]: asyncq.c: q overrun, queuing locally Dec 14 20:15:39 localhost pulseaudio[4331]: ratelimit.c: 2508 events suppressed Dec 14 20:15:39 localhost pulseaudio[4331]: asyncq.c: q overrun, queuing locally Dec 14 20:15:44 localhost pulseaudio[4331]: ratelimit.c: 3530 events suppressed Dec 14 20:15:44 localhost pulseaudio[4331]: asyncq.c: q overrun, queuing locally Dec 14 20:15:44 localhost pulseaudio[4331]: asyncq.c: q overrun, queuing locally Dec 14 20:15:49 localhost pulseaudio[4331]: ratelimit.c: 2672 events suppressed Dec 14 20:15:49 localhost pulseaudio[4331]: asyncq.c: q overrun, queuing locally Dec 14 20:16:05 localhost pulseaudio[4331]: ratelimit.c: 2244 events suppressed Dec 14 20:16:18 localhost pulseaudio[4331]: ratelimit.c: 1 events suppressed Dec 14 20:16:23 localhost pulseaudio[4331]: ratelimit.c: 1 events suppressed Dec 14 20:16:34 localhost pulseaudio[4331]: ratelimit.c: 5 events suppressed Dec 14 20:16:39 localhost pulseaudio[4331]: ratelimit.c: 9 events suppressed Dec 14 20:16:45 localhost pulseaudio[4331]: ratelimit.c: 11 events suppressed Dec 14 20:16:50 localhost pulseaudio[4331]: ratelimit.c: 13 events suppressed Dec 14 20:16:55 localhost pulseaudio[4331]: ratelimit.c: 16 events suppressed Dec 14 20:17:01 localhost pulseaudio[4331]: ratelimit.c: 17 events suppressed Dec 14 20:17:06 localhost pulseaudio[4331]: ratelimit.c: 23 events suppressed Dec 14 20:17:11 localhost pulseaudio[4331]: ratelimit.c: 19 events suppressed Dec 14 20:17:31 localhost pulseaudio[4331]: ratelimit.c: 23 events suppressed Dec 14 20:17:36 localhost pulseaudio[4331]: ratelimit.c: 19 events suppressed Dec 14 20:17:42 localhost pulseaudio[4331]: ratelimit.c: 21 events suppressed Dec 14 20:17:47 localhost pulseaudio[4331]: ratelimit.c: 19 events suppressed I have pulseaudio enabled but have glitch-free mode disabled. Any assistance in troubleshooting this would be appreciated. Chris -- KeyID 0xE372A7DA98E6705C

3 22

[alsa-devel] [PATCH V2] Add i.MX sound support
by Sascha Hauer 08 Jan '10

08 Jan '10

Hi All, Here is the second version of the patches to add i.MX sound support. This time I haven't included ARM related patches, so this series should be safe to apply. I skipped the mc13783 driver since I'm not ready integrating the comments from Mark. The main change in the driver is that I splitted out the transport from the driver, so it should be easy to add another transport layer to the driver when SDMA support is merged. I hopefully also addressed the other comments from Mark. Sascha

3 20

[alsa-devel] [PATCH 0/5] ASoC: tlv320dac33: Adding new FIFO mode
by Peter Ujfalusi 04 Jan '10

04 Jan '10

Hello, the following series adds new FIFO operating mode to the tlv320dac33 codec driver. To be able to add new FIFO mode the code has to be restructured in order to keep it readable after the new mode is added. Since both of the support FIFO mode in the driver needs the codec to be the master, an additional check is added to avoid misconfiguration. --- Peter Ujfalusi (5): ASoC: tlv320dac33: Change nsample switch to FIFO mode enum ASoC: tlv320dac33: Introduce prefill and playback state handlers ASoC: tlv320dac33: Clean up the hardware configuration code ASoC: tlv320dac33: Add new FIFO mode: mode 7 ASoC: tlv320dac33: Safety check for codec slave mode sound/soc/codecs/tlv320dac33.c | 190 ++++++++++++++++++++++++++++++++-------- 1 files changed, 153 insertions(+), 37 deletions(-)

2 8