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

[alsa-devel] Asynchronous notification in ALSA - I/O Plugin - Pulseaudio
by Juha Erkkilä 22 May '08

22 May '08

I'm trying to get Abode Flash Player working properly on a thin client, with sound, using Pulseaudio as a sound server. I'm using ALSA version 1.10.15 and Pulseaudio version 0.9.10 on Ubuntu Hardy, with Pulseaudio server running as a system-wide daemon on the thin client. I already outlined the issues on Pulseaudio mailing list on this post: https://tango.0pointer.de/pipermail/pulseaudio-discuss/2008-May/001793.html, see also Lennart Poettering's answer: https://tango.0pointer.de/pipermail/pulseaudio-discuss/2008-May/001796.html. I feel the proper solution would involve writing support for asynchronous notification into ALSA library and I/O-plugin layer. Currently, Pulse I/O-plugin does not work in the Flash case, because Flash requires the asynchronous API. On the other hand, Pulse requires the I/O-plugin layer to work. See the posts by Alexander Indenbaum, http://mailman.alsa-project.org/pipermail/alsa-devel/2008-April/007033.html, and Takashi Iwai, http://mailman.alsa-project.org/pipermail/alsa-devel/2008-April/007335.html, on this subject. I tried to tackle this issue, and did get the signal handling code to call the Flash audio callback, but I'm new to both ALSA and Pulseaudio, and it appears there are some issues with it I don't fully understand. Thus I'm asking: are there any other people who have been looking into this, or anyone who can tell whether this is a sane thing to do or not, will it require some nasty hack, or can help with some pointers to relevant information? I'm hoping that implementing the asynchronous API on I/O-plugin layer would not only fix Flash audio, but might help some other programs too to achieve network transparent audio. Juha

3 5

[alsa-devel] Will ALSA ever call _prepare or _hw_params while it's playing?
by Timur Tabi 21 May '08

21 May '08

I have an ASoC driver with a _hw_params, _prepare, and _trigger functions. I've recently discovered that I need to keep one of my devices disabled until playback starts. So I would like to know if ALSA will ever call _hw_params, _prepare, or _startup if playback or capture is currently in process, or will ALSA first call the _trigger to stop/pause the driver. If ALSA does stop/pause the driver before changing parameters, then I can safely assume the device is always disabled during those functions. -- Timur Tabi Linux kernel developer at Freescale

2 2

[alsa-devel] Possible problem with snd_pcm_oss_sync()
by Timur Tabi 21 May '08

21 May '08

-------- Original Message -------- Subject: RE: Regarding MPC8610 BSP question and issue Date: Tue, 20 May 2008 08:55:46 -0700 From: Hayasaka Manabu <manabu.hayasaka(a)freescale.com> To: Hayasaka Manabu <manabu.hayasaka(a)freescale.com>, Johnson Kelly <Kelly.Johnson(a)freescale.com> CC: sun york <yorksun(a)freescale.com>, Namiki Ayumi <namiki(a)freescale.com>, Beck Glenn <Glenn.Beck(a)freescale.com>, Cox Kevin <K.Cox(a)freescale.com>, Hamano Masahiro <M.Hamano(a)freescale.com>, Tabi Timur <timur(a)freescale.com> References: <E03EE6E38549E949AE8138F60493E1E801C49A0C(a)zja67exm20.fsl.freescale.net> <4807899D.3000901(a)freescale.com> <E03EE6E38549E949AE8138F60493E1E801DA1B11(a)zja67exm20.fsl.freescale.net> <48110FCF.7070302(a)freescale.com> <BD243C8D8F65694A966948E9D51F9815C29409(a)zja67exm21.fsl.freescale.net> <48189540.9060309(a)freescale.com> <BD243C8D8F65694A966948E9D51F9815C29422(a)zja67exm21.fsl.freescale.net> <E03EE6E38549E949AE8138F60493E1E801DA25D9(a)zja67exm20.fsl.freescale.net> <4821CA02.2020504(a)freescale.com> <E03EE6E38549E949AE8138F60493E1E801FA11C8(a)zja67exm20.fsl.freescale.net> <4829C444.7010206(a)freescale.com> <E03EE6E38549E949AE8138F60493E1E801FA13D2(a)zja67exm20.fsl.freescale.net> <482B1D10.7090402(a)freescale.com> <482B2699.8020409(a)freescale.com> I'm working with a customer that has discovered a possible problem with OSS emulation. Unfortunately, I don't have a lot of experience with OSS, so I need help understanding whether the customer's observations point to a real problem or not. The customer is using an old application called "bplay" to test OSS audio support on our hardware. The application works fine on x86, but fails on our PowerPC board. It could be an endian issue, but I doubt it. Here is the forwarded email (slightly edited). Can someone familiar with the OSS "sync" functionality comment? --------------- They reported that it seemed some ioctl commands in the OSS emulation did not work correctly. The tested procedure of the ioctl commands are as following, #1) Stopped audio stream output after doing followings: 1. Opening /dev/mixer 2. Getting a channel value (0x00000001) that is used for "ioctl(fd, SOUND_MIXER_READ_DEVMASK, &Sndsts);". 3. Write audio volume information by "ioctl(fd, SOUND_MIXER_WRITE_VOLUME, &Value);", #2) Stopped audio stream output after doing following: 1. Opening /dev/dsp 2. Executing command "ioctl(fd, SNDCTL_DSP_SYNC, NULL);", XXXX found that by commenting out the "sync_audio" function on the source code of "bplay" made "bplay" work. So XXXX suspects the implementation of the ioctl on the OSS emulation may have a problem. -- Timur Tabi Linux kernel developer at Freescale

3 4

[alsa-devel] AC'97 recording on AT91sam9263
by Sedji Gaouaou 21 May '08

21 May '08

Hi, I am trying to write the AC'97 driver(recording) and I encounter some problems. I would like to set up some constraints but if I do so I will have a seg fault when running arecord. here is my open function: /* define the constraints */ static unsigned int rates[] = { 8000, 44100, }; static struct snd_pcm_hw_constraint_list hw_constraints_rates = { .count = ARRAY_SIZE(rates), .list = rates, .mask = 0, }; ... static int snd_at91_ac97_capture_open(struct snd_pcm_substream *substream) { at91_ac97_t *chip = snd_pcm_substream_chip(substream); struct snd_pcm_runtime *runtime = substream->runtime; int err; runtime->hw = snd_at91_ac97_capture_hw; chip->capture_substream = substream; chip->period = 0; if ((err = snd_pcm_hw_constraint_list(runtime, 0, SNDRV_PCM_HW_PARAM_RATE, &hw_constraints_rates)) < 0) return err; snd_printd(KERN_DEBUG "%s : snd_at91_ac97_capture_open\n\r", driver_name); return 0; } I have another problem if I try to set up some constraint on the format. Indeed I do exactly the same as for the rate, but then it will fail in aplay.c in the function set_params, returning the error message:"Broken configuration for this PCM: no configuration available." Do I miss something when trying to set up the constraints? Is there any particular way for setting the format constraints? Regards, Sedji

1 0

[alsa-devel] External Plugin Non-Interleaved
by Charles Eidsness 21 May '08

21 May '08

I'm working on a small ALSA pcm/ctl plugin to add support for LADSPA modules that include real-time controls (unless I'm missing something it looks like the native ALSA LADSPA module doesn't include real-time adjustable controls). I want to use it as a system wide equalizer. I'm using snd_pcm_extplug, I want to force access to be non-interleaved only but I can't figure out how. Is there some way to force non-interleaved access for an extplug? If you're interested you can find the first pass of my plugin here: http://www.thedigitalmachine.net/alsaequal.html Thanks, Charles

2 2

[alsa-devel] Kernel crash in snd-aloop
by Benjamin van den Hout 21 May '08

21 May '08

Hello all, Thanks to the excellent advice here on the list, I'm one step further with getting my project running with the snd-aloop driver! Now I'm looking to scale my solution to more concurrent users. If I check aloop-kernel.c (in the alsa 10.0.16 release tarball), there are two lines that interest me: #define MAX_PCM_SUBSTREAMS 8 and static int pcm_substreams[SNDRV_CARDS] = {[0 ... (SNDRV_CARDS - 1)] = 8}; The standard aloop driver supplies 8 loopback devices; I need to have more, so I changed both occurences of '8' to 16 and there are no problems. I'm bundling all these subdevices with a 'type multi' in .asoundrc to one device that is used as a JACK backend. So far so good! If I change the 16 to 32 (and modifying .asoundrc to bundle all 32 devices to the 'multi' device) however, restarting JACK will sometimes panic my kernel. I'm running a stock 2.6.22-4 kernel (64 bit) and this is the oops output (redirected to a serial console luckily, otherwise it would be a lot of typing): ----Start oops output---- ALSA */home/benjamin/alsa/alsa-driver-1.0.16/acore/*..*/alsa-kernel/core/*pcm_lib.c) Call Trace: <IRQ> [<ffffffff8023a720>] run_timer_softirq+0x15b/0x1cf [<ffffffff8023723b>] __do_softirq+0x49/0xb8 [<ffffffff8020affc>] call_softirq+0x1c/0x28 [<ffffffff8020ca75>] do_softirq+0x2c/0x7d [<ffffffff802371e6>] irq_exit+0x36/0x42 [<ffffffff8021a549>] smp_apic_timer_interrupt+0x49/0x5c [<ffffffff80208e05>] mwait_idle+0x0/0x45 [<ffffffff80208e05>] mwait_idle+0x0/0x45 [<ffffffff8020aaa6>] apic_timer_interrupt+0x66/0x70 <EOI> [<ffffffff80208e47>] mwait_idle+0x42/0x45 [<ffffffff80208d89>] cpu_idle+0x88/0xbf ALSA */home/benjamin/alsa/alsa-driver-1.0.16/acore/*..*/alsa-kernel/core/*pcm_lib.c) Call Trace: <IRQ> [<ffffffff8023a720>] run_timer_softirq+0x15b/0x1cf [<ffffffff8023723b>] __do_softirq+0x49/0xb8 [<ffffffff8020affc>] call_softirq+0x1c/0x28 [<ffffffff8020ca75>] do_softirq+0x2c/0x7d [<ffffffff802371e6>] irq_exit+0x36/0x42 [<ffffffff8021a549>] smp_apic_timer_interrupt+0x49/0x5c [<ffffffff80208e05>] mwait_idle+0x0/0x45 [<ffffffff8020aaa6>] apic_timer_interrupt+0x66/0x70 <EOI> ALSA */home/benjamin/alsa/alsa-driver-1.0.16/acore/*..*/alsa-kernel/core/*pcm_lib.c) Call Trace: <IRQ> [<ffffffff8023a720>] run_timer_softirq+0x15b/0x1cf [<ffffffff8023723b>] __do_softirq+0x49/0xb8 [<ffffffff8020affc>] call_softirq+0x1c/0x28 [<ffffffff8020ca75>] do_softirq+0x2c/0x7d [<ffffffff802371e6>] irq_exit+0x36/0x42 [<ffffffff8021a549>] smp_apic_timer_interrupt+0x49/0x5c [<ffffffff80208e05>] mwait_idle+0x0/0x45 [<ffffffff8020aaa6>] apic_timer_interrupt+0x66/0x70 <EOI> ALSA */home/benjamin/alsa/alsa-driver-1.0.16/acore/*..*/alsa-kernel/core/*pcm_lib.c) Call Trace: <IRQ> [<ffffffff8023a720>] run_timer_softirq+0x15b/0x1cf [<ffffffff8023723b>] __do_softirq+0x49/0xb8 [<ffffffff8020affc>] call_softirq+0x1c/0x28 [<ffffffff8020ca75>] do_softirq+0x2c/0x7d [<ffffffff802371e6>] irq_exit+0x36/0x42 [<ffffffff8021a549>] smp_apic_timer_interrupt+0x49/0x5c [<ffffffff80208e05>] mwait_idle+0x0/0x45 [<ffffffff80208e05>] mwait_idle+0x0/0x45 [<ffffffff8020aaa6>] apic_timer_interrupt+0x66/0x70 <EOI> [<ffffffff80208e47>] mwait_idle+0x42/0x45 [<ffffffff80208d89>] cpu_idle+0x88/0xbf ALSA */home/benjamin/alsa/alsa-driver-1.0.16/acore/*..*/alsa-kernel/core/*pcm_lib.c) Call Trace: <IRQ> [<ffffffff8023a720>] run_timer_softirq+0x15b/0x1cf [<ffffffff8023723b>] __do_softirq+0x49/0xb8 [<ffffffff8020affc>] call_softirq+0x1c/0x28 [<ffffffff8020ca75>] do_softirq+0x2c/0x7d [<ffffffff802371e6>] irq_exit+0x36/0x42 [<ffffffff8021a549>] smp_apic_timer_interrupt+0x49/0x5c [<ffffffff80208e05>] mwait_idle+0x0/0x45 [<ffffffff80208e05>] mwait_idle+0x0/0x45 [<ffffffff8020aaa6>] apic_timer_interrupt+0x66/0x70 <EOI> [<ffffffff80208e47>] mwait_idle+0x42/0x45 [<ffffffff80208d89>] cpu_idle+0x88/0xbf ALSA */home/benjamin/alsa/alsa-driver-1.0.16/acore/*..*/alsa-kernel/core/*pcm_lib.c) Call Trace: <IRQ> [<ffffffff8023a720>] run_timer_softirq+0x15b/0x1cf [<ffffffff8023723b>] __do_softirq+0x49/0xb8 [<ffffffff8020affc>] call_softirq+0x1c/0x28 [<ffffffff8020ca75>] do_softirq+0x2c/0x7d [<ffffffff802371e6>] irq_exit+0x36/0x42 [<ffffffff8021a549>] smp_apic_timer_interrupt+0x49/0x5c [<ffffffff80208e05>] mwait_idle+0x0/0x45 [<ffffffff8020aaa6>] apic_timer_interrupt+0x66/0x70 <EOI> ALSA */home/benjamin/alsa/alsa-driver-1.0.16/acore/*..*/alsa-kernel/core/*pcm_lib.c) Call Trace: <IRQ> [<ffffffff8023a720>] run_timer_softirq+0x15b/0x1cf [<ffffffff8023723b>] __do_softirq+0x49/0xb8 [<ffffffff8020affc>] call_softirq+0x1c/0x28 [<ffffffff8020ca75>] do_softirq+0x2c/0x7d [<ffffffff802371e6>] irq_exit+0x36/0x42 [<ffffffff8021a549>] smp_apic_timer_interrupt+0x49/0x5c [<ffffffff80208e05>] mwait_idle+0x0/0x45 [<ffffffff80208e05>] mwait_idle+0x0/0x45 [<ffffffff8020aaa6>] apic_timer_interrupt+0x66/0x70 <EOI> [<ffffffff80208e47>] mwait_idle+0x42/0x45 [<ffffffff80208d89>] cpu_idle+0x88/0xbf ALSA */home/benjamin/alsa/alsa-driver-1.0.16/acore/*..*/alsa-kernel/core/*pcm_lib.c) Call Trace: <IRQ> [<ffffffff8023a720>] run_timer_softirq+0x15b/0x1cf [<ffffffff8023723b>] __do_softirq+0x49/0xb8 [<ffffffff8020affc>] call_softirq+0x1c/0x28 [<ffffffff8020ca75>] do_softirq+0x2c/0x7d [<ffffffff802371e6>] irq_exit+0x36/0x42 [<ffffffff8021a549>] smp_apic_timer_interrupt+0x49/0x5c [<ffffffff80208e05>] mwait_idle+0x0/0x45 [<ffffffff80208e05>] mwait_idle+0x0/0x45 [<ffffffff8020aaa6>] apic_timer_interrupt+0x66/0x70 <EOI> [<ffffffff80208e47>] mwait_idle+0x42/0x45 [<ffffffff80208d89>] cpu_idle+0x88/0xbf ALSA */home/benjamin/alsa/alsa-driver-1.0.16/acore/*..*/alsa-kernel/core/*pcm_lib.c) Call Trace: <IRQ> [<ffffffff8023a720>] run_timer_softirq+0x15b/0x1cf [<ffffffff8023723b>] __do_softirq+0x49/0xb8 [<ffffffff8020affc>] call_softirq+0x1c/0x28 [<ffffffff8020ca75>] do_softirq+0x2c/0x7d [<ffffffff802371e6>] irq_exit+0x36/0x42 [<ffffffff8021a549>] smp_apic_timer_interrupt+0x49/0x5c [<ffffffff80208e05>] mwait_idle+0x0/0x45 [<ffffffff8020aaa6>] apic_timer_interrupt+0x66/0x70 <EOI> ALSA */home/benjamin/alsa/alsa-driver-1.0.16/acore/*..*/alsa-kernel/core/*pcm_lib.c) Call Trace: <IRQ> [<ffffffff8023a720>] run_timer_softirq+0x15b/0x1cf [<ffffffff8023723b>] __do_softirq+0x49/0xb8 [<ffffffff8020affc>] call_softirq+0x1c/0x28 [<ffffffff8020ca75>] do_softirq+0x2c/0x7d [<ffffffff802371e6>] irq_exit+0x36/0x42 [<ffffffff8021a549>] smp_apic_timer_interrupt+0x49/0x5c [<ffffffff80208e05>] mwait_idle+0x0/0x45 [<ffffffff8020aaa6>] apic_timer_interrupt+0x66/0x70 <EOI> [<ffffffff8026669d>] get_page_from_freelist+0x2b/0x534 [<ffffffff80266d0b>] __alloc_pages+0x5a/0x2bc [<ffffffff8026664f>] get_zeroed_page+0x11/0x34 [<ffffffff8026eba6>] __pte_alloc+0x1a/0xb8 [<ffffffff8026ed7f>] __handle_mm_fault+0x13b/0xa35 [<ffffffff80220e9a>] do_page_fault+0x42b/0x7ad [<ffffffff80273f66>] do_mmap_pgoff+0x60a/0x776 [<ffffffff803fe7dd>] error_exit+0x0/0x84 ALSA */home/benjamin/alsa/alsa-driver-1.0.16/acore/*..*/alsa-kernel/core/*pcm_lib.c) Call Trace: <IRQ> [<ffffffff8023a720>] run_timer_softirq+0x15b/0x1cf [<ffffffff8023723b>] __do_softirq+0x49/0xb8 [<ffffffff8020affc>] call_softirq+0x1c/0x28 [<ffffffff8020ca75>] do_softirq+0x2c/0x7d [<ffffffff802371e6>] irq_exit+0x36/0x42 [<ffffffff8021a549>] smp_apic_timer_interrupt+0x49/0x5c [<ffffffff80208e05>] mwait_idle+0x0/0x45 [<ffffffff8020aaa6>] apic_timer_interrupt+0x66/0x70 <EOI> ALSA */home/benjamin/alsa/alsa-driver-1.0.16/acore/*..*/alsa-kernel/core/*pcm_lib.c) Call Trace: <IRQ> [<ffffffff8023a720>] run_timer_softirq+0x15b/0x1cf [<ffffffff8023723b>] __do_softirq+0x49/0xb8 [<ffffffff8020affc>] call_softirq+0x1c/0x28 [<ffffffff8020ca75>] do_softirq+0x2c/0x7d [<ffffffff802371e6>] irq_exit+0x36/0x42 [<ffffffff8021a549>] smp_apic_timer_interrupt+0x49/0x5c [<ffffffff80208e05>] mwait_idle+0x0/0x45 [<ffffffff80208e05>] mwait_idle+0x0/0x45 [<ffffffff8020aaa6>] apic_timer_interrupt+0x66/0x70 <EOI> [<ffffffff80208e47>] mwait_idle+0x42/0x45 [<ffffffff80208d89>] cpu_idle+0x88/0xbf ALSA */home/benjamin/alsa/alsa-driver-1.0.16/acore/*..*/alsa-kernel/core/*pcm_lib.c) Call Trace: <IRQ> [<ffffffff8023a720>] run_timer_softirq+0x15b/0x1cf [<ffffffff8023723b>] __do_softirq+0x49/0xb8 [<ffffffff8020affc>] call_softirq+0x1c/0x28 [<ffffffff8020ca75>] do_softirq+0x2c/0x7d [<ffffffff802371e6>] irq_exit+0x36/0x42 [<ffffffff8021a549>] smp_apic_timer_interrupt+0x49/0x5c [<ffffffff80208e05>] mwait_idle+0x0/0x45 [<ffffffff8020aaa6>] apic_timer_interrupt+0x66/0x70 <EOI> [<ffffffff8026e33b>] unmap_vmas+0x3a0/0x741 [<ffffffff8026e26e>] unmap_vmas+0x2d3/0x741 [<ffffffff80272394>] exit_mmap+0x80/0x117 [<ffffffff8022fdfe>] mmput+0x2c/0x9e [<ffffffff8028aee7>] flush_old_exec+0x69d/0x9b6 [<ffffffff8028702b>] vfs_read+0x13f/0x153 [<ffffffff802b60e2>] load_elf_binary+0x462/0x1979 [<ffffffff80244a85>] autoremove_wake_function+0x0/0x2e [<ffffffff80266d0b>] __alloc_pages+0x5a/0x2bc [<ffffffff802b5c80>] load_elf_binary+0x0/0x1979 [<ffffffff8028a135>] search_binary_handler+0xf1/0x27e [<ffffffff8028bbae>] do_execve+0x188/0x231 [<ffffffff80208b6f>] sys_execve+0x36/0x90 [<ffffffff8020a207>] stub_execve+0x67/0xb0 ALSA */home/benjamin/alsa/alsa-driver-1.0.16/acore/*..*/alsa-kernel/core/*pcm_lib.c) Call Trace: <IRQ> [<ffffffff8023a720>] run_timer_softirq+0x15b/0x1cf [<ffffffff8023723b>] __do_softirq+0x49/0xb8 [<ffffffff8020affc>] call_softirq+0x1c/0x28 [<ffffffff8020ca75>] do_softirq+0x2c/0x7d [<ffffffff802371e6>] irq_exit+0x36/0x42 [<ffffffff8021a549>] smp_apic_timer_interrupt+0x49/0x5c [<ffffffff80208e05>] mwait_idle+0x0/0x45 [<ffffffff8020aaa6>] apic_timer_interrupt+0x66/0x70 <EOI> ALSA */home/benjamin/alsa/alsa-driver-1.0.16/acore/*..*/alsa-kernel/core/*pcm_lib.c) Call Trace: <IRQ> [<ffffffff8023a720>] run_timer_softirq+0x15b/0x1cf [<ffffffff8023723b>] __do_softirq+0x49/0xb8 [<ffffffff8020affc>] call_softirq+0x1c/0x28 [<ffffffff8020ca75>] do_softirq+0x2c/0x7d [<ffffffff802371e6>] irq_exit+0x36/0x42 [<ffffffff8021a549>] smp_apic_timer_interrupt+0x49/0x5c [<ffffffff80208e05>] mwait_idle+0x0/0x45 [<ffffffff8020aaa6>] apic_timer_interrupt+0x66/0x70 <EOI> [<ffffffff8026655a>] free_hot_cold_page+0x135/0x167 [<ffffffff802665ad>] __pagevec_free+0x21/0x2e [<ffffffff80268e15>] release_pages+0x123/0x169 [<ffffffff8026945d>] __pagevec_release+0x19/0x22 [<ffffffff80269988>] truncate_inode_pages_range+0xc5/0x28d [<ffffffff8027ffd2>] shmem_delete_inode+0x3f/0xe7 [<ffffffff8027ff93>] shmem_delete_inode+0x0/0xe7 [<ffffffff802991a7>] generic_delete_inode+0xc5/0x13d [<ffffffff80296307>] d_kill+0x38/0x59 [<ffffffff80296435>] dput+0x10d/0x119 [<ffffffff802877dd>] __fput+0x145/0x16e [<ffffffff802d1141>] shm_destroy+0x41/0x5a [<ffffffff802d1e5f>] sys_shmctl+0x49d/0x632 [<ffffffff8023d659>] sys_kill+0x133/0x15c [<ffffffff80286ed7>] vfs_write+0x142/0x157 [<ffffffff802873c1>] sys_write+0x45/0x6e [<ffffffff80209e3e>] system_call+0x7e/0x83 ALSA */home/benjamin/alsa/alsa-driver-1.0.16/acore/*..*/alsa-kernel/core/*pcm_lib.c) Call Trace: <IRQ> [<ffffffff8023a720>] run_timer_softirq+0x15b/0x1cf [<ffffffff8023723b>] __do_softirq+0x49/0xb8 [<ffffffff8020affc>] call_softirq+0x1c/0x28 [<ffffffff8020ca75>] do_softirq+0x2c/0x7d [<ffffffff802371e6>] irq_exit+0x36/0x42 [<ffffffff8021a549>] smp_apic_timer_interrupt+0x49/0x5c [<ffffffff80208e05>] mwait_idle+0x0/0x45 [<ffffffff80208e05>] mwait_idle+0x0/0x45 [<ffffffff8020aaa6>] apic_timer_interrupt+0x66/0x70 <EOI> [<ffffffff80208e47>] mwait_idle+0x42/0x45 [<ffffffff80208d89>] cpu_idle+0x88/0xbf divide error: 0000 [1] PREEMPT SMP CPU 2 Modules linked in: snd_aloop snd_pcm_oss snd_mixer_oss snd_pcm snd_timer snd snn Pid: 0, comm: swapper Not tainted 2.6.22-4-amd64-preempt-blktrace #1 RIP: 0010:[<ffffffff882e73dd>] [<ffffffff882e73dd>] :snd_aloop:snd_card_loopba0 RSP: 0018:ffff81042faefed0 EFLAGS: 00010046 RAX: 0000000000000000 RBX: ffff810404cd78a8 RCX: 00000001003d172d RDX: 0000000000000000 RSI: 0000000000000217 RDI: 0000000000000001 RBP: ffff810404cd78b0 R08: 0000000000000091 R09: 00000001003d172d R10: 0000000000000000 R11: 0000000000000217 R12: ffff81042fadc000 R13: ffffffff882e7391 R14: 0000000000000000 R15: 0000000000000000 FS: 0000000000000000(0000) GS:ffff81042fa7d440(0000) knlGS:0000000000000000 CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b CR2: 00000000005b2b50 CR3: 0000000000201000 CR4: 00000000000006e0 Process swapper (pid: 0, threadinfo ffff81042fae8000, task ffff81042fae75a0) Stack: ffff810404cd78a8 ffff810404cd78a8 0000000000000102 ffffffff8023a720 ffff81042faefef0 ffff81042faefef0 0000012c0000000a 0000000000000021 ffffffff804f1110 000000000000000a 0000000000000002 ffffffff8023723b Call Trace: <IRQ> [<ffffffff8023a720>] run_timer_softirq+0x15b/0x1cf [<ffffffff8023723b>] __do_softirq+0x49/0xb8 [<ffffffff8020affc>] call_softirq+0x1c/0x28 [<ffffffff8020ca75>] do_softirq+0x2c/0x7d [<ffffffff802371e6>] irq_exit+0x36/0x42 [<ffffffff8021a549>] smp_apic_timer_interrupt+0x49/0x5c [<ffffffff80208e05>] mwait_idle+0x0/0x45 [<ffffffff80208e05>] mwait_idle+0x0/0x45 [<ffffffff8020aaa6>] apic_timer_interrupt+0x66/0x70 <EOI> [<ffffffff80208e47>] mwait_idle+0x42/0x45 [<ffffffff80208d89>] cpu_idle+0x88/0xbf Code: f7 73 64 8b 4b 68 89 93 80 00 00 00 8b 53 7c 39 ca 72 35 89 RIP [<ffffffff882e73dd>] :snd_aloop:snd_card_loopback_timer_function+0x4c/0xa0 RSP <ffff81042faefed0> Kernel panic - not syncing: Aiee, killing interrupt handler! Unable to handle kernel paging request at ffff81042af0c800 RIP: [<ffff81042af0c800>] PGD 8063 PUD 19063 PMD 800000042ae001e3 PTE 0 Oops: 0011 [2] PREEMPT SMP CPU 2 Modules linked in: snd_aloop snd_pcm_oss snd_mixer_oss snd_pcm snd_timer snd snn Pid: 0, comm: swapper Not tainted 2.6.22-4-amd64-preempt-blktrace #1 RIP: 0010:[<ffff81042af0c800>] [<ffff81042af0c800>] RSP: 0018:ffff81042faefb60 EFLAGS: 00010003 RAX: ffff81042fae9fd8 RBX: 0000000000000000 RCX: 0000000000000000 RDX: ffffffff8059e900 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ffff81042faefb90 R08: 0000000000000000 R09: ffff81042af0c800 R10: ffffffff8046d656 R11: 00000000000000fc R12: ffff81042af0c800 R13: 0000000000000000 R14: 000000000000000b R15: 0000000000000000 FS: 0000000000000000(0000) GS:ffff81042fa7d440(0000) knlGS:0000000000000000 CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b CR2: ffff81042af0c800 CR3: 0000000000201000 CR4: 00000000000006e0 Process swapper (pid: 0, threadinfo ffff81042fae8000, task ffff81042fae75a0) Stack: ffffffff802189f1 ffffffff8046d636 ffff81042fae75a0 ffffffff80468144 ffffffff8020a9c6 ffff81042faefb90 0000000000000000 00000000000000fc ffffffff8046d656 ffff81042af0c800 0000000000000000 ffffffff8037f3ca Call Trace: <IRQ> [<ffffffff802189f1>] smp_call_function_interrupt+0x40/0x5e [<ffffffff8020a9c6>] call_function_interrupt+0x66/0x70 [<ffffffff8037f3ca>] i8042_panic_blink+0x1/0x147 [<ffffffff80232206>] panic+0x126/0x148 [<ffffffff80232193>] panic+0xb3/0x148 [<ffffffff802298b0>] __wake_up_common+0x3e/0x68 [<ffffffff802352ec>] do_exit+0x8a/0x849 [<ffffffff8020b964>] kernel_math_error+0x0/0x71 [<ffffffff882e7391>] :snd_aloop:snd_card_loopback_timer_function+0x0/0xa0 [<ffffffff8020be38>] do_divide_error+0x7f/0x89 [<ffffffff882e73dd>] :snd_aloop:snd_card_loopback_timer_function+0x4c/0xa0 [<ffffffff882e7391>] :snd_aloop:snd_card_loopback_timer_function+0x0/0xa0 [<ffffffff80232b1f>] printk+0x4e/0x56 [<ffffffff8024d569>] __module_text_address+0x5e/0x68 [<ffffffff803fe7dd>] error_exit+0x0/0x84 [<ffffffff882e7391>] :snd_aloop:snd_card_loopback_timer_function+0x0/0xa0 [<ffffffff882e73dd>] :snd_aloop:snd_card_loopback_timer_function+0x4c/0xa0 [<ffffffff8023a720>] run_timer_softirq+0x15b/0x1cf [<ffffffff8023723b>] __do_softirq+0x49/0xb8 [<ffffffff8020affc>] call_softirq+0x1c/0x28 [<ffffffff8020ca75>] do_softirq+0x2c/0x7d [<ffffffff802371e6>] irq_exit+0x36/0x42 [<ffffffff8021a549>] smp_apic_timer_interrupt+0x49/0x5c [<ffffffff80208e05>] mwait_idle+0x0/0x45 [<ffffffff80208e05>] mwait_idle+0x0/0x45 [<ffffffff8020aaa6>] apic_timer_interrupt+0x66/0x70 <EOI> [<ffffffff80208e47>] mwait_idle+0x42/0x45 [<ffffffff80208d89>] cpu_idle+0x88/0xbf Code: 00 00 00 00 00 00 00 00 00 a0 f2 2b 04 81 ff ff 00 20 18 29 RIP [<ffff81042af0c800>] RSP <ffff81042faefb60> CR2: ffff81042af0c800 Kernel panic - not syncing: Aiee, killing interrupt handler! ----End oops output---- This crash can be reproduced by automatically restarting jackd in a 'while true' loop and simultaneously killing it every 0.5 seconds from a different terminal. That seems like a nasty thing to do, but I have had it happen some times when jackd was running for a few hours and I needed to restart it for testing something else. Sometimes it takes down the machine, sometimes it doesn't. This constant starting/killing will reproduce it within a minute or so. I'm convinced that jackd should never be able to crash the kernel right? Is there anything I'm missing here by blindly changing the value from 16 to 32, anything else I need to consider? Any input is greatly appreciated. Thanks in advance! Kind regards, Benjamin

1 0

[alsa-devel] [PATCH][ASoC V2] Fix null-pointer dereference in soc_create_pcm()
by Timur Tabi 21 May '08

21 May '08

When soc_create_pcm() finds all four components it needs, it displays a status message. This message references the local variables 'codec_dai' and 'cpu_dai', but these variables are initialized only when the codec DAI and the cpu DAI are the last to be registered. This patch changes the code to use the stored values instead of the local variables. Signed-off-by: Timur Tabi <timur(a)freescale.com> --- sound/soc/soc-core.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/sound/soc/soc-core.c b/sound/soc/soc-core.c index 7dc6d68..520469b 100644 --- a/sound/soc/soc-core.c +++ b/sound/soc/soc-core.c @@ -921,8 +921,8 @@ check: } pcm->private_free = platform->pcm_free; - printk(KERN_INFO "asoc: %s <-> %s mapping ok\n", codec_dai->name, - cpu_dai->name); + printk(KERN_INFO "asoc: %s <-> %s mapping ok\n", + pcm_runtime->codec_dai->name, pcm_runtime->cpu_dai->name); list_add(&pcm_runtime->list, &soc_card->pcm_list); return 1; err: -- 1.5.5

3 4

[alsa-devel] MIDI on ice1724 - preliminary findings and questions
by Pavel Hofman 20 May '08

20 May '08

Hi, I am trying to fix the ancient MIDI problem with ice1724 cards. I applied Takashi's patch from http://mailman.alsa-project.org/pipermail/alsa-devel/2007-April/000641.html and made some minor changes (MPU401_INFO_INPUT | MPU401_INFO_OUTPUT to mpu401_uart info_flags, added a few debugs for testing). I can test only MIDI input using my MIDI keyboard, I have no MIDI output device available. The input works fine now, the output most probably too since the method snd_vt1724_mpu401_write gets called when transmitting some data with amidi. But here is the problem I do not understand: When no MIDI input/output is used, the interrupt handler snd_vt1724_interrupt gets called with interrupt status 0x10 which correctly refers to the audio data interrupt (VT1724_IRQ_MTPCM). However, when MIDI input or output is used (opened) even for a short time after the module is loaded, any subsequent audio playback generates interrupt status of 0x30 which refers to VT1724_IRQ_MTPCM AND VT1724_IRQ_MPU_TX. I have no idea why VT1724_IRQ_MPU_TX gets generated. The first run of the snd_vt1724_interrupt loop tries to handle the MPU TX status, calling uart_interrupt_tx in mpu401_uart.c: if (test_bit(MPU401_MODE_BIT_OUTPUT, &mpu->mode) && test_bit(MPU401_MODE_BIT_OUTPUT_TRIGGER, &mpu->mode)) { spin_lock_irqsave(&mpu->output_lock, flags); snd_mpu401_uart_output_write(mpu); spin_unlock_irqrestore(&mpu->output_lock, flags); } However, since the MPU output is not open at this time (no MIDI is being transmitted), the call to snd_mpu401_uart_output_write is skipped. Even though I think the interrupt status should get cleared by outb(status, ICEREG1724(ice, IRQSTAT)) the loop repeats with the MPU TX interrupt status enabled until the timeout check breaks the while loop, returning to the interrupt handler the next moment again. Apr 19 22:20:47 nahore kernel: [ 2402.938245] uart interrupt: status 0x30 Apr 19 22:20:47 nahore kernel: [ 2402.938260] uart interrupt: status 0x20 Apr 19 22:20:47 nahore kernel: [ 2402.938267] uart interrupt: status 0x20 Apr 19 22:20:47 nahore kernel: [ 2402.938274] uart interrupt: status 0x20 Apr 19 22:20:47 nahore kernel: [ 2402.938281] uart interrupt: status 0x20 Apr 19 22:20:47 nahore kernel: [ 2402.938288] uart interrupt: status 0x20 Apr 19 22:20:47 nahore kernel: [ 2402.938295] uart interrupt: status 0x20 Apr 19 22:20:47 nahore kernel: [ 2402.938302] uart interrupt: status 0x20 Apr 19 22:20:47 nahore kernel: [ 2402.938309] uart interrupt: status 0x20 Apr 19 22:20:47 nahore kernel: [ 2402.938316] uart interrupt: status 0x20 Apr 19 22:20:47 nahore kernel: [ 2402.938323] uart interrupt: status 0x20 Apr 19 22:20:47 nahore kernel: [ 2402.938326] ice1724: Too long irq loop, status = 0x20 Apr 19 22:20:47 nahore kernel: [ 2402.961247] uart interrupt: status 0x30 Apr 19 22:20:47 nahore kernel: [ 2402.961278] uart interrupt: status 0x20 Apr 19 22:20:47 nahore kernel: [ 2402.961285] uart interrupt: status 0x20 Apr 19 22:20:47 nahore kernel: [ 2402.961292] uart interrupt: status 0x20 Apr 19 22:20:47 nahore kernel: [ 2402.961299] uart interrupt: status 0x20 Apr 19 22:20:47 nahore kernel: [ 2402.961306] uart interrupt: status 0x20 Apr 19 22:20:47 nahore kernel: [ 2402.961313] uart interrupt: status 0x20 Apr 19 22:20:47 nahore kernel: [ 2402.961320] uart interrupt: status 0x20 Apr 19 22:20:47 nahore kernel: [ 2402.961327] uart interrupt: status 0x20 Apr 19 22:20:47 nahore kernel: [ 2402.961334] uart interrupt: status 0x20 Apr 19 22:20:47 nahore kernel: [ 2402.961341] uart interrupt: status 0x20 Apr 19 22:20:47 nahore kernel: [ 2402.961344] ice1724: Too long irq loop, status = 0x20 After the playback stops, the interrupts are gone too. It seems as if the playback interrupt initiates the MPU TX interrupt. If we could avoid generating the MPU TX interrupt during regular playback, I believe the major problem would be resolved. Even if I mask the interrupts (CCS01) and do not explicitly unmask them (according to proc ice1724 the CCS01 register stays at 0xa0), the interrupt gets generated. I am enclosing the testing patch producing the above given results. Thanks a lot for any suggestion or help. Regards, Pavel.

3 19

[alsa-devel] Addition to soundcard vendor matrix
by Joshua Boyd 20 May '08

20 May '08

http://www.alsa-project.org/main/index.php/Matrix:Main Could someone with proper permissions add Marian (their web site is www.marian.de) to the vendor section? While there is no support in ALSA for any of their stuff yet, there is some information that seems like it would be worth adding, plus there is a guy working on a driver for one of their cards.

2 1

[alsa-devel] ca0106 Digital Output at 44.1kHz
by Ben Stanley 20 May '08

20 May '08

Dear List, Hello. I'm new here. This is my first attempt to hack an alsa driver. I recently purchased a "Sound Blaster Audigy Value!" card for use in a MythTV box. As I have a digital receiver, I was mainly concerned with getting a working S/PDIF output (coax or optical) and not too much more. Summary: I can make 44.1kHz digital output work, but I think that the driver model of the card having 3 or 4 digital output channels is incorrect. I believe the card only has 1 digital output channel. Details: The card I have is characterised by the following: http://www.soundblaster.com/products/product.asp?category=1&subcategory=205… Model: SB0570 serial: 100a1102 Also known as: Sound Blaster Audigy SE During initial testing, I noticed that 44.1kHz playback was not implemented. Subsequent testing shows that speaker-test works fine with 48kHz, 96kHz and 192kHz. (I only tested 16bit output so far.) I noticed in the source code that 44.1k was explicitly disabled. I added code in snd_ca0106_pcm_prepare_playback to set up this rate for S/PDIF output as per the comments in ca0106.h . Initial tests using hw:0,0 at 44.1kHz produced recognisable signals with some noisy corruption. Later I accidentally discovered that serially opening hw:0,2 , hw:0,1 and hw:0,0 at 44.1kHz then produces perfectly good 44.1kHz sampled digital audio output. Removing hw:0,1 or hw:0,2 from this sequence causes noisy corruption. It seems that channels 0-2 in reg40 must all be set to the same sampling frequency for S/PDIF to work where 44.1kHz is concerned. Conversely, to sucessfully output 48kHz again, I have to open hw:0,2 , hw:0,1 and hw:0,0 at 48kHz to restore proper output. I do not have such troubles with 96kHz and 192kHz, for which it suffices to just open hw:0,0 at the relevant sampling rate. Using these tricks, I can successfully output 44.1kHz encoded Dolby Digital and DTS signals (found at http://www.sr.se/cgi-bin/mall/index.asp?programid=2445 , as mentioned at http://alsa.opensrc.org/DigitalOut . ) Later, I examined the product manual (from a Windows compressed helpfile on the CD), and noticed that Creative instruct you to connect to the blue socket in only two ways: 1) with a mono 3.5mm jack plug to RCA plug -> S/PDIF input to external device, and 2) a proprietary digital I/O module (see http://www.soundblaster.com/products/product.asp?category=1&subcategory=16&… ) The digital I/O module only has one input and one output (the optical/coaxial pairs are duplicates of each other). The manual does not say how to connect a S/PDIF input signal other than through the digital I/O module. This suggests to me that the following comment near the top of ca0106_main.c is incorrect for the SB0570: * ( In theory one could output 3 different AC3 streams at once, to 3 different SPDIF outputs. ) I think you can only output one AC3 stream, and that there is only one S/PDIF output. Given this knowledge of the digital I/O module, I suggest that the pinout *may* possibly be: 1 (tip): S/PDIF output 2 : S/PDIF input 3 : power to digital I/O module 4 : gnd I have not been able to get any S/PDIF signal out of pin 2 (I only have a stereo cable to test with at the moment). I will attempt to test pin 2 as an input at some point. I think that this card can only output one S/PDIF channel, given the discovery of the required clock settings above, and that Creative's own hardware only gives you access to one output. Anyway, I don't have access to documentation. From reading around, I believe James has the docs under NDA from Creative Labs. Perhaps James could confirm these suspicions? Anyway, this is speculation. I'd love to have the docs. I haven't tried to get them. Is it likely/unlikely that I would get them? I'm currently working on kernel 2.6.22 from Ubuntu. They don't seem to have changed the ca0106 driver, and not much has happened there (for output) in the newer kernels. Please find attached my current patch, which is only suitable for the purposes of discussion. I need to clarify some things about channel arrangements with those who have the documentation before I begin to try to fix things up. This patch was written with a faulty understanding of the interaction between the channel model and the spdif_enable. I don't know how any of this affects other models in the ca0106 range. So, I think that before I go any further here, I need some feedback, and access to some documentation would be useful. Ben Stanley.

2 4