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

[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

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

11 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>

1 0

[alsa-devel] Patch - Revo7.1 PCM Playback Switch
by dustin＠seznam.cz 11 Jun '07

11 Jun '07

Hello Takashi, I have attached a patch to support mute for front channels of M-Audio Revolution 7.1 (the DAC AK4381 features a mute bit). Signed-off-by: Pavel Hofman <dustin at seznam.cz> Please could I ask you for your opinion on the following issue (so far no response): I am working together with Ctirad on supporting more capture channels in E-MU1212. So far we have managed to increase the number of channels from the default of 8 to 16 (A_FXWC2 = 0xffffffff, added new snd_emu10k1_audigy_dsp_convert_32_to_2x16 calls in emufx.c). There is still a number of issues to solve but the 16 channel capture already works fine. I would like to get your opinion on the form of adding this support to the module. The options are either hard-coding the 16 capture channels into the code, assuming that users would prefer as many channels as possible and do the routing in jack, or introducing a module parameter emu1010-capture-channels (range e.g. 1 to 16 - untested yet) and leaving the default number at the existing 8. Furthermore, the PCMs other than efx seem to be of no use for the EMU-1x1x models, probably fairly confusing for new users. Would you find it OK, if they were removed for this specific card (if (emu->card_capabilities->emu1010)), keeping only the playback and capture PCM id 2? Thanks a lot for your suggestions. Based on them, I will prepare the patch (with comments on what we found out about the card - it is a pitty that the driver has almost no big-picture comments on the supported cards' specifics, making new developers spend a number of long nights going through the nontrivial code and guessing). Best regards, Pavel.

4 7

Re: [alsa-devel] [2/3] 2.6.22-rc4: known regressions v2
by Michal Piotrowski 09 Jun '07

09 Jun '07

Hi all, Here is a list of some known regressions in 2.6.22-rc4. Feel free to add new regressions/remove fixed etc. http://kernelnewbies.org/known_regressions ALSA Subject : snd-aoa causes badness in lib/kref.c:33 References : http://bugzilla.kernel.org/show_bug.cgi?id=8513 Submitter : Ben Collins <bcollins(a)ubuntu.com> Handled-By : Takashi Iwai <tiwai(a)suse.de> Status : Unknown IDE Subject : libata and legacy ide pcmcia failure References : http://lkml.org/lkml/2007/5/17/305 Submitter : Robert de Rooy <robert.de.rooy(a)gmail.com> Handled-By : Mark Lord <mlord(a)pobox.com> Status : problem is being debugged SATA/PATA Subject : 22-rc3 broke the CDROM in Dell notebook References : http://lkml.org/lkml/2007/5/27/63 Submitter : Gregor Jasny <gjasny(a)googlemail.com> Handled-By : Tejun Heo <htejun(a)gmail.com> Jeff Garzik <jeff(a)garzik.org> Caused-By : Tejun Heo <htejun(a)gmail.com> commit d4b2bab4f26345ea1803feb23ea92fbe3f6b77bc Status : problem is being debugged Sparc64 Subject : 2.6.22-rc broke X on Ultra5 References : http://lkml.org/lkml/2007/5/22/78 Submitter : Mikael Pettersson <mikpe(a)it.uu.se> Handled-By : David Miller <davem(a)davemloft.net> Status : problem is being debugged Regards, Michal -- "Najbardziej brakowało mi twojego milczenia." -- Andrzej Sapkowski "Coś więcej"

2 1

[alsa-devel] probing state of high definition audio card in windows / SigmaTel STAC9221 microphone problems
by Eran Guendelman 09 Jun '07

09 Jun '07

Hi, I am struggling to get the (external) microphone working on a SigmaTel STAC9221 A1 device on my Dell XPS M1210 laptop. I saw other emails indicating that this was still problematic, and the latest drivers from alsa 1.0.14 did not seem to fix the problem. So now that I've started reading and trying to understand the basics behind the hda codec in an effort to fix this problem, I was wondering if it was possible for me to boot into windows (I've got a dual-boot setup), get into a state where the microphone is working, and somehow probe the codec's state at that time (all of the pin configurations, etc.)... then theoretically, if I reproduce that configuration on the linux side, it should work (right?). So the question is, does anyone have a ready-made utility for Windows to do this probe of the high definition audio codec? I could probably try writing one myself, but thought I'd check if it already exists. Thanks. Please send responses by email too (not subscribed).

3 3

[alsa-devel] Sound Devices USBPre
by Brian Phelps 08 Jun '07

08 Jun '07

Hey guys, I contacted Sound Devices at sounddevices.com about writing a Linux driver (I was going to head the project but would take any help I can get) for the USBPre, a 2ch-in 2ch-out USB preamp with highquality balanced XLR Mic inputs. They said that they would love to have a Linux Driver and will provide specs for me, I am still waiting on the info though. I have not asked if I can view their firmware sourcecode yet, and if it requires an NDA, I will have to work around that. What advice do you have for writing a driver for alsa? I have written some small kernel drivers for embedded Linux devices, a few audio programs in C, and I come from a DSP background, but I am not sure exactly where to start, besides the specs and firmware. Thanks for your help -Brian Phelps

1 0

[alsa-devel] Callback trouble
by Juan Manuel Lopez Baio 08 Jun '07

08 Jun '07

Hello. I'm having some problems with the asynchronous usage of ALSA API, and I'm not sure if this usage is correct. What I have done so far is the following: I have an class that encapsulates the ALSA API, working in a multithreaded environment. I use alsa to capture audio and want to do so in an asynchronous and non-blocing way, so I defined a static method in my class that functions as callback, which receives a pointer to the instance of my class and calls on a member function, like this: void alsaDevice::myCallback(snd_async_handler_t *handler) //STATIC { alsaDevice *dev = (alsaDevice*)snd_async_handler_get_callback_private(handler); dev->triggerCondition(); } void alsaDevice::triggerCondition() { LogError(0,"Trigger en placa %d device %d",cn,dn); m_condMutex.lock(); m_noDataCondition.trigger(); m_condMutex.unlock(); } To init ALSA, I do this: int mode = SND_PCM_ASYNC | SND_PCM_NONBLOCK; if ((err=snd_pcm_open(&pcm_cap_handle, pcm_name.str().c_str(), SND_PCM_STREAM_CAPTURE, mode) < 0)) { LogError(0,"Opening ALSA PCM device %s: %s",pcm_name.str().c_str(),snd_strerror(err)); pcm_cap_handle=NULL; return false; } then set all the pertinent parameters, and finally if((asyncaddresult=snd_async_add_pcm_handler(&ahandler,pcm_cap_handle,alsaDevice::myCallback,this))<0) { LogError(0,"No se pudo registrar la callback; PCM Error: %i",asyncaddresult); } if ((asyncaddresult=snd_pcm_start(pcm_cap_handle))<0) LogError(0,"No se pudo start pcm; PCM Error: %i",asyncaddresult); Afterwards, the first time that a call to snd_pcm_readn returns EAGAIN I call wait() on a condition object with a 100 ms timeout, which is triggered by the callback, as seen before. The problem is that the callback never seems to get called (so shows the log), so I'm not really sure if the previous steps were right. Any light you can shed on this would be much appreciated. Thanks! juan

1 0

[alsa-devel] snd-usb-audio: Add another QuickCam ID
by Ritesh Raj Sarraf 08 Jun '07

08 Jun '07

Hi, This patch adds another Logitech QuickCam USB ID for the device which is shipped with Dell's XPS M1210 Notebooks. Signed-off-by: Ritesh Raj Sarraf <rrs(a)researchut.com> diff --git a/sound/usb/usbquirks.h b/sound/usb/usbquirks.h index 374fbf6..c69a56f 100644 --- a/sound/usb/usbquirks.h +++ b/sound/usb/usbquirks.h @@ -70,6 +70,15 @@ .bInterfaceClass = USB_CLASS_AUDIO, .bInterfaceSubClass = USB_SUBCLASS_AUDIO_CONTROL }, +{ + .match_flags = USB_DEVICE_ID_MATCH_DEVICE | + USB_DEVICE_ID_MATCH_INT_CLASS | + USB_DEVICE_ID_MATCH_INT_SUBCLASS, + .idVendor = 0x046d, + .idProduct = 0x08c6, + .bInterfaceClass = USB_CLASS_AUDIO, + .bInterfaceSubClass = USB_SUBCLASS_AUDIO_CONTROL +}, PS: Request you to CC me if there are any comments. I'm not subscribed to the list. Thanks, Ritesh -- Ritesh Raj Sarraf RESEARCHUT - http://www.researchut.com "Necessity is the mother of invention."

2 2

[alsa-devel] [PATCH] soc/sh: let SND_SOC_PCM_SH7760 depend on SH_DMABRG
by Manuel Lauss 08 Jun '07

08 Jun '07

Let SND_SOC_PCM_SH7760 depend on SH_DMABRG rather than select'ing it. Gets rid of the Kbuild warning about SH_DMABRG being undefined on non-sh builds. Signed-off-by: Manuel Lauss <mano(a)roarinelk.homelinux.net> --- linux-2.6.22-rc4-mm2/sound/soc/sh/Kconfig~ 2007-06-07 11:09:30.000000000 +0200 +++ linux-2.6.22-rc4-mm2/sound/soc/sh/Kconfig 2007-06-07 11:09:30.000000000 +0200 @@ -2,8 +2,7 @@ menu "SoC Audio support for SuperH" config SND_SOC_PCM_SH7760 tristate "SoC Audio support for Renesas SH7760" - depends on CPU_SUBTYPE_SH7760 && SND_SOC - select SH_DMABRG + depends on CPU_SUBTYPE_SH7760 && SND_SOC && SH_DMABRG help Enable this option for SH7760 AC97/I2S audio support.

2 1

[alsa-devel] [PATCH] Add quirk for another MSI laptop to alc883_cfg_tbl[]
by Daniel T. Chen 08 Jun '07

08 Jun '07

Hi, Attached please find an hg changeset against current alsa-kernel tip adding the SSID of another MSI laptop to the quirk list. Thanks, Daniel Chen

2 1

[alsa-devel] [ASoC]one Small Suggestion
by Nobin Mathew 08 Jun '07

08 Jun '07

Liam, Thank you for your support, my work is almost complete now, driver is working perfectly now. I have one suggestion, I modified the wm9713.c codec driver in probe function , so that if(socdev->machine->dai_link->cpu_dai->private_data) codec->ac97->bus->private_data = socdev->machine->dai_link->cpu_dai->private_data; Here i am assigning the controller private data. so that my following ac97 read and write to access codec registers become good. static void aaci_ac97_write(struct snd_ac97 *ac97, unsigned short reg, unsigned short val) { struct platform_controller *controller = ac97->bus->private_data; struct aaci *aaci = (struct aaci *)controller->bus_controller; static unsigned short aaci_ac97_read(struct snd_ac97 *ac97, unsigned short reg) { struct platform_controller *controller = ac97->bus->private_data; struct aaci *aaci = (struct aaci *)controller->bus_controller; u32 v; Is there a way to accomodate this in existing ASoC design? Or a better way to do this?

3 5

[alsa-devel] [RFC] [PATCH 1/2] ASoC sound support for SMDK2440 boards: UDA1341 driver
by Zoltan Devai 08 Jun '07

08 Jun '07

ASoC Support for the UDA1341 codec. Please note that until there is a final L3-bus driver, this patch won't work. --- --- /dev/null +++ /sound/soc/codecs/uda1341.c @@ -0,0 +1,519 @@ +/* + * uda1341.c -- UDA1341 ALSA SoC Codec driver + * + * Copyright 2007 Dension Audio Systems Ltd. + * Author: Zoltan Devai + * + * Based on the WM87xx drivers by Liam Girdwood and Richard Purdie + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + */ + +#include <linux/module.h> +#include <linux/l3.h> +#include <sound/pcm.h> +#include <sound/pcm_params.h> +#include <sound/soc.h> +#include <sound/soc-dapm.h> +#include <sound/initval.h> + +#include "../s3c24xx/s3c24xx-i2s.h" +#include "uda1341.h" + +#define UDA1341_DEBUG 0 + +#ifdef UDA1341_DEBUG +#define DBG(format, arg...) \ + printk(KERN_DEBUG "UDA1341: %s:" format "\n" ,__FUNCTION__, ## arg) +#else +#define DBG(format, arg...) do {} while (0) +#endif + +#define UDA1341_RATES SNDRV_PCM_RATE_8000_48000 +#define UDA1341_FORMATS (SNDRV_PCM_FMTBIT_S8 | SNDRV_PCM_FMTBIT_S16_LE | \ + SNDRV_PCM_FMTBIT_S18_3LE | SNDRV_PCM_FMTBIT_S20_3LE ) + +struct uda1341_priv { + int sysclk; + int dai_fmt; +}; + +/* In-data addresses are hard-coded into the reg-cache values */ +static const char uda1341_reg[UDA1341_REGS_NUM] = { + /* Extended address registers */ + 0x04, 0x04, 0x04, 0x00, 0x00, 0x00, 0x00, 0x00, + /* Status, data regs */ + 0x00, 0x83, 0x00, 0x40, 0x80, 0x00, +}; + +/* + * The codec has no support for reading its registers except for peak level... + */ +static inline unsigned int uda1341_read_reg_cache(struct snd_soc_codec *codec, + unsigned int reg) +{ + u8 *cache = codec->reg_cache; + + DBG("reg: %d", reg); + + if (reg >= UDA1341_REGS_NUM) + return -1; + return cache[reg]; +} + +/* + * Write the register cache + */ +static inline void uda1341_write_reg_cache(struct snd_soc_codec *codec, + u8 reg, unsigned int value) +{ + u8 *cache = codec->reg_cache; + + DBG("reg: %02X", reg); + + if (reg >= UDA1341_REGS_NUM) + return; + cache[reg] = value; +} + +/* + * Write to the uda1341 registers + * + */ +static int uda1341_write(struct snd_soc_codec *codec, unsigned int reg, + unsigned int value) +{ + int ret; + int addr; + u8 data = value; + + DBG("reg: %02X, value:%02X", reg, value); + + if (reg >= UDA1341_REGS_NUM) { + DBG("Unkown register: reg: %d", reg); + return -EINVAL; + } + + uda1341_write_reg_cache(codec, reg, value); + + switch (reg) { + case UDA1341_STATUS0: + case UDA1341_STATUS1: + addr = UDA1341_STATUS_ADDR; + break; + case UDA1341_DATA000: + case UDA1341_DATA001: + case UDA1341_DATA010: + addr = UDA1341_DATA0_ADDR; + break; + case UDA1341_DATA1: + addr = UDA1341_DATA1_ADDR; + break; + default: + /* It's an extended address register */ + addr = (reg | UDA1341_EXTADDR_PREFIX); + + ret = codec->hw_write_l3(codec->control_data, + UDA1341_DATA0_ADDR, (char*)&addr, 1); + if (ret != 1) + return -EIO; + + addr = UDA1341_DATA0_ADDR; + data = (value | UDA1341_EXTDATA_PREFIX); + break; + } + + ret = codec->hw_write_l3(codec->control_data, addr, (char*)&data, 1); + if (ret != 1) + return -EIO; + + return 0; +} + +static inline void uda1341_reset(struct snd_soc_codec *codec) +{ + u8 reset_reg = uda1341_read_reg_cache(codec, UDA1341_STATUS0); + uda1341_write(codec, UDA1341_STATUS0, reset_reg | (1<<6)); +} + +static int uda1341_mute(struct snd_soc_codec_dai *dai, int mute) +{ + struct snd_soc_codec *codec = dai->codec; + u8 mute_reg = uda1341_read_reg_cache(codec, UDA1341_DATA010); + + DBG("mute: %d", mute); + + if (mute) + mute_reg |= (1<<2); + else + mute_reg &= ~(1<<2); + + uda1341_write(codec, UDA1341_DATA010, mute_reg & ~(1<<2)); + + return 0; +} + +static int uda1341_hw_params(struct snd_pcm_substream *substream, + struct snd_pcm_hw_params *params) +{ + struct snd_soc_pcm_runtime *rtd = substream->private_data; + struct snd_soc_device *socdev = rtd->socdev; + struct snd_soc_codec *codec = socdev->codec; + struct uda1341_priv *uda1341 = codec->private_data; + + u8 hw_params = uda1341_read_reg_cache(codec, UDA1341_STATUS0); + hw_params &= STATUS0_SYSCLK_MASK; + hw_params &= STATUS0_DAIFMT_MASK; + + DBG("sysclk: %d, rate:%d", uda1341->sysclk, params_rate(params)); + + /* set SYSCLK / fs ratio */ + switch (uda1341->sysclk / params_rate(params)) { + case 512: + break; + case 384: + hw_params |= (1<<4); + break; + case 256: + hw_params |= (1<<5); + break; + default: + return -EINVAL; + break; + } + + DBG("dai_fmt: %d, params_format:%d", uda1341->dai_fmt, + params_format(params)); + + + /* set DAI format and word length */ + switch (uda1341->dai_fmt & SND_SOC_DAIFMT_FORMAT_MASK) { + case SND_SOC_DAIFMT_I2S: + break; + case SND_SOC_DAIFMT_RIGHT_J: + switch(params_format(params)) { + case SNDRV_PCM_FORMAT_S16_LE: + hw_params |= (1<<1); + break; + case SNDRV_PCM_FORMAT_S18_3LE: + hw_params |= (1<<2); + break; + case SNDRV_PCM_FORMAT_S20_3LE: + hw_params |= ((1<<2) | (1<<1)); + break; + default: + return -EINVAL; + } + break; + case SND_SOC_DAIFMT_LEFT_J: + hw_params |= (1<<3); + break; + default: + return -EINVAL; + } + + uda1341_write(codec, UDA1341_STATUS0, hw_params); + + return 0; +} + +static int uda1341_set_dai_sysclk(struct snd_soc_codec_dai *codec_dai, + int clk_id, unsigned int freq, int dir) +{ + struct snd_soc_codec *codec = codec_dai->codec; + struct uda1341_priv *uda1341 = codec->private_data; + + DBG("clk_id: %d, freq: %d, dir: %d", clk_id, freq, dir); + + /* Anything between 256fs*8Khz and 512fs*48Khz should be acceptable + we'll error out on set_hw_params if it's not OK */ + if ( (freq >= (256 * 8000)) && (freq <= (512 * 48000)) ) { + uda1341->sysclk = freq; + return 0; + } + + return -EINVAL; +} + +static int uda1341_set_dai_fmt(struct snd_soc_codec_dai *codec_dai, + unsigned int fmt) +{ + struct snd_soc_codec *codec = codec_dai->codec; + struct uda1341_priv *uda1341 = codec->private_data; + + DBG("fmt: %08X", fmt); + + /* codec supports only full slave mode */ + if ((fmt & SND_SOC_DAIFMT_MASTER_MASK) != SND_SOC_DAIFMT_CBS_CFS) + return -EINVAL; + + /* no support for clock inversion */ + if ((fmt & SND_SOC_DAIFMT_INV_MASK) != SND_SOC_DAIFMT_NB_NF) + return -EINVAL; + + /* We can't setup DAI format here as it depends on the word bit num */ + /* so let's just store the value for later */ + uda1341->dai_fmt = fmt; + + return 0; +} + +static int uda1341_dapm_event(struct snd_soc_codec *codec, int event) +{ + u8 reg; + + DBG("event: %08X", event); + + switch (event) { + case SNDRV_CTL_POWER_D0: /* full On */ + /* ADC, DAC on */ + reg = uda1341_read_reg_cache(codec, UDA1341_STATUS1); + uda1341_write(codec, UDA1341_STATUS1, reg | 0x03); + break; + case SNDRV_CTL_POWER_D1: /* partial On */ + case SNDRV_CTL_POWER_D2: /* partial On */ + case SNDRV_CTL_POWER_D3hot: /* Off, with power */ + break; + case SNDRV_CTL_POWER_D3cold: /* Off, without power */ + /* mute, ADC, DAC power off */ + reg = codec->read(codec, UDA1341_STATUS1); + uda1341_write(codec, UDA1341_STATUS1, reg & ~(0x03)); + break; + } + codec->dapm_state = event; + return 0; +} + +static const char *uda1341_dsp_setting[] = {"Flat", "Minimum1", "Minimum2", "Maximum"}; +static const char *uda1341_deemph[] = {"None", "32Khz", "44.1Khz", "48Khz"}; +static const char *uda1341_mixmode[] = {"DD", "Input 2", "Input 2", "Digital mixer"}; + +static const struct soc_enum uda1341_mixer_enum[] = { +SOC_ENUM_SINGLE(UDA1341_DATA010, 0, 0x03, uda1341_dsp_setting), +SOC_ENUM_SINGLE(UDA1341_DATA010, 3, 0x03, uda1341_deemph), +SOC_ENUM_SINGLE(UDA1341_EA010, 0, 0x03, uda1341_mixmode), +}; + +static const struct snd_kcontrol_new uda1341_snd_controls[] = { +SOC_SINGLE("Playback Volume", UDA1341_DATA000, 0, 0x3F, 1), +SOC_SINGLE("Mic gain", UDA1341_EA010, 2, 0x07, 0), +SOC_SINGLE("Channel 1 mixer gain", UDA1341_EA000, 0, 0x1F, 1), +SOC_SINGLE("Channgel 2 mixer gain", UDA1341_EA001, 0, 0x1F, 1), +SOC_SINGLE("Input channel 2 amp gain", UDA1341_EA101, 0, 0x1F, 0), + +SOC_SINGLE("Bass boost", UDA1341_DATA001, 2, 0xF, 0), +SOC_SINGLE("Treble", UDA1341_DATA001, 0, 3, 0), + +SOC_ENUM("DSP setting", uda1341_mixer_enum[0]), +SOC_ENUM("Playback De-emphasis", uda1341_mixer_enum[1]), +SOC_ENUM("Mixer mode", uda1341_mixer_enum[2]), + +/* This should be an ext control with own handler, if one wants + to set the values in 0.5dB steps instead of 3dB */ +SOC_SINGLE("AGC output level", UDA1341_EA110, 0, 0x03, 1), +SOC_SINGLE("AGC time const", UDA1341_EA110, 2, 0x07, 0), + +SOC_SINGLE("DAC Gain switch", UDA1341_STATUS1, 6, 1, 0), +SOC_SINGLE("ADC Gain switch", UDA1341_STATUS1, 5, 1, 0), +SOC_SINGLE("ADC Polarity switch", UDA1341_STATUS1, 4, 1, 0), +SOC_SINGLE("DAC Polarity switch", UDA1341_STATUS1, 3, 1, 0), +SOC_SINGLE("Double speed playback switch", UDA1341_STATUS1, 2, 1, 0), +}; + +static int uda1341_add_controls(struct snd_soc_codec *codec) +{ + int err, i; + + for (i = 0; i < ARRAY_SIZE(uda1341_snd_controls); i++) { + if ((err = snd_ctl_add(codec->card, + snd_soc_cnew(&uda1341_snd_controls[i],codec, NULL))) < 0) + return err; + } + + return 0; +} + +struct snd_soc_codec_dai uda1341_dai = { + .name = "UDA1341", + /* playback capabilities */ + .playback = { + .stream_name = "Playback", + .channels_min = 1, + .channels_max = 2, + .rates = UDA1341_RATES, + .formats = UDA1341_FORMATS, + }, + /* capture capabilities */ + .capture = { + .stream_name = "Capture", + .channels_min = 1, + .channels_max = 2, + .rates = UDA1341_RATES, + .formats = UDA1341_FORMATS, + }, + /* pcm operations */ + .ops = { + .hw_params = uda1341_hw_params, + }, + /* DAI operations */ + .dai_ops = { + .digital_mute = uda1341_mute, + .set_sysclk = uda1341_set_dai_sysclk, + .set_fmt = uda1341_set_dai_fmt, + } +}; +EXPORT_SYMBOL(uda1341_dai); + + +static int uda1341_soc_probe(struct platform_device *pdev) +{ + struct snd_soc_device *socdev = platform_get_drvdata(pdev); + struct snd_soc_codec *codec; + struct uda1341_priv *uda1341; + void * codec_setup_data = socdev->codec_data; + int ret = -ENOMEM; + + printk(KERN_INFO "UDA1341 SoC Audio Codec\n"); + + socdev->codec = kzalloc(sizeof(struct snd_soc_codec), GFP_KERNEL); + if (socdev->codec == NULL) + return ret; + + codec = socdev->codec; + + uda1341 = kzalloc(sizeof(struct uda1341_priv), GFP_KERNEL); + if (uda1341 == NULL) + goto priv_err; + + codec->private_data = uda1341; + + codec->reg_cache = kmemdup(uda1341_reg, sizeof(uda1341_reg), \ + GFP_KERNEL); + + if (codec->reg_cache == NULL) + goto reg_err; + + mutex_init(&codec->mutex); + + codec->reg_cache_size = sizeof(uda1341_reg); + codec->reg_cache_step = 1; + + codec->name = "UDA1341"; + codec->owner = THIS_MODULE; + codec->dai = &uda1341_dai; + codec->num_dai = 1; + codec->read = uda1341_read_reg_cache; + codec->write = uda1341_write; + codec->dapm_event = uda1341_dapm_event; + INIT_LIST_HEAD(&codec->dapm_widgets); + INIT_LIST_HEAD(&codec->dapm_paths); + + if (!codec_setup_data) { + printk(KERN_ERR "UDA1341 SoC codec: \ + Unable to find an L3 bus adapter\n"); + ret = -ENODEV; + goto pcm_err; + } + + codec->control_data = codec_setup_data; + codec->hw_write_l3 = (hw_write_l3_t)l3_write; + + uda1341_reset(codec); + + /* register pcms */ + ret = snd_soc_new_pcms(socdev, SNDRV_DEFAULT_IDX1, SNDRV_DEFAULT_STR1); + if (ret < 0) { + printk(KERN_ERR "UDA1341: failed to register pcms\n"); + goto pcm_err; + } + + ret = uda1341_add_controls(codec); + if (ret < 0) { + printk(KERN_ERR "UDA1341: failed to register controls\n"); + goto pcm_err; + } + + //uda1341_add_widgets(codec); + + ret = snd_soc_register_card(socdev); + if (ret < 0) { + printk(KERN_ERR "UDA1341: failed to register card\n"); + goto card_err; + } + + return 0; + +card_err: + snd_soc_free_pcms(socdev); + snd_soc_dapm_free(socdev); +pcm_err: + kfree(codec->reg_cache); +reg_err: + kfree(codec->private_data); +priv_err: + kfree(codec); + return ret; +} + +/* power down chip */ +static int uda1341_soc_remove(struct platform_device *pdev) +{ + struct snd_soc_device *socdev = platform_get_drvdata(pdev); + struct snd_soc_codec *codec = socdev->codec; + + if (codec->control_data) + uda1341_dapm_event(codec, SNDRV_CTL_POWER_D3cold); + + snd_soc_free_pcms(socdev); + snd_soc_dapm_free(socdev); + + kfree(codec->private_data); + kfree(codec->reg_cache); + kfree(codec); + + return 0; +} + +#if defined(CONFIG_PM) +static int uda1341_soc_suspend(struct platform_device *pdev, + pm_message_t state) +{ + struct snd_soc_device *socdev = platform_get_drvdata(pdev); + struct snd_soc_codec *codec = socdev->codec; + + uda1341_dapm_event(codec, SNDRV_CTL_POWER_D3cold); + return 0; +} + +static int uda1341_soc_resume(struct platform_device *pdev) +{ + struct snd_soc_device *socdev = platform_get_drvdata(pdev); + struct snd_soc_codec *codec = socdev->codec; + int i; + u8 *cache = codec->reg_cache; + + /* Sync reg_cache with the hardware */ + for (i = 0; i < ARRAY_SIZE(uda1341_reg); i++) { + codec->write(codec, i, *cache++); + } + uda1341_dapm_event(codec, codec->suspend_dapm_state); + return 0; +} +#endif /* CONFIG_PM */ + +struct snd_soc_codec_device soc_codec_dev_uda1341 = { + .probe = uda1341_soc_probe, + .remove = uda1341_soc_remove, +#if defined(CONFIG_PM) + .suspend = uda1341_soc_suspend, + .resume = uda1341_soc_resume, +#endif /* CONFIG_PM */ +}; + +EXPORT_SYMBOL(soc_codec_dev_uda1341); + +MODULE_DESCRIPTION("UDA1341 ALSA soc codec driver"); +MODULE_AUTHOR("Zoltan Devai"); +MODULE_LICENSE("GPL"); --- /dev/null +++ /sound/soc/codecs/uda1341.h @@ -0,0 +1,47 @@ +/* + * uda1341.h -- UDA1341 ALSA SoC Codec driver + * + * Copyright 2007 Dension Audio Systems Ltd. + * Author: Zoltan Devai + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + */ + +#ifndef _UDA1341_H +#define _UDA1341_H + +#define UDA1341_L3ADDR 5 +#define UDA1341_DATA0_ADDR ((UDA1341_L3ADDR << 2) | 0) +#define UDA1341_DATA1_ADDR ((UDA1341_L3ADDR << 2) | 1) +#define UDA1341_STATUS_ADDR ((UDA1341_L3ADDR << 2) | 2) + +#define UDA1341_EXTADDR_PREFIX 0xC0 +#define UDA1341_EXTDATA_PREFIX 0xE0 + +/* UDA1341 registers */ +#define UDA1341_EA000 0 +#define UDA1341_EA001 1 +#define UDA1341_EA010 2 +#define UDA1341_EA011 3 +#define UDA1341_EA100 4 +#define UDA1341_EA101 5 +#define UDA1341_EA110 6 +#define UDA1341_EA111 7 +#define UDA1341_STATUS0 8 +#define UDA1341_STATUS1 9 +#define UDA1341_DATA000 10 +#define UDA1341_DATA001 11 +#define UDA1341_DATA010 12 +#define UDA1341_DATA1 13 + +#define UDA1341_REGS_NUM 14 + +#define STATUS0_DAIFMT_MASK (~(7<<1)) +#define STATUS0_SYSCLK_MASK (~(3<<4)) + +extern struct snd_soc_codec_dai uda1341_dai; +extern struct snd_soc_codec_device soc_codec_dev_uda1341; + +#endif /* _UDA1341_H */

4 4

[alsa-devel] [PATCH] Add SSID for Dell XPS400 to stac922x_cfg_tbl[]
by Daniel T. Chen 08 Jun '07

08 Jun '07

Hi, Attached please find an hg changeset against current alsa-kernel tip adding a quirk entry for a Dell XPS400. Thanks, Daniel Chen

2 1

[alsa-devel] Testing/forcing XRUN
by Eliot Blennerhassett 08 Jun '07

08 Jun '07

Hi, I want to test my driver behaviour when an xrun happens. I have tried using aplay/arecord, and suspending (ctrl-Z) them while playing/recording but this doesn't have the desired effect. (I don't see my driver code detecting an xrun). Instead I see a trigger-stop command to the driver. The apps do report an overrun when they are restarted though. Can anyone answer these: 1) Is this a valid way to simulate an xrun due to application not keeping up? 1.1) If not, what is? Do I have to write an app that deliberately starves the streams? 2) Where is the xrun being detected if my driver doesnt see it? Where does the trigger-stop command come from when I suspend the app? thanks Eliot Blennerhassett AudioScience Inc.

2 1

[alsa-devel] Audio driver for omap 24xx.
by Pharaoh . 07 Jun '07

07 Jun '07

Hi I am referring the EAC driver for omap 24xx which is used by n800 board. The EAC 24xx driver doesn't look complete since it has only hardware init sequences and very basic ALSA related functionalities i.e. register the sound card etc. Is omap 24xx eac driver still in intermediate stage?Or it is complete but not yet integrated in to omap git tree? In later case, where can I find the complete eac driver? Also, omap 24xx driver doesn't seem to follow the framework/structure of other omap alsa drivers in sound/arm/omap/ , any particular reason? Please enlighten. I know this might be little off topic here, but there are only two places where I can ask this question, so I am trying both. -pharaoh.

2 1

[alsa-devel] Surround sound problem with CS46xx
by Vasilis Manwlopoulos 06 Jun '07

06 Jun '07

Hi to everybody, I am kind of new in linux and to alsa and I am facing a problem with the setup for 5.1 surround sound with my sound card Hercules Fortissimo III, recognized having the chip cs46xx. I have managed to enable surround sound by creating a .asounrc file with the followings pcm.!default { type plug slave.pcm "surround51" slave.channels 6 route_policy duplicate } The problem is that I am facing weird cpu load spikes (sometimes isn't just spikes, but just 99% usage for a long time!) even when just playing a normal mp3 file at 128Kbps. This is happening when playing with various players (totem,rhythbox,vlc). Also the sound has cracklings or there is a delay between the front and the rear speakers. i have send this email to alsa-users too, but since there wasn't anyone to propose a workaround I was adviced to also send it to alsa-devel. I am using the distro ubuntu 7.04 with the default alsa libraries version 1.0.13ubuntu5. So, if anyone has any idea plz give me a hint, cause I am stuck with it about two weeks now, without having any clue to proceed with!!! PS. If any other information or command output is necessary to help me, tell me so.

1 0

[alsa-devel] [ASoC]Changing the order of trigger in soc_pcm_trigger
by Nobin Mathew 06 Jun '07

06 Jun '07

Liam, I have one suggestion. Can we use this if (rtd->codec_dai->ops.trigger) { ret = rtd->codec_dai->ops.trigger(substream, cmd); if (ret < 0) return ret; } if (rtd->cpu_dai->ops.trigger) { ret = rtd->cpu_dai->ops.trigger(substream, cmd); if (ret < 0) return ret; } if (platform->pcm_ops->trigger) { ret = platform->pcm_ops->trigger(substream, cmd); if (ret < 0) return ret; } Instead of if (rtd->codec_dai->ops.trigger) { ret = rtd->codec_dai->ops.trigger(substream, cmd); if (ret < 0) return ret; } if (platform->pcm_ops->trigger) { ret = platform->pcm_ops->trigger(substream, cmd); if (ret < 0) return ret; } if (rtd->cpu_dai->ops.trigger) { ret = rtd->cpu_dai->ops.trigger(substream, cmd); if (ret < 0) return ret; } That means trigger the Cpu before pcm. Because most of the controllers needs to be initialized and triggered before external DMA is triggered. Correct me if i am going wrong. This was causing so many problems in my hardware. Nobin Mathew

2 2

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

06 Jun '07

Hello ALSA developers, I have one of the Intel HDA cards that is not supported currently: Realtek 268. It was previously mentioned in May (http://mailman.alsa-project.org/pipermail/alsa-devel/2007-May/000828.html). The post seemed to imply it was not a terribly difficult task to add support for the card, but was very vague on details. If it is in fact just a matter of copying an existing preset and changing the values, I would probably try to do it myself. If it is any more difficult than that, I'd like to formally ask the developers if they could add any support for the card. The lspci and /proc/asound/codec info is identical to that in the posting I mentioned. If you need anymore information, I would be happy to provide it. Thank you!

2 1

[alsa-devel] Connecting two USB-Soundcard to JACK
by Carsten Beth 06 Jun '07

06 Jun '07

Hello! We want to connect two USB soundcards to one multichannel device at the alsa layer and to use that virtual device with JACK. But we don't find a way to do so. The USB soundcard is self-made. It woks as a high speed USB device with sample rates of up to 96 KHz, has four capture and two playback cannels. The clocks of two cards can be synchronized at hardware level. Using one card by its own works perfectly both, at the alsa and at the JACK level, also as a duplex device. All is done with alsalib 1.0.13, jackd 0.101.1 and qjackctl 0.2.21. Now I'm trying to build a virtual device with 8 capture and 4 playback channels at the alsa level. But, as it can be read at several locations, this only works for capture only or playback. It has been reported, that duplex operation is possible after patching pcm_multi.c. I have applyed the patch, but this has not changed anything. Now I want to ask you for support, to get the device running. I made some experiments with different configurations of alsa/jackd and had some strange results. You can read about the results and used the asoundrc below. Questions, that I can't answer are - Why do I see just the channels of one card when using the multi plugin in try 2), 5) and 7)? - Why is the processor load so high with playback only in try 2) and 3) but not in duplex operation? - Why are there lots non-adible xruns with playback only in try 2) and 3)? 1) playback only with p_multi ALSA: mmap-based access is not possible for the playback stream of this audio interface 2) playback only with p_multi_plug Playback of just the 1st cards two channel. Lot of processor load: Both cores of the Core Duo 2GHz system are at about 90% load. Lot of XRUNs: 08:01:35.514 XRUN callback (48501 skipped). 08:01:37.517 XRUN callback (80633 skipped). 08:01:39.519 XRUN callback (70612 skipped). but XRUNS can't be heard. Sometimes jackd terminates after a while: ALSA: could not complete playback of 256 frames: error = -32 cycle execution failure, exiting DRIVER NT: could not run driver cycle jack main caught signal 12 [...] zombified - calling shutdown handler [...] 08:01:40.926 Post-shutdown script terminated with exit status=256. 3) playback only with p_multi_route Number of channels as expected (4 channels, two from each card). Lot of processor load, like 2) Lot of non-adible XRUNS, like 2). Sometimes jackd terminates after a while with the same message as in 2). 4) capture only with c_multi ALSA: mmap-based access is not possible for the capture stream of this audio interface 5) capture only with c_multi_plug Captures just two channel from the 1st card Low processor load (near 0%) No XRUNS. 6) capture only with c_multi_route Number of channels as expected (8 channels, four from each card). Low load and no XRUNS, like 5) 7) duplex with p_multi_plug and c_multi_plug Playback and capture works just for the 1st card (two playback and 4 capture channels). Low processor load, like 2) Lot of XRUNs, but less the 2) (and now the XRUNS can be heard). Here is a snip: **** alsa_pcm: xrun of at least 0.010 msecs 11:34:00.013 XRUN callback (9 skipped). **** alsa_pcm: xrun of at least 0.014 msecs 11:34:02.037 XRUN callback (11 skipped). **** alsa_pcm: xrun of at least 0.018 msecs **** alsa_pcm: xrun of at least 0.016 msecs 11:34:04.069 XRUN callback (11 skipped). **** alsa_pcm: xrun of at least 0.016 msecs 11:34:06.099 XRUN callback (11 skipped). **** alsa_pcm: xrun of at least 0.018 msecs **** alsa_pcm: xrun of at least 0.013 msecs 11:34:08.116 XRUN callback (12 skipped). Sometimes jackd terminates after a while with the same message as in 2). 8) duplex with p_multi_route and c_multi_route Exactly the same as in 7) expect for the number of channels. Now all channels are available (four playback and four capture channels) Here the used asoundrc: ##################################### # 1st USB card ##################################### pcm.usb0 { type hw card 1 } ctl.usb0 { type hw card 1 } ##################################### # 2nd USB card ##################################### pcm.usb1 { type hw card 2 } ctl.usb1 { type hw card 2 } pcm.p_multi { type multi; slaves.a.pcm "usb0"; slaves.a.channels 2; slaves.b.pcm "usb1"; slaves.b.channels 2; bindings.0.slave a; bindings.0.channel 0; bindings.1.slave a; bindings.1.channel 1; bindings.2.slave b; bindings.2.channel 0; bindings.3.slave b; bindings.3.channel 1; } ctl.p_multi { type hw; card 1; } pcm.c_multi { type multi; slaves.a.pcm "usb0"; slaves.a.channels 4; slaves.b.pcm "usb1"; slaves.b.channels 4; bindings.0.slave a; bindings.0.channel 0; bindings.1.slave a; bindings.1.channel 1; bindings.2.slave a; bindings.2.channel 2; bindings.3.slave a; bindings.3.channel 3; bindings.4.slave b; bindings.4.channel 0; bindings.5.slave b; bindings.5.channel 1; bindings.6.slave b; bindings.6.channel 2; bindings.7.slave b; bindings.7.channel 3; } ctl.c_multi { type hw; card 1; } pcm.p_multi_plug { type plug; slave.pcm "p_multi"; ttable.0.0 1; ttable.1.1 1; ttable.2.2 1; ttable.3.3 1; } ctl.p_multi_plug { type hw; card 1; } pcm.c_multi_plug { type plug; slave.pcm "c_multi"; ttable.0.0 1; ttable.1.1 1; ttable.2.2 1; ttable.3.3 1; ttable.4.4 1; ttable.5.5 1; ttable.6.6 1; ttable.7.7 1; } ctl.c_multi_plug { type hw; card 1; } pcm.p_multi_route { type route; slave.pcm "p_multi"; ttable.0.0 1; ttable.1.1 1; ttable.2.2 1; ttable.3.3 1; } ctl.p_multi_route { type hw; card 1; } pcm.c_multi_route { type route; slave.pcm "c_multi"; ttable.0.0 1; ttable.1.1 1; ttable.2.2 1; ttable.3.3 1; ttable.4.4 1; ttable.5.5 1; ttable.6.6 1; ttable.7.7 1; } ctl.c_multi_route { type hw; card 1; } Thank you Carsten Beth -- Dipl.-Inform. Carsten Beth OFFIS - Institute for Information technology R&D Division Embedded Hardware-/Software-Systems Escherweg 2 - 26121 Oldenburg - Germany - http://www.offis.de/ Phone: +49-441-9722-241 - Fax: +49-441-9722-282

1 0

Re: [alsa-devel] Power management state flow in ALSA
by Nobin Mathew 06 Jun '07

06 Jun '07

Liam, In soc_resume() we should do this snd_power_change_state(codec->card, SNDRV_CTL_POWER_D0); instead of snd_power_change_state(codec->card, SNDRV_CTL_POWER_D3hot); Because snd_pcm_resume in pcm_native.c expects the card to be in SNDRV_CTL_POWER_D0 state. Other ioctl will wait forever. static int snd_pcm_resume(struct snd_pcm_substream *substream) { struct snd_card *card = substream->pcm->card; int res; snd_power_lock(card); if ((res = snd_power_wait(card, SNDRV_CTL_POWER_D0)) >= 0) res = snd_pcm_action_lock_irq(&snd_pcm_action_resume, substream, 0); snd_power_unlock(card); return res; } One more thing why we are using snd_power_change_state(codec->card, SNDRV_CTL_POWER_D3cold); every other driver is doing snd_power_change_state(card, SNDRV_CTL_POWER_D3hot); SNDRV_CTL_POWER_D3cold is true for deep sleep where power to the controller is switched off . In sleep, only clock to the controller is switched off. Nobin Mathew On 6/4/07, Nobin Mathew <nobin.mathew(a)gmail.com> wrote: > Liam > > I will get back, i need to set up the board > > On 6/1/07, Liam Girdwood <lg(a)opensource.wolfsonmicro.com> wrote: > > Nobin, > > > > Can you try the following patch :- > > > > http://opensource.wolfsonmicro.com/cgi-bin/gitweb/gitweb.cgi?p=linux-2.6-as… > > > > This will notify pcm's of their suspend state. > > > > Liam > > > > On Wed, 2007-05-30 at 12:58 +0200, Takashi Iwai wrote: > > > At Wed, 30 May 2007 16:06:54 +0530, > > > Nobin Mathew wrote: > > > > > > > > I am writing an ASoC driver, where i can place these calls > > > > > > > > snd_power_change_state(card, SNDRV_CTL_POWER_D3hot); > > > > snd_pcm_suspend_all(chip->pcm[i]); > > > > > > > > and snd_power_change_state(card, SNDRV_CTL_POWER_D0); > > > > > > > > > > > > In soc-core.c ? > > > > > > I suppose so. > > > In soc_suspend() and soc_resume(), you can get the card instance from > > > codec->card, at least. > > > > > > But currently SoC doesn't keep the PCM instances, so it cannot be > > > implemented as it is... Liam, any plan or known issue regarding this? > > > > > > > > > Takashi > > > > >

1 0

[alsa-devel] Problem restarting alsa: can't set buffer size
by Juan Manuel Lopez Baio 06 Jun '07

06 Jun '07

Hello. I'm developing an application that records input from ALSA and process it. To do so I user the API starting with snd_pcm_open and follow with the parameters settings and so on, and once the app is done and exits, it closes with snd_pcm_hw_params_free and snd_pcm_close. The problem is that afterwards, if I restart the application, I can't set up ALSA, becausea continuous calls to snd_pcm_hw_params_set_buffer_size always fail (I start with a buffer size of 8192 and keep dividing it by 2). I finally have to restart the system in order to get it to work again. I'm on a Mandriva box with gcc 4.1.2 ¿Any thoughts on this? Thanks in advance! juan

2 1

[alsa-devel] using 'type softvol' in a card conf file in /usr/share/alsa/cards, am i doing this right?
by John L. Utz III 05 Jun '07

05 Jun '07

Hello; I am working with an CMEDIA 8738-MC6 and i am trying to gain control of the second DAC by way of softvolume. but i seem to not be succeeding because my application cant find my 'Rear' control, am i doing this correctly? the original /usr/share/alsa/cards/CMI8738-MC6.conf CMI8738-MC6.pcm.rear.0 { @args [ CARD ] @args.CARD { type string } type hw card $CARD device 1 } i have modified it to look thusly: notice that the type is now softvol and the original hardware description is encapsulated in slave.pcm # 2nd DAC CMI8738-MC6.pcm.rear.0 { @args [ CARD ] @args.CARD { type string } type softvol slave.pcm { type hw card $CARD device 1 } control { name "Rear Playback Volume" card $CARD } } Shouldnt i now be able to see 'Rear Playback Volume' in the output of amixer controls ?? as it stands right now, i can not. what am i doing incorrectly? tnx! johnu

2 2

Re: [alsa-devel] [2/5] 2.6.22-rc4: known regressions
by Michal Piotrowski 05 Jun '07

05 Jun '07

Hi all, Here is a list of some known regressions in 2.6.22-rc4. Feel free to add new regressions/remove fixed etc. http://kernelnewbies.org/known_regressions ACPI Subject : ACPI_CPUFREQ fails to load - HP ML110 G4 Xeon 3040 References : http://bugzilla.kernel.org/show_bug.cgi?id=8570 Submitter : Marc Tuerschmann <marc(a)tuerschmann.de> Status : Unknown (possible hardware issues) Subject : unable to shutdown on kernel 2.6.22-rc2 References : http://bugzilla.kernel.org/show_bug.cgi?id=8516 Submitter : Thierry Volpiatto <tvolpiatt(a)neuf.fr> Status : Unknown ALSA Subject : snd-aoa causes badness in lib/kref.c:33 References : http://bugzilla.kernel.org/show_bug.cgi?id=8513 Submitter : Ben Collins <bcollins(a)ubuntu.com> Status : Unknown File systems Subject : OOPS (NULL pointer dereference) in v2.6.22-rc3 References : http://lkml.org/lkml/2007/6/1/389 Submitter : Alex Riesen <raa.lkml(a)gmail.com> Status : Unknown Regards, Michal -- "Najbardziej brakowało mi twojego milczenia." -- Andrzej Sapkowski "Coś więcej"

1 0

[alsa-devel] Alsa-OSS Duplex bug (revisited)
by Alan Horstmann 04 Jun '07

04 Jun '07

About a year ago I posted an explaination of the cause of non-functioning with Alsa-OSS in duplex, together with a workaround patch. After some discussion the thread ended. However since then there has been a steady trickle of downloads of the patches from my host (it can also be found elsewhere) and some reports of great success,eg http://audacityteam.org/forum/thread/1388 (2nd page especially) In attempting to tidy up some loose ends, I hope you can bear with me revisiting this and making the case for it's acceptance. I am aware the Alsa-OSS is not of much interest to developers, and it might be said 'use native Alsa'; however that is not possible or desirable in all applications, and anyway, why provide an OSS emulation that cannot be made to work properly? To summarise the problem first: OSS provides a single SNDCTL_DSP_CHANNELS ioctl; where a device is duplex the number of capture and playback channels cannot be set separately. With original OSS this was not a problem AFAIK because separate devices are created for capture and playback, ie they are not used duplex. However Alsa-OSS in most cases creates a single combined device, which only operates correctly when an equal number of capture and playback channels are used. The Workaround: The workaround I proposed and now use constantly is like a secret trapdoor. Where the existing interface is adequate (ie captue channels == playback channels, or non-duplex) nothing changes, and SNDCTL_DSP_CHANNELS is set with a number between 0 and 128. It is fully compatible with apps that don't know of the secret door -the front door is used! However, if an app needs to set capture channels != playback channels, in duplex, at present the stream will malfunction every time. But with this patch applied, if the app knows the workaround, then it can simply set SNDCTL_DSP_CHANNELS as playback + 256*capture channels, and this will be interpreted correctly in the patched Alsa-OSS and the stream functions correctly. As I say, there is therefore no loss of compatibility in either direction. Providing the app only uses the special formula when necessary rather than always, it is only providing a way to fix something that is broken. It would seem to me of value to add the patch to Alsa so that the workaround can be effected by changes to the app only, without also having to patch and compile a replacement Alsa. Whilst it is by no means ideal, it does overcome the underlying problem successfully. Details of the workaround could be added to the OSS-Emulation.html document. Patch for 1.0.14rc4 is attached for consideration, together with example portaudio patch. Regards Alan

3 15

[alsa-devel] ALSA 1.0.14 release
by Jaroslav Kysela 04 Jun '07

04 Jun '07

Hi all, finally, ALSA 1.0.14 is out. For list of changes, please, check: http://www.alsa-project.org/changes/v1-0-13--v1-0-14.txt http://www.alsa-project.org/changes/v1-0-14rc4--v1-0-14.txt Jaroslav ----- Jaroslav Kysela <perex(a)suse.cz> Linux Kernel Sound Maintainer ALSA Project, SUSE Labs

2 1

[alsa-devel] Alsa guru needed for short-term contracting gig
by Darren Gibbs 04 Jun '07

04 Jun '07

Are there any SF Bay Area local Alsa experts out there that could provide assistance bringing up Alsa with driver for an I2S codec on an ARM embedded system?

1 0

[alsa-devel] [PATCH] ALSA: Fix prototype for snd_soc_dai_link.init() function pointer
by Timur Tabi 04 Jun '07

04 Jun '07

Change the snd_soc_dai_link.init() function to take a pointer to the corresponding snd_soc_dai_link structure, instead of a pointer to a snd_soc_codec structure. This allows the initialization function to initialize its own structure. Signed-off-by: Timur Tabi <timur(a)freescale.com> --- This is a fix for ALSA bug 3135 (https://bugtrack.alsa-project.org/alsa-bug/view.php?id=3135). Since I don't have an ARM cross-compiler, and currently all ASoC drivers are for ARM platforms only, I'm not sure if this fix is correct. include/sound/soc.h | 2 +- sound/soc/at91/eti_b1_wm8731.c | 3 ++- sound/soc/pxa/corgi.c | 3 ++- sound/soc/pxa/poodle.c | 3 ++- sound/soc/pxa/spitz.c | 3 ++- sound/soc/pxa/tosa.c | 3 ++- sound/soc/soc-core.c | 2 +- 7 files changed, 12 insertions(+), 7 deletions(-) diff --git a/include/sound/soc.h b/include/sound/soc.h index db6edba..86e1b1d 100644 --- a/include/sound/soc.h +++ b/include/sound/soc.h @@ -410,7 +410,7 @@ struct snd_soc_dai_link { struct snd_soc_ops *ops; /* codec/machine specific init - e.g. add machine controls */ - int (*init)(struct snd_soc_codec *codec); + int (*init)(struct snd_soc_dai_link *codec); }; /* SoC machine */ diff --git a/sound/soc/at91/eti_b1_wm8731.c b/sound/soc/at91/eti_b1_wm8731.c index 820a676..a4f5a99 100644 --- a/sound/soc/at91/eti_b1_wm8731.c +++ b/sound/soc/at91/eti_b1_wm8731.c @@ -216,9 +216,10 @@ static const char *intercon[][3] = { /* * Logic for a wm8731 as connected on a Endrelia ETI-B1 board. */ -static int eti_b1_wm8731_init(struct snd_soc_codec *codec) +static int eti_b1_wm8731_init(struct snd_soc_dai_link *dai) { int i; + struct snd_soc_codec *codec = dai->codec_dai->codec; DBG("eti_b1_wm8731_init() called\n"); diff --git a/sound/soc/pxa/corgi.c b/sound/soc/pxa/corgi.c index 5ee51a9..43237f9 100644 --- a/sound/soc/pxa/corgi.c +++ b/sound/soc/pxa/corgi.c @@ -286,9 +286,10 @@ static const struct snd_kcontrol_new wm8731_corgi_controls[] = { /* * Logic for a wm8731 as connected on a Sharp SL-C7x0 Device */ -static int corgi_wm8731_init(struct snd_soc_codec *codec) +static int corgi_wm8731_init(struct snd_soc_dai_link *dai) { int i, err; + struct snd_soc_codec *codec = dai->codec_dai->codec; snd_soc_dapm_set_endpoint(codec, "LLINEIN", 0); snd_soc_dapm_set_endpoint(codec, "RLINEIN", 0); diff --git a/sound/soc/pxa/poodle.c b/sound/soc/pxa/poodle.c index 0915cf7..5e8cb76 100644 --- a/sound/soc/pxa/poodle.c +++ b/sound/soc/pxa/poodle.c @@ -246,9 +246,10 @@ static const snd_kcontrol_new_t wm8731_poodle_controls[] = { /* * Logic for a wm8731 as connected on a Sharp SL-C7x0 Device */ -static int poodle_wm8731_init(struct snd_soc_codec *codec) +static int poodle_wm8731_init(struct snd_soc_dai_link *dai) { int i, err; + struct snd_soc_codec *codec = dai->codec_dai->codec; snd_soc_dapm_set_endpoint(codec, "LLINEIN", 0); snd_soc_dapm_set_endpoint(codec, "RLINEIN", 0); diff --git a/sound/soc/pxa/spitz.c b/sound/soc/pxa/spitz.c index 80e8210..95dcaa4 100644 --- a/sound/soc/pxa/spitz.c +++ b/sound/soc/pxa/spitz.c @@ -292,9 +292,10 @@ static const struct snd_kcontrol_new wm8750_spitz_controls[] = { /* * Logic for a wm8750 as connected on a Sharp SL-Cxx00 Device */ -static int spitz_wm8750_init(struct snd_soc_codec *codec) +static int spitz_wm8750_init(struct snd_soc_dai_link *dai) { int i, err; + struct snd_soc_codec *codec = dai->codec_dai->codec; /* NC codec pins */ snd_soc_dapm_set_endpoint(codec, "RINPUT1", 0); diff --git a/sound/soc/pxa/tosa.c b/sound/soc/pxa/tosa.c index 5504e30..b438349 100644 --- a/sound/soc/pxa/tosa.c +++ b/sound/soc/pxa/tosa.c @@ -192,9 +192,10 @@ static const struct snd_kcontrol_new tosa_controls[] = { tosa_set_spk), }; -static int tosa_ac97_init(struct snd_soc_codec *codec) +static int tosa_ac97_init(struct snd_soc_dai_link *dai) { int i, err; + struct snd_soc_codec *codec = dai->codec_dai->codec; snd_soc_dapm_set_endpoint(codec, "OUT3", 0); snd_soc_dapm_set_endpoint(codec, "MONOOUT", 0); diff --git a/sound/soc/soc-core.c b/sound/soc/soc-core.c index 92d5d91..654a517 100644 --- a/sound/soc/soc-core.c +++ b/sound/soc/soc-core.c @@ -1093,7 +1093,7 @@ int snd_soc_register_card(struct snd_soc_device *socdev) mutex_lock(&codec->mutex); for(i = 0; i < machine->num_links; i++) { if (socdev->machine->dai_link[i].init) { - err = socdev->machine->dai_link[i].init(codec); + err = socdev->machine->dai_link[i].init(&machine->dai_link[i]); if (err < 0) { printk(KERN_ERR "asoc: failed to init %s\n", socdev->machine->dai_link[i].stream_name); -- 1.5.0.2.260.g2eb065

2 2

[alsa-devel] SALSA-Lib version 0.0.1 release
by Takashi Iwai 04 Jun '07

04 Jun '07

Hi all, I created a small replacement of ALSA-library, mainly for embedded systems with limited resources. The library is named as "SALSA-Lib" (too easy, eh?) It has no plugin layer but only hw layer, thus no sexy features like dmix and format conversions are available. It supports no shiny and complex configuration files. And it supports no sequencer. The only goal of this library is the reduction of the size of library and running binaries by inlining functions with direct syscalls. The library is designed to be source-level API compatible with the normal alsa-lib 1.0.14. Note that it is _not_ designed to be binary-compatible at all, and it will be never so. The first released version 0.0.1 is available at: ftp://ftp.suse.com/pub/people/tiwai/salsa-lib/salsa-lib-0.0.1.tar.bz2 The package is released under LGPL as well as the original alsa-lib. I've tested it only on i386, and tests on other architectures would be greatly appreciated. (And, no, I didn't make it on HG tree yet.) Takashi

5 4

[alsa-devel] Datasheet Needed
by chris＠idlelion.net 04 Jun '07

04 Jun '07

(working on bug #305) I'm looking for a proper datasheet on the Cirrus Logic / Crystal Semiconductor CS4624 (or CS4622) sound chip. It's used in a number of popular laptops made around 1999-2001. I don't need the 7- or 8-page feature list, or the 30 (or so) page reference design document. I need register lists and theory of operation and a discussion of power modes. The chip was end-of-lifed in 2004. Many thanks, Chris

1 0

[alsa-devel] v1.0.14 - test packages #2
by Jaroslav Kysela 04 Jun '07

04 Jun '07

Hi, I recreated driver and tools packages in /pub/testing to fix reported problems. Please, test... Thanks, Jaroslav ----- Jaroslav Kysela <perex(a)suse.cz> Linux Kernel Sound Maintainer ALSA Project, SUSE Labs

3 4

[alsa-devel] Problem with ncurses and alsamixer (cannot open terminal: vt100 or xterm)
by David Topper 04 Jun '07

04 Jun '07

I finally managed to get the alsa-1.0.4 utils to compile on an ARM based SBC. When I launch alsamixer, however, I get an error: Error opening terminal: xterm When I ssh into the board. Or: Error opening terminal: vt100 When connected via serial cable. I suspect this has something to do with the linking (or lack thereof) of alsamixer for ncurses. The ncurrses library, by the way, I cross compiled with the following command: CC=/opt/crosstool/arm-unknown-linux-gnu/gcc-3.3.4-glibc-2.3.2/bin/arm-unknown-linux-gnu-gcc ./configure --host=arm-linux --prefix=/home/topper/ts-packages/ --exec-prefix=/home/topper/ts-packages/ But for the alsa utils, I simple ran ./configure, and the script detected the ncurses library, ran through and compiled. Yet, something seems amuck because: root@ts7000:root# ldd /bin/alsamixer libasound.so.2 => /lib/libasound.so.2 (0x2aac8000) libm.so.6 => /lib/libm.so.6 (0x2ab6f000) libdl.so.2 => /lib/libdl.so.2 (0x2abe9000) libpthread.so.0 => /lib/libpthread.so.0 (0x2abf3000) libc.so.6 => /lib/libc.so.6 (0x2ac4b000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x2aaab000) Whereas on my Linux Intel laptop: awn:~$ ldd /usr/bin/alsamixer libncurses.so.5 => /lib/libncurses.so.5 (0x4002c000) libasound.so.2 => /usr/lib/libasound.so.2 (0x40069000) libm.so.6 => /lib/libm.so.6 (0x4010d000) libdl.so.2 => /lib/libdl.so.2 (0x40130000) libpthread.so.0 => /lib/libpthread.so.0 (0x40133000) libc.so.6 => /lib/libc.so.6 (0x40184000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) So I have two questions: 1. How might ensure proper linking of the ncurses library. 2. Is there another way to tell alsa to activate various cards, set volume, etc.. so I can test to see if the alsa driver is even working on this board. Thanks, Dave Topper -- Technical Director - Virginia Center for Computer Music http://www.virginia.edu/music/VCCM/

2 1

[alsa-devel] 1.0.14 test packages
by Jaroslav Kysela 04 Jun '07

04 Jun '07

Hello all, I put 1.0.14-final test packages to ftp://ftp.alsa-project.org/pub/testing Note that these packages are not an official release. They are indended for compilation tests. Anyway, if you find a compilation (not functionality) issue, please, let me know ASAP through e-mail. I'm going to release 1.0.14 packages on next Monday. Note for alsa developers: Please, no more HG repository updates until packages are released. Thanks, Jaroslav ----- Jaroslav Kysela <perex(a)suse.cz> Linux Kernel Sound Maintainer ALSA Project, SUSE Labs

3 4

[alsa-devel] snd_hda_intel: Conexant CX20551 (Waikiki)
by Edwin Smulders 03 Jun '07

03 Jun '07

Hi, I believe there's still a problem with the HDA Intel chip Conexant CX20551 (Waikiki) not working. However, im not entirely sure the problem the problem is with alsa, because it starts working when i boot with acpi=off (a fix suggested on the ubuntu forums, but not quite useful on a laptop [plus, it breaks my ethernet]) The reason I'm mailing is, can you confirm this is something alsa can/should/will fix or are we all looking in the wrong direction and this is really an acpi problem? If you can fix this or know of something that might work, I would be happy to hear it. I've attached my lspci -nv and cat /proc/asound/card0/codec\#* just in case. I would be happy to give you any more info you might need. ~~ Edwin

2 2

[alsa-devel] [PATCH] Add support for another X-Fi Extreme Audio (really SB Live 24bit)
by Daniel T. Chen 03 Jun '07

03 Jun '07

Hi, Attached please find an hg changeset against current alsa-kernel tip. Thanks, Daniel Chen

2 2

[alsa-devel] Next steps
by chris＠idlelion.net 03 Jun '07

03 Jun '07

Hey gang, I'm trying to work on issue 305, suspend/resume for cs46xx. I'm running CentOS 5, so I'd like to work on what's current for that distribution first, and patch to latest if needed after that. I think I have the correct source package, but the only mention of cs46xx I could find in the source is a configuration file. Running make doesn't make the cs46xx module, AFAICT. Which source (package)(s) should I have? How do I track down the source file(s) I need to examine? Thanks, Chris

4 5

Re: [alsa-devel] ASoC and a codec that can't be controlled
by Timur Tabi 01 Jun '07

01 Jun '07

Liam Girdwood wrote: >> I guess I just don't understand why the codec driver is acting like the "master" driver of >> ASOC. IMHO, the codec driver should be doing two things: > > I guess this is due to an ordering issue we had during early > development. We had to make sure that the I2C probe of the codec > succeeded before registering the card, pcms, etc. Fwiw, I do intend to > address this in future versions (I should probably add a road map to the > wiki now). In that case, I think we can solve this problem as well as the PowerPC device tree problem in one shot, because they're basically the same problem. Anyway, let me see if I get this right: 1. The first function called is eti_b1_init(). 2. eti_b1_init() calls platform_device_add() to add an soc-audio class device and register the eti_b1_snd_devdata structure. 3. The registration causes a number of things to happen, one of which is a call to soc_probe(). 4. soc_probe() sees that the snd_soc_machine_eti_b1.probe is NULL, so that part is skipped. 3. soc_probe() sees that snd_soc_machine_eti_b1.dai_link->cpu_dai->probe is also NULL, so that part is skipped. (eti_b1_snd_devdata.machine == snd_soc_machine_eti_b1) 4. soc_probe() sees that soc_codec_dev_wm8731.probe is not NULL, so it calls wm8731_probe(). 5. wm8731_probe() registers an I2C driver. 6. The I2C class driver calls wm8731_i2c_driver.attach_adapter, which is wm8731_i2c_attach(). 7. wm8731_i2c_attach() calls i2c_probe(), which in turn calls wm8731_codec_probe() 8. wm8731_codec_probe() allocates a snd_soc_codec structure. 8. wm8731_codec_probe() calls wm8731_init(). This means that if there is no I2C support, wm8731_init() will never be called. 9. wm8731_init() initializes the snd_soc_codec structure. Question: why doesn't wm8731_probe() initialize the non-I2C parts of the snd_soc_codec structure? For example, snd_soc_codec.dai, snd_soc_codec.name, and snd_soc_codec.owner? That way, the snd_soc_codec structure will be properly initialized even when there's no I2C. 10. wm8731_init() calls snd_soc_new_pcms. 11. wm8731_init() exits, wm8731_codec_probe() exits, wm8731_i2c_attach() exits, and then wm8731_probe() exits. Control returns to soc_probe(). 12. soc_probe() notices that eti_b1_snd_devdata.platform.probe is NULL, so it skips that. Question: why don't you define a function for at91_soc_platform.probe, and in that function you can call snd_soc_new_pcms()? That way, you guarantee the codec driver's I2C interface is initialized before snd_soc_new_pcms() is called, and you avoid have PCM calls in the codec driver. >> ASOC and the machine driver should then work in tandem to decide which driver will do what >> and which capabilities are *actually* supported. *Something* needs to look at the entire >> system and say to each device, "Well, yes, I know about this little feature of yours, but >> we're just not going to support that today." >> > > The machine driver pretty much already does this. It can override valid > hardware configurations and return -EINVAl if required. Do you have an example of that? Would that be eti_b1_hw_params()? -- Timur Tabi Linux Kernel Developer @ Freescale

2 5

[alsa-devel] [1/3] 2.6.22-rc3: known regressions v2
by Michal Piotrowski 01 Jun '07

01 Jun '07

Hi all, Here is a list of some known regressions in 2.6.22-rc3. Feel free to add new regressions/remove fixed etc. http://kernelnewbies.org/known_regressions Unclassified Subject : build failed in function `vic_sys_interrupt' References : http://lkml.org/lkml/2007/5/31/227 Submitter : Toralf Förster <toralf.foerster(a)gmx.de> Status : Unknown Subject : long freezes on thinkpad t60 References : http://lkml.org/lkml/2007/5/24/100 Submitter : Miklos Szeredi <miklos(a)szeredi.hu> Handled-By : Ingo Molnar <mingo(a)elte.hu> Status : problem is being debugged ACPI Subject : unable to shutdown on kernel 2.6.22-rc2 References : http://bugzilla.kernel.org/show_bug.cgi?id=8516 Submitter : Thierry Volpiatto <tvolpiatt(a)neuf.fr> Status : Unknown ALSA Subject : snd-aoa causes badness in lib/kref.c:33 References : http://bugzilla.kernel.org/show_bug.cgi?id=8513 Submitter : Ben Collins <bcollins(a)ubuntu.com> Status : Unknown Networking Subject : b44: regression in 2.6.22 References : http://lkml.org/lkml/2007/5/27/108 Submitter : Maximilian Engelhardt <maxi(a)daemonizer.de> Handled-By : Michael Buesch <mb(a)bu3sch.de> Status : problem is being debugged Regards, Michal -- "Najbardziej brakowało mi twojego milczenia." -- Andrzej Sapkowski "Coś więcej"

3 2

[alsa-devel] Configure problems for alsa-utils-1.0.4
by David Topper 01 Jun '07

01 Jun '07

So I've managed to compile alsa-drivers-1.0.4 for ARM. I can even load the modules. I've also successfully compiled alsa-libs-1.0.4 ... but I had to do it on the board. Cross compiling simply didn't seem to work. I've been using --prefix=/ and --exec-prefix=/ for configures. But when I do ./configure --prefix=/ --exec-prefix=/ for alsa-utils-1.0.4 it fails with: checking for libasound headers version >= 0.9.0... not present. configure: error: Sufficiently new version of libasound not found. But they're there, for sure. Perhaps it doesn't like looking in /include/alsa? Thanks, DT

1 0

[alsa-devel] snd_soc_dai_link.init()
by Timur Tabi 01 Jun '07

01 Jun '07

Liam, Why does the init() function pointer in the snd_soc_dai_link structure take a snd_soc_codec pointer? Wouldn't it make more sense for it to take a snd_soc_dai_link pointer? That way, I could use the init() function to initialize the structure. I'm trying to write a function that will initialize the codec_dai pointer. I thought I could use snd_soc_dai_link.init(), but I don't know how to get the pointer to the snd_soc_dai_link structure from a snd_soc_codec structure. /* SoC machine DAI configuration, glues a codec and cpu DAI together */ struct snd_soc_dai_link { char *name; /* Codec name */ char *stream_name; /* Stream name */ /* DAI */ struct snd_soc_codec_dai *codec_dai; struct snd_soc_cpu_dai *cpu_dai; /* machine stream operations */ struct snd_soc_ops *ops; /* codec/machine specific init - e.g. add machine controls */ int (*init)(struct snd_soc_codec *codec); }; -- Timur Tabi Linux Kernel Developer @ Freescale

2 7

[alsa-devel] Power management state flow in ALSA
by Nobin Mathew 01 Jun '07

01 Jun '07

I am having a doubt regarding ALSA power management. My understanding of APM suspend() is like this. Freeze the ALSA apps Call ALSA driver suspend () in the ALSA suspend() function it saves the current state of substream and changes the state of substream to SUSPENDED. My understanding of APM resume() is like this Call ALSA driver resume () Activate the ALSA apps In ALSA resume function it restores the saved state of substream. So my question is when ALSA app will get to know the SUSPENDED state of substream.??? I am using linux kernel 2.6.17 ALSA driver version 1.0.11rc4 ASoC patch version 0.12.4

3 9