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

[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

Re: [alsa-devel] Alsa 1.0.13 (and others) does not work on ALC880
by Andrew Callan 12 Jun '07

12 Jun '07

I have been without sound using Fedora Core ever since the 2.6.16 or 2.6.17 kernel update (2.6.16 crashed during initialization, so I could not tell whether sound worked or not). It had worked well through the 2.6.15 Fedora kernels. I finally sat down tonight to work the problem as hard as I could and happened upon Eric and Tobin's timely exchange. First, simply adding probe_mask=1 to the snd-hda-intel options worked for me as well; I did not end up having to specify a specific model. Second, I too was seeing a LONG hang when trying to do: cat /proc/asound/card0/codec#0 but now with the probe_mask=1, I do not see this. If it helps, the alsa-info.sh output for my system is at http://pastebin.ca/496293 If it makes any difference, I'm not sure which model I had specified on the modprobe line at the time I captured this output. One thing I do notice is that after adding probe_mask=1, aplay -l does not show the Si3054 Modem which shows up in the alsa-info output. Thanks for the help you gave in the thread with Eric. Andrew

5 16

[alsa-devel] hda-codec - Add HP Pavillion quirk to Realtek code.
by Tobin Davis 12 Jun '07

12 Jun '07

This patch adds the HP Pavillion a1589L desktop system to the ALC883 configuration table. Signed off by Tobin Davis <tdavis(a)dsl-only.net> Resent from the correct email address. Ignore previous email.

2 1

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

12 Jun '07

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] [ASoC] machine driver and channel configuration
by Matthieu CASTET 12 Jun '07

12 Jun '07

Hi, If the platform/cpu_dai driver and codec support capture and playback channels. But on the board only the playback link is connected. In this configuration, the codec and platform/cpu_dai driver shouldn't try to use the capture path (and the resource associated to this). Is there a way to do something like that ? Thanks Matthieu

3 3

[alsa-devel] Questions on usb audio development
by LCID Fire 12 Jun '07

12 Jun '07

Hi. I know there is quite some documentation how to develop a pci driver for alsa - but since I'll try to get a usb device working I was wondering how to write a usb driver? Is it just the same? How to interface the various aspects of the device with regards to descriptor reading, ...

4 11