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

[alsa-devel] [PATCH] Fix build error with strict mm checking
by Martin Habets 13 Jun '07

13 Jun '07

Turning on STRICT_MM_TYPECHECKS in include/asm/page.h causes a build error for sparc32. This patch against 2.6.21 fixes this. Martin Signed-off-by: Martin Habets <errandir_news(a)mph.eclipse.co.uk> --- --- linux/sound/core/sgbuf.c.orig 2007-06-06 23:53:34.000000000 +0100 +++ linux/sound/core/sgbuf.c 2007-06-06 23:54:45.000000000 +0100 @@ -96,7 +96,7 @@ void *snd_malloc_sgbuf_pages(struct devi } sgbuf->size = size; - dmab->area = vmap(sgbuf->page_table, sgbuf->pages, VM_MAP, PAGE_KERNEL); + dmab->area = vmap(sgbuf->page_table, sgbuf->pages, VM_MAP, __pgprot(PAGE_KERNEL)); if (! dmab->area) goto _failed; return dmab->area;

2 1

[alsa-devel] Trouble understanding ALSA's DMA buffers
by Timur Tabi 12 Jun '07

12 Jun '07

I'm writing an ALSA SOC driver for an I2S-based device, and I'm having a really hard time understanding how ALSA uses the DMA buffers. And yes, I've read the documentation and studied some sample source code. I used to write audio drivers for a living, but that was many years ago, and it wasn't for Linux. Perhaps the concepts in my head are outdated, but I just don't see enough explanation as to how DMA buffers are supposed to work. Back then, audio drivers used "ping pong" DMA buffers. A single DMA buffer is allocated, and the audio hardware is programmed to read from that buffer in a loop. That is, it would automatically restart reading from the beginning of the buffer without any reprogramming. The hardware would also be programmed to issue an interrupt when it got to the end of the buffer, and when it got to the half-way point. To start playback, you first filled the whole buffer with audio data, and then told the hardware to start playing. After the hardware got to the half-way point, it would issue an interrupt. You would then tell the OS you need more data, and you'd get it. You then copy that data into the first half of the buffer *while* the hardware was playing the second half. Later, the hardware would interrupt you when it got to the end of the buffer. You'd then copy more data to the 2nd half while the hardware is playing the first half. And so - hardware plays one half while you copy data to the other half. Hence, "ping pong". So how do I implement this in ALSA? The "Writing an ALSA Driver" document doesn't even contain the words "ping" or "pong". -- Timur Tabi Linux Kernel Developer @ Freescale

4 6

[alsa-devel] [ASoC] bug in soc_pcm_open
by Matthieu CASTET 12 Jun '07

12 Jun '07

Hi, it seems there is a bug in soc_pcm_open. In some case [1] we are in a error path, but we don't set the ret return value. This cause bug/crash from alsa core. Thanks Matthieu [1]http://hg-mirror.alsa-project.org/alsa-kernel/file/38926de0e79c/soc/soc-c… if (!runtime->hw.rates) { 218 printk(KERN_ERR "asoc: %s <-> %s No matching rates\n", 219 codec_dai->name, cpu_dai->name); 220 goto machine_err; 221 } 222 if (!runtime->hw.formats) { 223 printk(KERN_ERR "asoc: %s <-> %s No matching formats\n", 224 codec_dai->name, cpu_dai->name); 225 goto machine_err; 226 } 227 if (!runtime->hw.channels_min || !runtime->hw.channels_max) { 228 printk(KERN_ERR "asoc: %s <-> %s No matching channels\n", 229 codec_dai->name, cpu_dai->name); 230 goto machine_err; 231 }

4 4

[alsa-devel] Realtek 268
by Steven Zakulec 12 Jun '07

12 Jun '07

I have tried the current (from about 6 hours ago) drivers+lib from the HG repository. My card is now labelled as an ALC 268, and shows me what appears to be a correct number of options in the mixer. Unfortunately, I still get no sound. I've compiled the driver with --debug=full, and the lib with the debug. The following is from dmesg when I removed the old snd-hda-intel module, did a make install, then did modprobe snd-hda-intel: (I cleared out dmesg before I did the modprobe) [ 1473.892000] ACPI: PCI Interrupt 0000:00:1b.0[A] -> GSI 22 (level, low) -> IRQ 21 [ 1473.892000] PCI: Setting latency timer of device 0000:00:1b.0 to 64 [ 1474.092000] hda_codec: Unknown model for ALC268, trying auto-probe from BIOS... [ 1474.140000] ALSA /home/szakulec/alsa-hg/alsa-driver/pci/hda/hda_codec.c:2339: autoconfig: line_outs=1 (0x14/0x0/0x0/0x0/0x0) [ 1474.140000] ALSA /home/szakulec/alsa-hg/alsa-driver/pci/hda/hda_codec.c:2343: speaker_outs=0 (0x0/0x0/0x0/0x0/0x0) [ 1474.140000] ALSA /home/szakulec/alsa-hg/alsa-driver/pci/hda/hda_codec.c:2347: hp_outs=1 (0x15/0x0/0x0/0x0/0x0) [ 1474.140000] ALSA /home/szakulec/alsa-hg/alsa-driver/pci/hda/hda_codec.c:2355: inputs: mic=0x19, fmic=0x18, line=0x0, fline=0x0, cd=0x0, aux=0x0 [ 1474.864000] ALSA /home/szakulec/alsa-hg/alsa-driver/pci/hda/../../alsa-kernel/pci/hda/patch_si3054.c:244: si3054: cannot initialize. EXT MID = 0000 [ 1474.872000] ALSA /home/szakulec/alsa-hg/alsa-driver/pci/hda/../../alsa-kernel/pci/hda/patch_si3054.c:256: Link Frame Detect(FDT) is not ready (line status: 0000) My /proc/asound/card0/codeco#0 is as follows: cat /proc/asound/card0/codec#0 Codec: Realtek ALC268 Address: 0 Vendor Id: 0x10ec0268 Subsystem Id: 0x1179ff10 Revision Id: 0x100003 Default PCM: rates [0x560]: 44100 48000 96000 192000 bits [0xe]: 16 20 24 formats [0x1]: PCM Default Amp-In caps: N/A Default Amp-Out caps: N/A Node 0x02 [Audio Output] wcaps 0x1d: Stereo Amp-Out Amp-Out caps: ofs=0x40, nsteps=0x40, stepsize=0x03, mute=0 Amp-Out vals: [0x00 0x00] PCM: rates [0x560]: 44100 48000 96000 192000 bits [0xe]: 16 20 24 formats [0x1]: PCM Node 0x03 [Audio Output] wcaps 0x1d: Stereo Amp-Out Amp-Out caps: ofs=0x40, nsteps=0x40, stepsize=0x03, mute=0 Amp-Out vals: [0x40 0x40] PCM: rates [0x560]: 44100 48000 96000 192000 bits [0xe]: 16 20 24 formats [0x1]: PCM Node 0x04 [Vendor Defined Widget] wcaps 0xf00000: Mono Node 0x05 [Vendor Defined Widget] wcaps 0xf00000: Mono Node 0x06 [Audio Output] wcaps 0x211: Stereo Digital PCM: rates [0x5e0]: 44100 48000 88200 96000 192000 bits [0x1e]: 16 20 24 32 formats [0x1]: PCM Node 0x07 [Audio Input] wcaps 0x100111: Stereo PCM: rates [0x160]: 44100 48000 96000 bits [0x6]: 16 20 formats [0x1]: PCM Connection: 1 0x24 Node 0x08 [Audio Input] wcaps 0x100111: Stereo PCM: rates [0x160]: 44100 48000 96000 bits [0x6]: 16 20 formats [0x1]: PCM Connection: 1 0x23 Node 0x09 [Vendor Defined Widget] wcaps 0xf00000: Mono Node 0x0a [Vendor Defined Widget] wcaps 0xf00000: Mono Node 0x0b [Vendor Defined Widget] wcaps 0xf00000: Mono Node 0x0c [Vendor Defined Widget] wcaps 0xf00000: Mono Node 0x0d [Vendor Defined Widget] wcaps 0xf00000: Mono Node 0x0e [Audio Mixer] wcaps 0x20010a: Mono Amp-In Amp-In caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1 Amp-In vals: [0x00] Connection: 1 0x02 Node 0x0f [Audio Mixer] wcaps 0x20010b: Stereo Amp-In Amp-In caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1 Amp-In vals: [0x00 0x00] [0x80 0x80] Connection: 2 0x02 0x1d Node 0x10 [Audio Mixer] wcaps 0x20010b: Stereo Amp-In Amp-In caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1 Amp-In vals: [0x00 0x00] [0x80 0x80] [0x80 0x80] Connection: 3 0x03 0x1d 0x02 Node 0x11 [Vendor Defined Widget] wcaps 0xf00000: Mono Node 0x12 [Pin Complex] wcaps 0x400001: Stereo Pincap 0x0820: IN Pin Default 0x411111f0: [N/A] Speaker at Ext Rear Conn = 1/8, Color = Black Pin-ctls: 0x00: Node 0x13 [Pin Complex] wcaps 0x400001: Stereo Pincap 0x0820: IN Pin Default 0x411111f0: [N/A] Speaker at Ext Rear Conn = 1/8, Color = Black Pin-ctls: 0x00: Node 0x14 [Pin Complex] wcaps 0x40018d: Stereo Amp-Out Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1 Amp-Out vals: [0x00 0x00] Pincap 0x081003c: IN OUT HP EAPD Detect Pin Default 0x99130110: [Fixed] Speaker at Int ATAPI Conn = ATAPI, Color = Unknown Pin-ctls: 0x40: OUT Connection: 1 0x0f Node 0x15 [Pin Complex] wcaps 0x40018d: Stereo Amp-Out Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1 Amp-Out vals: [0x00 0x00] Pincap 0x081003c: IN OUT HP EAPD Detect Pin Default 0x02211020: [Jack] HP Out at Ext Front Conn = 1/8, Color = Black Pin-ctls: 0xc0: OUT HP Connection: 1 0x10 Node 0x16 [Pin Complex] wcaps 0x40010c: Mono Amp-Out Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1 Amp-Out vals: [0x80] Pincap 0x0810: OUT Pin Default 0x411111f0: [N/A] Speaker at Ext Rear Conn = 1/8, Color = Black Pin-ctls: 0x00: Connection: 1 0x0e Node 0x17 [Vendor Defined Widget] wcaps 0xf00000: Mono Node 0x18 [Pin Complex] wcaps 0x40018f: Stereo Amp-In Amp-Out Amp-In caps: ofs=0x00, nsteps=0x02, stepsize=0x4f, mute=0 Amp-In vals: [0x00 0x00] Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1 Amp-Out vals: [0x80 0x80] Pincap 0x083734: IN OUT Detect Pin Default 0x02a11830: [Jack] Mic at Ext Front Conn = 1/8, Color = Black Pin-ctls: 0x24: IN Connection: 1 0x02 Node 0x19 [Pin Complex] wcaps 0x40008b: Stereo Amp-In Amp-In caps: ofs=0x00, nsteps=0x02, stepsize=0x4f, mute=0 Amp-In vals: Pincap 0x083724: IN Detect Pin Default 0x99a30940: [Fixed] Mic at Int ATAPI Conn = ATAPI, Color = Unknown Pin-ctls: 0x24: IN Node 0x1a [Pin Complex] wcaps 0x40018f: Stereo Amp-In Amp-Out Amp-In caps: ofs=0x00, nsteps=0x02, stepsize=0x4f, mute=0 Amp-In vals: [0x00 0x00] Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1 Amp-Out vals: [0x80 0x80] Pincap 0x083734: IN OUT Detect Pin Default 0x411111f0: [N/A] Speaker at Ext Rear Conn = 1/8, Color = Black Pin-ctls: 0x20: IN Connection: 1 0x02 Node 0x1b [Vendor Defined Widget] wcaps 0xf00000: Mono Node 0x1c [Pin Complex] wcaps 0x400001: Stereo Pincap 0x0820: IN Pin Default 0x411111f0: [N/A] Speaker at Ext Rear Conn = 1/8, Color = Black Pin-ctls: 0x20: IN Node 0x1d [Pin Complex] wcaps 0x400000: Mono Pincap 0x0820: IN Pin Default 0x4015812d: [N/A] Speaker at Ext N/A Conn = Optical, Color = Purple Pin-ctls: 0x20: IN Node 0x1e [Pin Complex] wcaps 0x400380: Mono Digital Pincap 0x0810: OUT Pin Default 0x411111f0: [N/A] Speaker at Ext Rear Conn = 1/8, Color = Black Pin-ctls: 0x40: OUT Connection: 1 0x06 Node 0x1f [Vendor Defined Widget] wcaps 0xf00000: Mono Node 0x20 [Vendor Defined Widget] wcaps 0xf00040: Mono Node 0x21 [Vendor Defined Widget] wcaps 0xf00000: Mono Node 0x22 [Vendor Defined Widget] wcaps 0xf00000: Mono Node 0x23 [Audio Selector] wcaps 0x30010d: Stereo Amp-Out Amp-Out caps: ofs=0x0b, nsteps=0x1f, stepsize=0x05, mute=1 Amp-Out vals: [0x81 0x81] Connection: 7 0x18 0x19 0x1a 0x1c 0x14 0x15* 0x12 Node 0x24 [Audio Selector] wcaps 0x30010d: Stereo Amp-Out Amp-Out caps: ofs=0x0b, nsteps=0x1f, stepsize=0x05, mute=1 Amp-Out vals: [0x81 0x81] Connection: 7 0x18 0x19 0x1a 0x1c 0x14* 0x15 0x13 Output for the audio device (lspci -vvv) below: 00:1b.0 Audio device: Intel Corporation 82801G (ICH7 Family) High Definition Audio Controller (rev 02) Subsystem: Toshiba America Info Systems Unknown device ff10 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- Latency: 0, Cache Line Size: 64 bytes Interrupt: pin A routed to IRQ 21 Region 0: Memory at f0b40000 (64-bit, non-prefetchable) [size=16K] Capabilities: [50] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=55mA PME(D0+,D1-,D2-,D3hot+,D3cold+) Status: D0 PME-Enable- DSel=0 DScale=0 PME- Capabilities: [60] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0 Enable- Address: 0000000000000000 Data: 0000 Capabilities: [70] Express Unknown type IRQ 0 Device: Supported: MaxPayload 128 bytes, PhantFunc 0, ExtTag- Device: Latency L0s <64ns, L1 <1us Device: Errors: Correctable- Non-Fatal- Fatal- Unsupported- Device: RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop+ Device: MaxPayload 128 bytes, MaxReadReq 128 bytes Link: Supported Speed unknown, Width x0, ASPM unknown, Port 0 Link: Latency L0s <64ns, L1 <1us Link: ASPM Disabled CommClk- ExtSynch- Link: Speed unknown, Width x0

2 1

[alsa-devel] alsa on Atmel at91
by Michel Benoit 12 Jun '07

12 Jun '07

Hello I am trying to run alsa on an ARM based target AT91SAM9260 based board. The cpu is connected over i2s (atmel's ssc) to a PCM1725 chip. I modifed the AT73C213 driver available in the latest experimental patches from www.at91.com to behave correctly for the PCM1725 chip. Basically all I have done is remove the spi communication with the AT73C213 that regulates the sound output volume. The PCM chip has no such volume control and I use the i2s interface setup as is to send sample data. I cross compile alsa lib and run the program test/pcm_min which generates as expected random noise on the speaker output. However when I try to run test/pcm I get a divide by zero floating point exception because the library returns a period_size of 0. This despite the fact that the period time is set to 100000 and buffer time is set to 500000. I enabled some debug info in the library and I see the following data dumped to the console. ACCESS: RW_INTERLEAVED FORMAT: S16_LE SUBFORMAT: STD SAMPLE_BITS: 16 FRAME_BITS: 32 CHANNELS: 2 RATE: 48000 PERIOD_TIME: (20354 20355) PERIOD_SIZE: 977 PERIOD_BYTES: 3908 PERIODS: (4 5) BUFFER_TIME: (81479 81480) BUFFER_SIZE: 3911 BUFFER_BYTES: 15644 TICK_TIME: 10000 How is it possible that the following code from test/pcm.c err = snd_pcm_hw_params_set_period_time_near(handle, params, &period_time, &dir); if (err < 0) { printf("Unable to set period time %i for playback: %s\n", period_time, snd_strerror(err)); return err; } err = snd_pcm_hw_params_get_period_size(params, &size, &dir); if (err < 0) { printf("Unable to get period size for playback: %s\n", snd_strerror(err)); return err; } returns a period_size of 0 when the debug output shows that the period_size has been calculated to be 977? Can it be that the driver has not initialised the alsa structures properly (the driver file is attached to this email)? Have I mucked something up by removing the spi comm. with the at73c213? Could this be due to a problem in the cross compilation of alsa-lib? I use the following configure command line: CC=arm-linux-gcc ./configure \ --host=arm-linux\ --prefix=$HOME/bsp/rootfs/buildroot/build_arm/root/usr\ --with-softfloat (note: I have also tried it without --with-softfloat) I have tried digging through the alsa lib code but it is not very clear to me where the returned value for period_size comes from. I appreciate any pointers, hints or tips that can help me to solve and/or understand this problem. Thanks in advance! Michel

5 20

[alsa-devel] Source of timing for MIDI and/or audio synchronization
by Mark Rivera 12 Jun '07

12 Jun '07

Hello (new to list), and thank you for the work you have been doing. As an end-user of the ALSA project's development, I am very grateful for being able to use softwares which provide audio functionality to Linux. I have been reading up on the docs and list archives, but I still have an open question for which I hope you can lead me to an answer. I designed and built a MIDI sequencer based around a Microchip PIC18 MCU, and used the built-in hardware timers and interrupt levels to drive the 'scheduler' for initiating MIDI output (EUSART) routines. In this same vein, I would like to write a software sequencer with as 'tight' timing as possible. So, in a similar concept for Linux - from where does the timing of audio and MIDI events come from? It occurred to me that it would be nice to have a loadable kernel module (LKM) to which userland programs could subscribe for receiving 'soft interrupts' based on some timer (cpu ticks?) so that various software could all reference the same notion of the "current time" - a sort of "master clock" with start/stop/continue as well. Does ALSA provide this functionality? Can someone point me in the right direction for learning more about this? Many thanks. Mark

3 2

[alsa-devel] snd_pcm_lib_malloc_pages()
by Timur Tabi 12 Jun '07

12 Jun '07

(resending since I haven't gotten a reply yet) Liam Why do none of the ASoC drivers use snd_pcm_lib_malloc_pages()? They all allocate their DMA buffers by hand. -- Timur Tabi Linux Kernel Developer @ Freescale

2 1

[alsa-devel] [PATCH] snd-usb-caiaq: Fix compatibility with kernels < 2.6.19
by Sergey Vlasov 12 Jun '07

12 Jun '07

Kernels before 2.6.19 used a different signature for the urb->complete callback (an additional "struct pt_regs *regs" parameter was present), therefore snd-usb-caiaq needs some compatibility patches in alsa-driver, like snd-usb-audio. Signed-off-by: Sergey Vlasov <vsu(a)altlinux.ru> --- The snd_usb_caiaq_midi_output_done() part is somewhat hackish - the problem is that snd_usb_caiaq_midi_output_done() is declared in caiaq-midi.h, and the alsa-driver build system does not support patching of *.h files. The rest is basically copied from usbaudio.patch. Without the patch compiling for 2.6.18 produces warnings: .../usb/caiaq/caiaq-device.c: In function 'init_card': .../usb/caiaq/caiaq-device.c:316: warning: passing argument 6 of 'usb_fill_bulk_urb' from incompatible pointer type .../usb/caiaq/caiaq-device.c:321: warning: passing argument 6 of 'usb_fill_bulk_urb' from incompatible pointer type .../usb/caiaq/caiaq-audio.c: In function 'alloc_urbs': .../usb/caiaq/caiaq-audio.c:583: warning: assignment from incompatible pointer type --- alsa-driver-1.0.14/usb/caiaq/Makefile.alt-caiaq-api 2007-06-11 16:29:28 +0400 +++ alsa-driver-1.0.14/usb/caiaq/Makefile 2007-06-11 19:50:39 +0400 @@ -5,6 +5,13 @@ endif include $(SND_TOPDIR)/toplevel.config include $(SND_TOPDIR)/Makefile.conf +clean-files := caiaq-audio.c caiaq-device.c + include $(SND_TOPDIR)/alsa-kernel/usb/caiaq/Makefile +EXTRA_CFLAGS += -I$(SND_TOPDIR)/alsa-kernel/usb/caiaq + include $(SND_TOPDIR)/Rules.make + +caiaq-audio.c: caiaq-audio.patch $(SND_TOPDIR)/alsa-kernel/usb/caiaq/caiaq-audio.c +caiaq-device.c: caiaq-device.patch $(SND_TOPDIR)/alsa-kernel/usb/caiaq/caiaq-device.c --- alsa-driver-1.0.14/usb/caiaq/caiaq-audio.patch.alt-caiaq-api 2007-06-11 19:18:40 +0400 +++ alsa-driver-1.0.14/usb/caiaq/caiaq-audio.patch 2007-06-11 19:18:17 +0400 @@ -0,0 +1,26 @@ +--- ../../alsa-kernel/usb/caiaq/caiaq-audio.c 2007-06-11 16:29:28 +0400 ++++ caiaq-audio.c 2007-06-11 19:17:38 +0400 +@@ -464,7 +464,11 @@ static void fill_out_urb(struct snd_usb_ + check_for_elapsed_periods(dev, dev->sub_playback); + } + ++#if !defined(OLD_USB) && !defined(CONFIG_SND_NEW_IRQ_HANDLER) ++static void read_completed(struct urb *urb, struct pt_regs *regs) ++#else + static void read_completed(struct urb *urb) ++#endif + { + struct snd_usb_caiaq_cb_info *info = urb->context; + struct snd_usb_caiaqdev *dev; +@@ -518,7 +522,11 @@ static void read_completed(struct urb *u + usb_submit_urb(urb, GFP_ATOMIC); + } + ++#if !defined(OLD_USB) && !defined(CONFIG_SND_NEW_IRQ_HANDLER) ++static void write_completed(struct urb *urb, struct pt_regs *regs) ++#else + static void write_completed(struct urb *urb) ++#endif + { + struct snd_usb_caiaq_cb_info *info = urb->context; + struct snd_usb_caiaqdev *dev = info->dev; --- alsa-driver-1.0.14/usb/caiaq/caiaq-device.patch.alt-caiaq-api 2007-06-11 19:55:17 +0400 +++ alsa-driver-1.0.14/usb/caiaq/caiaq-device.patch 2007-06-11 19:54:49 +0400 @@ -0,0 +1,31 @@ +--- ../../alsa-kernel/usb/caiaq/caiaq-device.c 2007-06-11 16:29:28 +0400 ++++ caiaq-device.c 2007-06-11 19:54:46 +0400 +@@ -100,7 +100,11 @@ static struct usb_device_id snd_usb_id_t + { /* terminator */ } + }; + ++#if !defined(OLD_USB) && !defined(CONFIG_SND_NEW_IRQ_HANDLER) ++static void usb_ep1_command_reply_dispatch (struct urb* urb, struct pt_regs *regs) ++#else + static void usb_ep1_command_reply_dispatch (struct urb* urb) ++#endif + { + int ret; + struct snd_usb_caiaqdev *dev = urb->context; +@@ -295,6 +299,16 @@ static struct snd_card* create_card(stru + return card; + } + ++#if !defined(OLD_USB) && !defined(CONFIG_SND_NEW_IRQ_HANDLER) ++static void snd_usb_caiaq_midi_output_done_wrapper(struct urb* urb, ++ struct pt_regs *regs) ++{ ++ snd_usb_caiaq_midi_output_done(urb); ++} ++#undef snd_usb_caiaq_midi_output_done ++#define snd_usb_caiaq_midi_output_done snd_usb_caiaq_midi_output_done_wrapper ++#endif ++ + static int init_card(struct snd_usb_caiaqdev *dev) + { + char *c;

2 1

[alsa-devel] [PATCH] asihpi: Fix compatibility with 64-bit resource_size_t
by Sergey Vlasov 12 Jun '07

12 Jun '07

In recent kernels the resource_size_t type can be either 32-bit or 64-bit depending on config options. The proper way to printk such values is to cast them to unsigned long long. Signed-off-by: Sergey Vlasov <vsu(a)altlinux.ru> --- Without the patch compilation on 2.6.18 produces warnings: .../pci/asihpi/hpimod.c: In function 'adapter_probe': .../pci/asihpi/hpimod.c:460: warning: format '%x' expects type 'unsigned int', but argument 4 has type 'resource_size_t' .../pci/asihpi/hpimod.c:460: warning: format '%x' expects type 'unsigned int', but argument 5 has type 'resource_size_t' --- alsa-driver-1.0.14/pci/asihpi/hpimod.c.alt-asihpi-warnings 2007-06-11 16:29:28 +0400 +++ alsa-driver-1.0.14/pci/asihpi/hpimod.c 2007-06-11 19:58:30 +0400 @@ -457,10 +457,10 @@ static int __devinit adapter_probe(struc // fill in HPI_PCI information from kernel provided information for (idx = 0; idx < HPI_MAX_ADAPTER_MEM_SPACES; idx++) { - HPI_DEBUG_LOG4(DEBUG, "Resource %d %s %x-%x\n", idx, + HPI_DEBUG_LOG4(DEBUG, "Resource %d %s %llx-%llx\n", idx, pci_dev->resource[idx].name, - pci_resource_start(pci_dev, idx), - pci_resource_end(pci_dev, idx)); + (unsigned long long)pci_resource_start(pci_dev, idx), + (unsigned long long)pci_resource_end(pci_dev, idx)); memlen = pci_resource_len(pci_dev, idx); if (memlen) {

2 1

[alsa-devel] Shutdown() vector in ALSA
by Nobin Mathew 12 Jun '07

12 Jun '07

why no ALSA driver has shutdown() vector implemented? Is this vector needed to ensure the proper shutdown of the system? What all needs to be taken care if i want to implement shutdown(), except hardware shutdown. struct snd_shutdown_f_ops { struct file_operations f_ops; struct snd_shutdown_f_ops *next; }; what this operations means? defined in sound/core/init.c Is there any need to call these functions? snd_power_change_state(card, SNDRV_CTL_POWER_D3hot); for (i = 0; i < chip->pcm_devs; i++) snd_pcm_suspend_all(chip->pcm[i]);

3 8