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

[alsa-devel] [RFC] cmi8330: Add basic CMI8329 support
by Ondrej Zary 05 Jul '09

05 Jul '09

Add basic support for CMI8329 cards. It seems to be very similar to CMI8330, but the PnP devices are different: - AD1848 (WSS) and SB16 device IDs are swapped - the OPL3 port is contained in SB16 device, not AD1848 (WSS) - there is A@@0001 device (looks like some control interface - it has only one 8-bit I/O address) Is my detection code correct, shouldn't the struct pnp_dev returned pnp_request_card_device() be released somehow? Also the mixer seems to be a bit different - master volume does not work currently. My card includes wavetable MIDI - it works in Windows when MPU-401 is selected. It does not work with this driver - pmidi plays but no sound comes out. OPL3 works. My card has also an IDE interface but it's not visible as PnP device and it does not work even in Windows (and I'm unable to find any driver for it for any OS). Here's a scan of the card: http://www.rainbow-software.org/images/hardware/cmi8329a_.jpg The main chip is labelled AD Chips CMI8329A. --- linux-test/sound/isa/cmi8330.c 2009-06-27 16:32:13.000000000 +0200 +++ linux-2.6.30-pentium/sound/isa/cmi8330.c 2009-06-27 16:33:25.000000000 +0200 @@ -156,6 +156,11 @@ typedef int (*snd_pcm_open_callback_t)(struct snd_pcm_substream *); +enum card_type { + CMI8329, + CMI8330 +}; + struct snd_cmi8330 { #ifdef CONFIG_PNP struct pnp_dev *cap; @@ -172,6 +177,8 @@ snd_pcm_open_callback_t open; void *private_data; /* sb or wss */ } streams[2]; + + enum card_type type; }; #ifdef CONFIG_PNP @@ -328,12 +335,26 @@ { struct pnp_dev *pdev; int err; + const char *sb16_id, *wss_id; + + /* CMI8329 has a device with ID A@@0001, CMI8330 does not */ + pdev = pnp_request_card_device(card, "A@@0001", NULL); + if (pdev) { + acard->type = CMI8329; + pnp_release_card_device(pdev); + sb16_id = id->devs[0].id; + wss_id = id->devs[1].id; + } else { + acard->type = CMI8330; + sb16_id = id->devs[1].id; + wss_id = id->devs[0].id; + } - acard->cap = pnp_request_card_device(card, id->devs[0].id, NULL); + acard->cap = pnp_request_card_device(card, wss_id, NULL); if (acard->cap == NULL) return -EBUSY; - acard->play = pnp_request_card_device(card, id->devs[1].id, NULL); + acard->play = pnp_request_card_device(card, sb16_id, NULL); if (acard->play == NULL) return -EBUSY; @@ -351,7 +372,8 @@ wssport[dev] = pnp_port_start(pdev, 0); wssdma[dev] = pnp_dma(pdev, 0); wssirq[dev] = pnp_irq(pdev, 0); - fmport[dev] = pnp_port_start(pdev, 1); + if (acard->type == CMI8330) + fmport[dev] = pnp_port_start(pdev, 1); /* allocate SB16 resources */ pdev = acard->play; @@ -365,6 +387,8 @@ sbdma8[dev] = pnp_dma(pdev, 0); sbdma16[dev] = pnp_dma(pdev, 1); sbirq[dev] = pnp_irq(pdev, 0); + if (acard->type == CMI8329) + fmport[dev] = pnp_port_start(pdev, 1); /* allocate MPU-401 resources */ pdev = acard->mpu; -- Ondrej Zary

2 3

Re: [alsa-devel] Laptop speakers nonfunctional, jacks functional
by Takashi Iwai 05 Jul '09

05 Jul '09

At Sat, 4 Jul 2009 22:16:18 +0200, Ludwig Maes wrote: > > but then, how come I have audio on line out and headphones? No idea. But this implies that you have very strange setup. Takashi > > thanks, > Ludwig > > 2009/7/4 Takashi Iwai <tiwai(a)suse.de> > > At Sat, 4 Jul 2009 19:15:23 +0200, > Ludwig Maes wrote: > > > > Thanks for your attention, > > I dont have /dev/snd/hwC0D0 > > but I do have > > /dev/snd/seq > > /dev/snd/timer > > /dev/sndstat > > I guess I should try it on seq, but I'll await your advice > > No, don't, that's wrong! > > It's an odd situation. I guess you didn't install the driver properly. > Otherwise you must have /dev/snd/control*, PCM, else. > > How to install the alsa-driver externally depends on the distro. > I'd advise you to ask on a distro forum about it at first. > The rest debugging starts after you can install the sound drivers > properly. > > thanks, > > Takashi > > > friendly greetings > > Ludwig > > > > 2009/6/30 Takashi Iwai <tiwai(a)suse.de> > > > > At Mon, 29 Jun 2009 20:06:47 +0200, > > Ludwig Maes wrote: > > > > > > Tried the snapshot, > > > still the same, alsa-info.txt attached > > > > Hm, just through a quick look at the output, there is no obvious > > problem. It's only the problem from speaker, not about the > headphone, > > right? > > > > If so, the problem is likely the missing amplifier setup, which is > > usually powered up via COEF verbs or GPIO verbs (ALC888/1200 have no > > EAPD verbs). > > > > Try to install hda-verb program and check the command below. > > > > # hda-verb /dev/snd/hwC0D0 0x20 SET_COEF_INDEX 7 > > # hda-verb /dev/snd/hwC0D0 0x20 GET_PROC_COEF 0 > > > > Which value do you get? What happens if you set > > > > # hda-verb /dev/snd/hwC0D0 0x20 SET_COEF_INDEX 7 > > # hda-verb /dev/snd/hwC0D0 0x20 SET_PROC_COEF 0x3060 > > or > > # hda-verb /dev/snd/hwC0D0 0x20 SET_COEF_INDEX 7 > > # hda-verb /dev/snd/hwC0D0 0x20 SET_PROC_COEF 0x3070 > > or > > # hda-verb /dev/snd/hwC0D0 0x20 SET_COEF_INDEX 7 > > # hda-verb /dev/snd/hwC0D0 0x20 SET_PROC_COEF 0x0830 > > or so? > > > > Takashi > > > > > >

1 0

Re: [alsa-devel] Laptop speakers nonfunctional, jacks functional
by Takashi Iwai 04 Jul '09

04 Jul '09

At Sat, 4 Jul 2009 19:15:23 +0200, Ludwig Maes wrote: > > Thanks for your attention, > I dont have /dev/snd/hwC0D0 > but I do have > /dev/snd/seq > /dev/snd/timer > /dev/sndstat > I guess I should try it on seq, but I'll await your advice No, don't, that's wrong! It's an odd situation. I guess you didn't install the driver properly. Otherwise you must have /dev/snd/control*, PCM, else. How to install the alsa-driver externally depends on the distro. I'd advise you to ask on a distro forum about it at first. The rest debugging starts after you can install the sound drivers properly. thanks, Takashi > friendly greetings > Ludwig > > 2009/6/30 Takashi Iwai <tiwai(a)suse.de> > > At Mon, 29 Jun 2009 20:06:47 +0200, > Ludwig Maes wrote: > > > > Tried the snapshot, > > still the same, alsa-info.txt attached > > Hm, just through a quick look at the output, there is no obvious > problem. It's only the problem from speaker, not about the headphone, > right? > > If so, the problem is likely the missing amplifier setup, which is > usually powered up via COEF verbs or GPIO verbs (ALC888/1200 have no > EAPD verbs). > > Try to install hda-verb program and check the command below. > > # hda-verb /dev/snd/hwC0D0 0x20 SET_COEF_INDEX 7 > # hda-verb /dev/snd/hwC0D0 0x20 GET_PROC_COEF 0 > > Which value do you get? What happens if you set > > # hda-verb /dev/snd/hwC0D0 0x20 SET_COEF_INDEX 7 > # hda-verb /dev/snd/hwC0D0 0x20 SET_PROC_COEF 0x3060 > or > # hda-verb /dev/snd/hwC0D0 0x20 SET_COEF_INDEX 7 > # hda-verb /dev/snd/hwC0D0 0x20 SET_PROC_COEF 0x3070 > or > # hda-verb /dev/snd/hwC0D0 0x20 SET_COEF_INDEX 7 > # hda-verb /dev/snd/hwC0D0 0x20 SET_PROC_COEF 0x0830 > or so? > > Takashi > >

1 0

[alsa-devel] Help required with debugging
by Harsha, Priya 04 Jul '09

04 Jul '09

Hi, I see the following behavior and have a couple of questions that would help me debug my new driver/hardware. snd_pcm_lib_read1() - > snd_pcm_update_hw_ptr() ->ops->ack() This enables the driver to send data to hardware for capture snd_pcm_period_elapsed() -> hw_ptr_interrupt This updates the runtime->hw_ptr_jiffies. The jdelta calculated is proper and I find no issues with this. snd_pcm_lib_read1() is returned back Alsa calls driver's ack inbetween here snd_pcm_period_elapsed() -> snd_pcm_update_ hw_ptr_interrupt This updates the runtime->hw_ptr_jiffies. The jdelta calculated is proper and I find no issues with this. snd_pcm_lib_read1() - > snd_pcm_update_ hw_ptr() Here the runtime->hw_ptr_jiffies is updated and this causes my next jdelta to be very less in snd_pcm_period_elapsed() -> snd_pcm_update_hw_ptr_interrupt. Why is runtime->hw_ptr_jiffies updated in hw_ptr()? This should be only updated in the interrupt context right? Without this statement, my driver/hardware works fine. Or is there any constraint I can set somehow such that the hw_ptr_jiffies is only updated in the hw_ptr_interrupt function? Thanks, Harsha

2 2

[alsa-devel] ESI Maya44 Driver
by Dany Svirsky 04 Jul '09

04 Jul '09

Hi All, This subject was disscused before, but it has been very long time without any updates. It been more then half a year since the patch is out. Was someone able to contact Rainer? If not what can be done to finally merge the patch? Is it possible for someone to take over the development of the driver? Thanks, Dany

4 5

[alsa-devel] [PATCH] Allow opt-out from speex dependency
by Ingmar Vanhassel 04 Jul '09

04 Jul '09

--- configure.in | 8 +++++--- 1 files changed, 5 insertions(+), 3 deletions(-) This patch makes the --with-speex configure option work as intended, allowing to explicitly disable speex linking. diff --git a/configure.in b/configure.in index 36740e9..36d0d2a 100644 --- a/configure.in +++ b/configure.in @@ -106,14 +106,16 @@ AC_SUBST(AVCODEC_CFLAGS) AC_SUBST(AVCODEC_LIBS) AC_SUBST(AVCODEC_HEADER) -PKG_CHECK_MODULES(speexdsp, [speexdsp >= 1.2], [HAVE_SPEEXDSP="yes"], [HAVE_SPEEXDSP=""]) -AM_CONDITIONAL(HAVE_SPEEXDSP, test "$HAVE_SPEEXDSP" = "yes") - AC_ARG_WITH([speex], AS_HELP_STRING([--with-speex={builtin|lib|no}], [build speex resampler (built-in code, link with external lib, or no build)]), [PPH=$withval], [PPH="lib"]) +if test "x$with_speex" != "xno"; then + PKG_CHECK_MODULES(speexdsp, [speexdsp >= 1.2], [HAVE_SPEEXDSP="yes"], [HAVE_SPEEXDSP=""]) +fi +AM_CONDITIONAL(HAVE_SPEEXDSP, test "$HAVE_SPEEXDSP" = "yes") + USE_LIBSPEEX="" if test "$PPH" = "lib"; then if test "$HAVE_SPEEXDSP" = "yes"; then -- 1.6.3.3

2 1

[alsa-devel] [PATCH] ALSA: hda - move 8086:fb30 quirk (stac9205) to the proper section
by Herton Ronaldo Krzesinski 04 Jul '09

04 Jul '09

Signed-off-by: Herton Ronaldo Krzesinski <herton(a)mandriva.com.br> --- sound/pci/hda/patch_sigmatel.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/sound/pci/hda/patch_sigmatel.c b/sound/pci/hda/patch_sigmatel.c index 14f3c3e..826b1a0 100644 --- a/sound/pci/hda/patch_sigmatel.c +++ b/sound/pci/hda/patch_sigmatel.c @@ -1590,8 +1590,6 @@ static struct snd_pci_quirk stac9200_cfg_tbl[] = { /* SigmaTel reference board */ SND_PCI_QUIRK(PCI_VENDOR_ID_INTEL, 0x2668, "DFI LanParty", STAC_REF), - SND_PCI_QUIRK(PCI_VENDOR_ID_INTEL, 0xfb30, - "SigmaTel",STAC_9205_REF), SND_PCI_QUIRK(PCI_VENDOR_ID_DFI, 0x3101, "DFI LanParty", STAC_REF), /* Dell laptops have BIOS problem */ @@ -2344,6 +2342,8 @@ static struct snd_pci_quirk stac9205_cfg_tbl[] = { /* SigmaTel reference board */ SND_PCI_QUIRK(PCI_VENDOR_ID_INTEL, 0x2668, "DFI LanParty", STAC_9205_REF), + SND_PCI_QUIRK(PCI_VENDOR_ID_INTEL, 0xfb30, + "SigmaTel", STAC_9205_REF), SND_PCI_QUIRK(PCI_VENDOR_ID_DFI, 0x3101, "DFI LanParty", STAC_9205_REF), /* Dell */

2 1

[alsa-devel] soc_pcm_trigger
by ccku 04 Jul '09

04 Jul '09

Hi, in soc-core.c ,soc_pcm_trigger(), The function only calls three sub-functions codec_dai->ops->trigger platform->pcm_ops->trigger cpu_dai->ops->trigger why not give machine a chance to run its trigger?? like machine->ops->trigger. Thanks static int soc_pcm_trigger(struct snd_pcm_substream *substream, int cmd) { struct snd_soc_pcm_runtime *rtd = substream->private_data; struct snd_soc_device *socdev = rtd->socdev; struct snd_soc_dai_link *machine = rtd->dai; struct snd_soc_card *card = socdev->card; struct snd_soc_platform *platform = card->platform; struct snd_soc_dai *cpu_dai = machine->cpu_dai; struct snd_soc_dai *codec_dai = machine->codec_dai; struct snd_soc_codec *codec = card->codec; mutex_lock(&pcm_mutex); /* apply codec digital mute */ if (!codec->active) snd_soc_dai_digital_mute(codec_dai, 1); /* free any machine hw params */ if (machine->ops && machine->ops->hw_free) machine->ops->hw_free(substream); /* free any DMA resources */ if (platform->pcm_ops->hw_free) platform->pcm_ops->hw_free(substream); /* now free hw params for the DAI's */ if (codec_dai->ops->hw_free) codec_dai->ops->hw_free(substream, codec_dai); if (cpu_dai->ops->hw_free) cpu_dai->ops->hw_free(substream, cpu_dai); mutex_unlock(&pcm_mutex); return 0; }

2 1

[alsa-devel] [PATCH v2] Sample generation on big endian platforms was broken.
by Kenneth Johansson 03 Jul '09

03 Jul '09

Has not worked since commit 3d1fa924906996463ac33cba5b5143f762d913cf Signed-off-by: Kenneth Johansson <kenneth(a)southpole.se> --- Fixes regression for 3 byte format in version 1. tested on both little and big endian platform test/pcm.c | 24 +++++++++++++----------- 1 files changed, 13 insertions(+), 11 deletions(-) diff --git a/test/pcm.c b/test/pcm.c index ee27422..0476c5f 100644 --- a/test/pcm.c +++ b/test/pcm.c @@ -34,14 +34,10 @@ static void generate_sine(const snd_pcm_channel_area_t *areas, static double max_phase = 2. * M_PI; double phase = *_phase; double step = max_phase*freq/(double)rate; - double res; - unsigned char *samples[channels], *tmp; + unsigned char *samples[channels]; int steps[channels]; - unsigned int chn, byte; - union { - int i; - unsigned char c[4]; - } ires; + unsigned int chn; + unsigned int maxval = (1 << (snd_pcm_format_width(format) - 1)) - 1; int bps = snd_pcm_format_width(format) / 8; /* bytes per sample */ @@ -61,12 +57,18 @@ static void generate_sine(const snd_pcm_channel_area_t *areas, } /* fill the channel areas */ while (count-- > 0) { + int res,i; res = sin(phase) * maxval; - ires.i = res; - tmp = ires.c; for (chn = 0; chn < channels; chn++) { - for (byte = 0; byte < (unsigned int)bps; byte++) - *(samples[chn] + byte) = tmp[byte]; + /* Generate data in native endian format */ + for ( i=0 ; i < bps ; i++ ){ +#if (__BYTE_ORDER == __BIG_ENDIAN) + *(samples[chn] + bps-1-i) = (res >> i*8) & 0xff; +#else + + *(samples[chn] + i) = (res >> i*8) & 0xff; +#endif + } samples[chn] += steps[chn]; } phase += step; -- 1.6.1.GIT

2 1

[alsa-devel] Conexant CX20582 HDA codec support
by Daniel Drake 03 Jul '09

03 Jul '09

Hi, I'm working on some sound issues with the new OLPC XO-1.5 alpha board. This laptop is now based on a VIA VX855 chipset and our board includes a CX20582-10Q HDA codec. We are running kernel v2.6.30. We have a few issues, which are: 1. Volume range is ridiculous, you can go all the way down to -74dB gain. Beyond -42dB you can barely hear anything from the speakers, and I note that all my other systems only go down as far as -46.5dB. 2. No microphone automute. The internal microphone continues recording sound while there is an external one plugged in. 3. No speaker automute. The internal speakers continue playing sound while there are headphones plugged in. 4. Mixer arrangement is odd. There are 3 microphones: Mic, Mic 1, and Mic 2. Mic (the default) records nothing. Mic 1 and Mic 2 both seem to behave the same, and record from both internal and external microphones. I looked into adding some quirks into patch_conexant.c to hopefully solve some of the above. However I note that there is no support for the CX20582, hence the generic HDA parser is being used. How has support for the other CX chips been developed -- are datasheets always required? (I'll try and get hold of one anyway) Here is some more info. codec dump http://dev.laptop.org/~dsd/20090629/codec0.txt codec graph http://dev.laptop.org/~dsd/20090629/codecgraph.svg lspci entry http://dev.laptop.org/~dsd/20090629/lspci-entry.txt verbose dmesg from probing http://dev.laptop.org/~dsd/20090629/dmesg-probe.txt Any thoughts/input appreciated! Thanks, Daniel

4 8