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

Re: [alsa-devel] [Jack-Devel] Says: server is not connected, even though it has been!
by Guilherme Longo 10 Jul '09

10 Jul '09

Yes Patrick.... same user for both Really strange, isn't it! Patrick Shirkey wrote: > > On 07/10/2009 05:20 PM, Guilherme Longo wrote: >> Hi all! >> >> I couldn't find where this problem comes from. > > Hi, > > Sorry, to ask the obvious but, are you running as the same user for > the server and the simple_client? > > > Patrick Shirkey > Boost Hardware Ltd > > > >> I am connecting jack with the command: >> >> jackd -d alsa -d default >> >> and appears right below: >> >> bash-3.1# jackd -d alsa -d default >> jackdmp 1.9.2 >> Copyright 2001-2005 Paul Davis and others. >> Copyright 2004-2008 Grame. >> jackdmp comes with ABSOLUTELY NO WARRANTY >> This is free software, and you are welcome to redistribute it >> under certain conditions; see the file COPYING for details >> JACK server starting in non-realtime mode >> creating alsa driver ... >> default|default|1024|2|48000|0|0|nomon|swmeter|-|32bit >> Using ALSA driver EMU10K1 running on SB Live [Unknown] (rev.10, >> serial:0x80671102) at 0xd000, irq 18 >> configuring for 48000Hz, period = 1024 frames (21.3 ms), buffer = 2 >> periods >> ALSA: final selected sample format for capture: 32bit float >> little-endian >> You appear to be using the ALSA software "plug" layer, probably >> a result of using the "default" ALSA device. This is less >> efficient than it could be. Consider using a hardware device >> instead rather than using the plug layer. Usually the name of the >> hardware device that corresponds to the first soun >> ALSA: use 2 periods for capture >> ALSA: final selected sample format for playback: 32bit float >> little-endian >> You appear to be using the ALSA software "plug" layer, probably >> a result of using the "default" ALSA device. This is less >> efficient than it could be. Consider using a hardware device >> instead rather than using the plug layer. Usually the name of the >> hardware device that corresponds to the first soun >> ALSA: use 2 periods for playback >> >> >> In another terminal, I am running a simple_cliente, and when I run it >> with the code: >> >> quart$: simple_client audiofile >> jack server not running? >> >> It is resulting of: >> >> if ((client = jack_client_open(argv[1], JackNoStartServer, NULL)) == >> 0) { >> fprintf (stderr, "jack server not running?\n"); >> return 1; >> } >> >> >> Plz, can I get som help here. >> Tks. >> _______________________________________________ >> Jack-Devel mailing list >> Jack-Devel(a)lists.jackaudio.org >> http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org >

1 0

[alsa-devel] Bug report: Random MIDI output data drop-outs/corruption
by Sean M. Pappalardo 10 Jul '09

10 Jul '09

Hello there. I just wanted to call your attention to a bug report I recently filed, because I'm not sure I put it in the right place: https://bugtrack.alsa-project.org/alsa-bug/view.php?id=4606 In a nutshell, ALSA seems to be dropping or corrupting output MIDI messages (both "short" and SysEx) at random as evidenced by the devices not lighting some LEDs or changing modes (sysex) on occasion. The problem is positively affected, but not completely mitigated, by the use of a real-time kernel. aseqdump -d shows everything correctly even when the device response is incorrect. All details are in that bug report including links to alsa-info output in the notes. Thanks for your time. Let me know if I can provide any further information. Sincerely, Sean M. Pappalardo "D.J. Pegasus" <<--------------------------------------------------------------------------------->> This E-Mail message has been scanned for viruses and cleared by >>SmartMail<< from Smarter Technology, Inc. <<--------------------------------------------------------------------------------->>

1 0

[alsa-devel] problems on AT91 with SSC not generating frame sync on RF0 pin
by Stefan Schoenleitner 10 Jul '09

10 Jul '09

Hi, I wrote an ALSA machine driver for the WM8731 codec on the AT91SAM9260 platform (for code see end of mail). I'm using the latest ALSA sound-2.6 tree from git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-2.6.git The audio codec is configured as I2S slave, so that the SSC is responsible to create the BCLK and LRC frame sync signals. my problem is that while playing audio works (and a LRC signal is created on the TF0 pin), recording does not work since there is no LRC signal on the RF0 pin. The connection between SSC and wm8731 is the following: codec SSC <-- BCLK/TK0 -- <-- ADCLRC/RF0 -- <-- DACLRC/TF0 -- <-- DACDAT/TD0 -- -- ADCDAT/RD0 --> In my board file I'm initializing the SSC with the following function call: ------------------------------------------------------------------------ static void __init ek_board_init(void) { .... at91_add_device_ssc(AT91SAM9260_ID_SSC, ATMEL_SSC_TK | ATMEL_SSC_RF | ATMEL_SSC_TF | ATMEL_SSC_TD | ATMEL_SSC_RD); .... } ------------------------------------------------------------------------ In arch/arm/mach-at91/at91sam9260_devices.c this leads to the following calls: ------------------------------------------------------------------------ static inline void configure_ssc_pins(unsigned pins) { if (pins & ATMEL_SSC_TF) at91_set_A_periph(AT91_PIN_PB17, 1); if (pins & ATMEL_SSC_TK) at91_set_A_periph(AT91_PIN_PB16, 1); if (pins & ATMEL_SSC_TD) at91_set_A_periph(AT91_PIN_PB18, 1); if (pins & ATMEL_SSC_RD) at91_set_A_periph(AT91_PIN_PB19, 1); if (pins & ATMEL_SSC_RK) at91_set_A_periph(AT91_PIN_PB20, 1); if (pins & ATMEL_SSC_RF) at91_set_A_periph(AT91_PIN_PB21, 1); } ------------------------------------------------------------------------ Then in the machine driver I'm initializing both codec and cpu DAI with SND_SOC_DAIFMT_I2S | SND_SOC_DAIFMT_CBS_CFS. For this reason the SSC is I2S master and has to generate the clock and frame sync signals. By looking at atmel_ssc_dai.c (and putting some printk() debug code there) I verified that the SSC registers are correctly set up so that the RF0 pin is configured as output. As mentioned playing audio works just fine. Thus by attaching a scope to the TF0 pin (which carries the transmitter frame sync signal) I can see that the signal is alright. However, if I record something with arecord, the SSC receiver is enabled, but no frame sync pulses can be seen on the RF0 pin. Therefore also audio recording does not work since there is no data being transfered from the codec to the SSC. The kernel output (with some debug code added) looks good: ------------------------------------------------------------------------ Jul 9 22:30:52 devboard kernel: atmel_ssc_startup: SSC_SR=0x12 Jul 9 22:30:52 devboard kernel: sam9l9260_startup() Jul 9 22:30:52 devboard kernel: asoc: WM8731 <-> atmel-ssc0 info: Jul 9 22:30:52 devboard kernel: asoc: rate mask 0x6fe Jul 9 22:30:52 devboard kernel: asoc: min ch 1 max ch 2 Jul 9 22:30:52 devboard kernel: asoc: min rate 8000 max rate 96000 Jul 9 22:30:52 devboard kernel: sam9l9260_hw_params() Jul 9 22:30:52 devboard kernel: sam9l9260_hw_params: sample rate is 44100 Hz Jul 9 22:30:52 devboard kernel: sam9l9260_hw_params: substream->stream is SNDRV_PCM_STREAM_CAPTURE Jul 9 22:30:52 devboard kernel: sam9l9260_hw_params: snd_soc_dai_set_clkdiv() --> I'm receiver ! Jul 9 22:30:52 devboard kernel: atmel_ssc_hw_params: setting up for SND_SOC_DAIFMT_I2S | SND_SOC_DAIFMT_CBS_CFS Jul 9 22:30:52 devboard kernel: atmel_ssc_hw_params: RCMR=21010420 RFMR=001f018f TCMR=00010404 TFMR=001f018f Jul 9 22:30:52 devboard kernel: atmel_ssc_dai: Starting clock Jul 9 22:30:52 devboard kernel: atmel_ssc_dai,hw_params: SSC initialized Jul 9 22:30:52 devboard kernel: atmel-pcm: hw_params: DMA for SSC0 PCM in initialized (dma_bytes=32768, period_size=8192) Jul 9 22:30:52 devboard kernel: receive enabled SSC_SR=0x0002040c Jul 9 22:30:53 devboard kernel: atmel-pcm:buffer_size = 8192,dma_area = ffc1b000, dma_bytes = 32768 Jul 9 22:30:53 devboard kernel: atmel-pcm: trigger: period_ptr=23a9a000, xpr=598310912, xcr=4096, xnpr=598319104, xncr=4096 Jul 9 22:30:53 devboard kernel: sr=133164 imr=0 atmel-pcm:buffer_size = 8192,dma_area = ffc1b000, dma_bytes = 32768 atmel_ssc_shutdown: receive disabled SSC_SR=0x0002083c atmel_ssc_dau: Stopping clock Jul 9 22:36:04 devboard kernel: atmel-pcm:buffer_size = 8192,dma_area = ffc1b000, dma_bytes = 32768 Jul 9 22:36:04 devboard kernel: atmel_ssc_shutdown: receive disabled SSC_SR=0x0002083c Jul 9 22:36:04 devboard kernel: atmel_ssc_dau: Stopping clock Jul 9 22:36:04 devboard kernel: sam9l9260_shutdown() Unregistered DAI 'WM8731' Unregistered codec 'WM8731' Unregistered DAI 'atmel-ssc0' Unregistered platform 'atmel-audio' Jul 9 22:36:18 devboard kernel: Unregistered DAI 'WM8731' Jul 9 22:36:18 devboard kernel: Unregistered codec 'WM8731' Jul 9 22:36:18 devboard kernel: Unregistered DAI 'atmel-ssc0' Jul 9 22:36:18 devboard kernel: Unregistered platform 'atmel-audio' ------------------------------------------------------------------------ As you can see above, the receiver is enabled (SNDRV_PCM_STREAM_CAPTURE), the clock is set for the receiver and the SSC starts to generate the BCLK (which can be measured with tthe scope). Also the SSC registers should be configured correctly (thus the RF0 pin should be output for frame sync), but it still does not work. I also checked for hardware problems by completely disconnecting the SSC from the codec and directly attaching the lines to a scope. The result it the same: While playing sound produces the correct signals, recording does not do so since there is no frame sync on the RF0 pin. I also checked for bad solder junctions and I did do the measurements directly on the tiny AT91SAM9260 controller pins as well (with the same result). And of course I also looked at the schematic and verified that the pins are not connected to anything else. Also, the pins are not anywhere else in my kernel sources as for the SSC (I verified this by looking at the code and searching for the relevant pin names). I read the relevant sections in the at91sam9260 and wm8731 datasheets very carefully and also verified that the setup is according to specification as well. I'm pretty sure that it is a software problem somewhere, but after so much time trying to fix the problem I no longer have any ideas what could be wrong. For my understanding the pins need to be multiplexed for use with the SSC. I verified this and the pins are indeed multiplexed with calls to at91_set_A_periph() on the according pins (see code snippet above). Once this has been done the pins should be ready for use with the SSC. Thus once the SSC registers are configured (which they verifiably are in atmel_ssc_dai.c) the pins should behave according to the SSC register configuration. And since the SSC registers are configured in a way that the RF0 pin is an ouput with with the LR frame sync signal for the receive on it, it should also work (which it doesn't). If you have any ideas why it is not working I would be very grateful. sincerely, Stefan machine driver code: ------------------------------------------------------------------------ #include <linux/module.h> #include <linux/moduleparam.h> #include <linux/kernel.h> #include <linux/timer.h> #include <linux/interrupt.h> #include <linux/platform_device.h> #include <linux/i2c.h> #include <linux/atmel-ssc.h> #include <sound/core.h> #include <sound/pcm.h> #include <sound/pcm_params.h> #include <sound/soc.h> #include <sound/soc-dapm.h> #include <asm/mach-types.h> #include <mach/hardware.h> #include <mach/gpio.h> #include "../codecs/wm8731.h" #include "atmel-pcm.h" #include "atmel_ssc_dai.h" #define MCLK_RATE 12288000 static int sam9l9260_startup(struct snd_pcm_substream *substream) { struct snd_soc_pcm_runtime *rtd = snd_pcm_substream_chip(substream); struct snd_soc_dai *codec_dai = rtd->dai->codec_dai; int ret; printk(KERN_INFO "sam9l9260_startup()\n"); ret = snd_soc_dai_set_sysclk(codec_dai, WM8731_SYSCLK, MCLK_RATE, SND_SOC_CLOCK_IN); if (ret < 0) { return ret; } return 0; } static void sam9l9260_shutdown(struct snd_pcm_substream *substream) { struct snd_soc_pcm_runtime *rtd = snd_pcm_substream_chip(substream); printk(KERN_INFO "sam9l9260_shutdown()\n"); dev_dbg(rtd->socdev->dev, "shutdown"); } static int sam9l9260_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_dai *codec_dai = rtd->dai->codec_dai; struct snd_soc_dai *cpu_dai = rtd->dai->cpu_dai; struct atmel_ssc_info *ssc_p = cpu_dai->private_data; struct ssc_device *ssc = ssc_p->ssc; int ret; unsigned int rate; int cmr_div, period; printk(KERN_INFO "sam9l9260_hw_params()\n"); if (ssc == NULL) { printk(KERN_INFO "sam9l9260_hw_params: ssc is NULL!\n"); return -EINVAL; } /* set codec DAI configuration */ ret = snd_soc_dai_set_fmt(codec_dai, SND_SOC_DAIFMT_I2S | SND_SOC_DAIFMT_NB_NF | SND_SOC_DAIFMT_CBS_CFS); if (ret < 0) return ret; /* set cpu DAI configuration */ /* * atmel_ssc_dai.c * SND_SOC_DAIFMT_I2S | SND_SOC_DAIFMT_CBS_CFS * --> I2S format, SSC provides BCLK and LRC clocks. * * SND_SOC_DAIFMT_I2S | SND_SOC_DAIFMT_CBM_CFM: * --> I2S format, CODEC supplies BCLK and LRC clocks. */ ret = snd_soc_dai_set_fmt(cpu_dai, SND_SOC_DAIFMT_I2S | SND_SOC_DAIFMT_NB_NF | SND_SOC_DAIFMT_CBS_CFS); if (ret < 0) return ret; /* * The SSC clock dividers depend on the sample rate. The CMR.DIV * field divides the system master clock MCK to drive the SSC TK * signal which provides the codec BCLK. The TCMR.PERIOD and * RCMR.PERIOD fields further divide the BCLK signal to drive * the SSC TF and RF signals which provide the codec DACLRC and * ADCLRC clocks. * * The dividers were determined through trial and error, where a * CMR.DIV value is chosen such that the resulting BCLK value is * divisible, or almost divisible, by (2 * sample rate), and then * the TCMR.PERIOD or RCMR.PERIOD is BCLK / (2 * sample rate) - 1. * * AT91SAM9260 datasheet: * CMR - clock mode register - p. 492 * CMR.DIV is 12-bit value, the divided clock equals * the master clock devided by 2 times DIV * * TCMR - transmit clock mode register - p. 497 * TCMR.PERIOD is 8-bit value, divider for frame sync signal (LRCLK). * (Also called: WM8731 --> DACLRC, TLV320AIC23 --> LRCIN) * A period signal is generated each 2*(PERIOD+1) transmit clock * * RCMR - receive clock mode register - p. 493 * RCMR.PERIOD is 8-bit value, divider for frame sync signal (LRCLK). * (Also called: WM8731 --> ADCLRC, TLV320AIC23 --> LRCOUT) * A period signal is generated each 2*(PERIOD+1) receive clock * * The LRCLK sync signals needs to be as close to the sampling rate as possible. * * The following register values have been calculated with my * wm8731_calculate_ssc_dividers.pl script. * * According to the wm8731 datasheet, the minimum BCLK cycle time is 50 ns. * That would be f = 1/T = 1/0,050us = 20 MHz */ rate = params_rate(params); printk(KERN_INFO "sam9l9260_hw_params: sample rate is %i Hz\n", rate); switch (rate) { case 8000: cmr_div=29; /* BCLK = 90 MHz / (2*29) ~= 1.551 MHz */ period=96; /* LRC = BCLK/(2*(96+1)) ~= 7998.6 Hz */ break; case 11025: cmr_div=13; /* BCLK ~= 3.461 Mhz */ period=156; /* LRC ~= 11024.0 Hz */ break; case 16000: cmr_div=38; /* BCLK ~= 1.184 */ period=36; /* LRC ~= 16002.8 */ break; case 22050: cmr_div=17; /* BCLK ~= 2.647 */ period=59; /* LRC ~= 22058.8 */ break; case 32000: cmr_div=19; /* BCLK ~= 2.368 */ period=36; /* LRC ~= 32005.6 */ break; case 44100: cmr_div=15; /* BCLK ~= 3.000 */ period=33; /* LRC ~= 44117.6 */ break; case 48000: cmr_div=7; /* BCLK ~= 6.428 */ period=66; /* LRC ~= 47974.4 */ break; case 88200: cmr_div=5; /* BCLK ~= 9.000 */ period=50; /* LRC ~= 88235.3 */ break; case 96000: cmr_div=6; /* BCLK ~= 7.500 */ period=38; /* LRC ~= 96153.8 */ break; default: printk(KERN_WARNING "unsupported rate %d" " on at91sam9g20ek board\n", rate); return -EINVAL; } /* set the MCK divider for BCLK */ ret = snd_soc_dai_set_clkdiv(cpu_dai, ATMEL_SSC_CMR_DIV, cmr_div); if (ret < 0) return ret; switch (substream->stream) { case SNDRV_PCM_STREAM_PLAYBACK: printk(KERN_DEBUG "%s: substream->stream is SNDRV_PCM_STREAM_PLAYBACK\n", __func__); break; case SNDRV_PCM_STREAM_CAPTURE: printk(KERN_DEBUG "%s: substream->stream is SNDRV_PCM_STREAM_CAPTURE\n", __func__); break; default: printk(KERN_DEBUG "%s: substream->stream is INVALID !!!\n", __func__); break; } if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) { /* set the BCLK divider for DACLRC */ ret = snd_soc_dai_set_clkdiv(cpu_dai, ATMEL_SSC_TCMR_PERIOD, period); printk(KERN_DEBUG "%s: snd_soc_dai_set_clkdiv() --> I'm transmitter !\n", __func__); } else { /* set the BCLK divider for ADCLRC */ ret = snd_soc_dai_set_clkdiv(cpu_dai, ATMEL_SSC_RCMR_PERIOD, period); printk(KERN_DEBUG "%s: snd_soc_dai_set_clkdiv() --> I'm receiver !\n", __func__); } if (ret < 0) return ret; return 0; } static struct snd_soc_ops sam9l9260_ops = { .startup = sam9l9260_startup, .hw_params = sam9l9260_hw_params, .shutdown = sam9l9260_shutdown, }; static const struct snd_soc_dapm_widget sam9l9260_dapm_widgets[] = { SND_SOC_DAPM_MIC("Mic", NULL), SND_SOC_DAPM_SPK("Phones", NULL), }; static const struct snd_soc_dapm_route intercon[] = { /* speaker connected to LHPOUT */ {"Phones", NULL, "LHPOUT"}, /* mic is connected to Mic Jack, with WM8731 Mic Bias */ {"MICIN", NULL, "Mic Bias"}, {"Mic Bias", NULL, "Mic"}, }; /* * Logic for a wm8731 as connected on a at91sam9g20ek board. */ static int sam9l9260_wm8731_init(struct snd_soc_codec *codec) { printk(KERN_DEBUG "sam9l9260_wm8731 " ": sam9l9260_wm8731_init() called\n"); printk(KERN_INFO "sam9l9260_wm8731_init()\n"); /* Add specific widgets */ snd_soc_dapm_new_controls(codec, sam9l9260_dapm_widgets, ARRAY_SIZE(sam9l9260_dapm_widgets)); /* Set up specific audio path interconnects */ snd_soc_dapm_add_routes(codec, intercon, ARRAY_SIZE(intercon)); /* not connected */ snd_soc_dapm_nc_pin(codec, "RLINEIN"); snd_soc_dapm_nc_pin(codec, "LLINEIN"); snd_soc_dapm_nc_pin(codec, "ROUT"); snd_soc_dapm_nc_pin(codec, "LOUT"); /* always connected */ snd_soc_dapm_enable_pin(codec, "Mic"); snd_soc_dapm_enable_pin(codec, "Phones"); snd_soc_dapm_sync(codec); return 0; } static struct snd_soc_dai_link sam9l9260_dai = { .name = "WM8731", .stream_name = "WM8731 PCM", .cpu_dai = &atmel_ssc_dai[0], .codec_dai = &wm8731_dai, .init = sam9l9260_wm8731_init, .ops = &sam9l9260_ops, }; static struct snd_soc_card snd_soc_at91sam9g20ek = { .name = "SAM9-L9260", .platform = &atmel_soc_platform, .dai_link = &sam9l9260_dai, .num_links = 1, }; static struct snd_soc_device sam9l9260_snd_devdata = { .card = &snd_soc_at91sam9g20ek, .codec_dev = &soc_codec_dev_wm8731, }; static struct platform_device *sam9l9260_snd_device; static int __init sam9l9260_init(void) { struct atmel_ssc_info *ssc_p = sam9l9260_dai.cpu_dai->private_data; struct ssc_device *ssc = NULL; int ret; printk(KERN_INFO "sam9l9260_init()\n"); /* Olimex SAM9-L9260 board */ if (!(machine_is_sam9_l9260())) return -ENODEV; /* * Request SSC device */ ssc = ssc_request(0); if (IS_ERR(ssc)) { printk(KERN_ERR "ASoC: Failed to request SSC 0\n"); ret = PTR_ERR(ssc); ssc = NULL; goto err_ssc; } ssc_p->ssc = ssc; sam9l9260_snd_device = platform_device_alloc("soc-audio", -1); if (!sam9l9260_snd_device) { printk(KERN_ERR "ASoC: Platform device allocation failed\n"); ret = -ENOMEM; } platform_set_drvdata(sam9l9260_snd_device, &sam9l9260_snd_devdata); sam9l9260_snd_devdata.dev = &sam9l9260_snd_device->dev; ret = platform_device_add(sam9l9260_snd_device); if (ret) { printk(KERN_ERR "ASoC: Platform device allocation failed\n"); platform_device_put(sam9l9260_snd_device); } return ret; err_ssc: ssc_free(ssc); ssc_p->ssc = NULL; return ret; } static void __exit sam9l9260_exit(void) { struct atmel_ssc_info *ssc_p = sam9l9260_dai.cpu_dai->private_data; struct ssc_device *ssc; if (ssc_p != NULL) { ssc = ssc_p->ssc; if (ssc != NULL) ssc_free(ssc); ssc_p->ssc = NULL; } platform_device_unregister(sam9l9260_snd_device); sam9l9260_snd_device = NULL; } module_init(sam9l9260_init); module_exit(sam9l9260_exit); MODULE_DESCRIPTION("ALSA SoC sam9l9260_WM8731"); MODULE_LICENSE("GPL"); ------------------------------------------------------------------------

1 0

[alsa-devel] save alsa buffer
by arif setiawan 10 Jul '09

10 Jul '09

Hi, I am trying to save content of alsa buffer to file for playing it in Matlab.I choose Matlab for prototyping. I run full duplex ALSA based on code from http://www.bel.fi/~alankila/blog/2005/08/21/Full Duplex ALSA.html<http://www.bel.fi/%7Ealankila/blog/2005/08/21/Full%20Duplex%20ALSA.html> I run alsa on Beagleboard. I want to save buffer content to a file, but it failed with error: Segmentation fault when reach fclose(fp). I want to know what kind of data that ALSA processes so I can implement my LPC vocoder. Thank you. Best regards, Arif

1 0

[alsa-devel] runtime->boundary
by Harsha, Priya 10 Jul '09

10 Jul '09

Hi, Can anyone help explain what is runtime->boundary and what is the value that is set for this? It seems to be a pretty huge value when I try and print it. Also in snd_pcm_indiret_capture_transfer, I see this code snippet; If (diff < runtime->boundary /2) diff += runtime->boundary what is the reason for the same? If its for handling ring buffer wrapping, should I be setting my runtime->boundary to rumtime->buffer_size in the driver code? Thanks, Harsha

2 1

[alsa-devel] No incoming sound indigo iox
by Susan Cragin 10 Jul '09

10 Jul '09

I just purchased the indigoaudio iox. Outgoing shows up on Volume Control, incoming does not. In Audacity, incoming shows up as: ALSA: Indigo IOx (hw:1,0) but recording does not work. Here's the catch. My problem may be due to my kernel. I am running Ubuntu-Studio and have the 29.5-2-rt experimental kernel, which is the 5-1 recompiled with alsadriver support for 30 kernels. So you may just tell me to go away until the kernel's better, but I don't think the kernel is the problem. FYI winecfg says: fixme:mixer:ALSA_MixerInit No master control found on Indigo IOx, disabling mixer

2 1

[alsa-devel] targa and targa-2ch fix for 2.6.31
by okias 09 Jul '09

09 Jul '09

Simplify ALC882_TARGA and return gpio3 to ALC883_TARGA_DIG and ALC883_TARGA_2ch_DIG, which I accidentally removed in commit id 64a8be74357477558183b43156c5536b642de134 Signed-off-by: David Heidelberger <d.okias(a)gmail.com> --- --- sound/pci/hda/patch_realtek.c 2009-07-09 17:36:37.593323363 +0200 +++ sound/pci/hda/patch_realtek.c 2009-07-09 17:57:31.014574807 +0200 @@ -6895,9 +6895,6 @@ static struct hda_verb alc882_targa_verb {0x1b, AC_VERB_SET_CONNECT_SEL, 0x00}, /* HP */ {0x14, AC_VERB_SET_UNSOLICITED_ENABLE, ALC880_HP_EVENT | AC_USRSP_EN}, - {0x01, AC_VERB_SET_GPIO_MASK, 0x03}, - {0x01, AC_VERB_SET_GPIO_DIRECTION, 0x03}, - {0x01, AC_VERB_SET_GPIO_DATA, 0x03}, { } /* end */ }; @@ -7217,7 +7214,8 @@ static struct alc_config_preset alc882_p }, [ALC882_TARGA] = { .mixers = { alc882_targa_mixer, alc882_chmode_mixer }, - .init_verbs = { alc882_init_verbs, alc882_targa_verbs}, + .init_verbs = { alc882_init_verbs, alc880_gpio3_init_verbs, + alc882_targa_verbs}, .num_dacs = ARRAY_SIZE(alc882_dac_nids), .dac_nids = alc882_dac_nids, .dig_out_nid = ALC882_DIGOUT_NID, @@ -9212,7 +9210,8 @@ static struct alc_config_preset alc883_p }, [ALC883_TARGA_DIG] = { .mixers = { alc883_targa_mixer, alc883_chmode_mixer }, - .init_verbs = { alc883_init_verbs, alc883_targa_verbs}, + .init_verbs = { alc883_init_verbs, alc880_gpio3_init_verbs, + alc883_targa_verbs}, .num_dacs = ARRAY_SIZE(alc883_dac_nids), .dac_nids = alc883_dac_nids, .dig_out_nid = ALC883_DIGOUT_NID, @@ -9225,7 +9224,8 @@ static struct alc_config_preset alc883_p }, [ALC883_TARGA_2ch_DIG] = { .mixers = { alc883_targa_2ch_mixer}, - .init_verbs = { alc883_init_verbs, alc883_targa_verbs}, + .init_verbs = { alc883_init_verbs, alc880_gpio3_init_verbs, + alc883_targa_verbs}, .num_dacs = ARRAY_SIZE(alc883_dac_nids), .dac_nids = alc883_dac_nids, .adc_nids = alc883_adc_nids_alt, -- Jabber/XMPP: okias(a)isgeek.info SIP VoIP: sip:17474537254@proxy01.sipphone.com

2 1

[alsa-devel] [PATCH] snd-hda-intel: fix beep tone calculation for IDT/STAC codecs
by Paul Vojta 09 Jul '09

09 Jul '09

In the beep tone calculation for IDT/STAC codecs, lower numbers correspond to higher frequencies and vice versa. The current code has this backwards, resulting in beep frequencies which are way too high (and sound bad on tinny laptop speakers, resulting in complaints). Signed-off-by: Paul Vojta <vojta(a)math.berkeley.edu> diff --git a/sound/pci/hda/hda_beep.c b/sound/pci/hda/hda_beep.c index 08fe659..d559a7a 100644 --- a/sound/pci/hda/hda_beep.c +++ b/sound/pci/hda/hda_beep.c @@ -51,19 +51,20 @@ static void snd_hda_generate_beep(struct work_struct *work) * The tone frequency of beep generator on IDT/STAC codecs is * defined from the 8bit tone parameter, in Hz, * freq = 48000 * (257 - tone) / 1024 - * that is from 12kHz to 93.75kHz in step of 46.875 hz + * that is from 12kHz to 93.75Hz in steps of 46.875 Hz */ static int beep_linear_tone(struct hda_beep *beep, int hz) { hz *= 1000; /* fixed point */ - hz = hz - DIGBEEP_HZ_MIN; + hz = hz - DIGBEEP_HZ_MIN + + DIGBEEP_HZ_STEP / 2; /* round to nearest step */ if (hz < 0) hz = 0; /* turn off PC beep*/ else if (hz >= (DIGBEEP_HZ_MAX - DIGBEEP_HZ_MIN)) - hz = 0xff; + hz = 1; /* max frequency */ else { hz /= DIGBEEP_HZ_STEP; - hz++; + hz = 255 - hz; } return hz; }

2 1

[alsa-devel] [PATCH] [resend] cmi8330: find OPL3 port automatically
by Ondrej Zary 09 Jul '09

09 Jul '09

My CMI8329 had OPL3 port specified in SB16 resources. But now I found out that it was my modification of the card's PnP EEPROM a couple of years ago (can be done using C9SETROM.EXE utility). I did it because the OPL3 port was completely missing from PnP data. It seems to be hardwired to 0x388 on CMI8329. Find OPL3 port automatically by searching in WSS and SB16 resources. If not found, assume that it's hardwired to 0x388. Signed-off-by: Ondrej Zary <linux(a)rainbow-software.org> --- linux-test/sound/isa/cmi8330.c 2009-07-06 21:18:06.000000000 +0200 +++ linux-2.6.30-pentium/sound/isa/cmi8330.c 2009-07-06 21:45:29.000000000 +0200 @@ -362,7 +362,7 @@ wssport[dev] = pnp_port_start(pdev, 0); wssdma[dev] = pnp_dma(pdev, 0); wssirq[dev] = pnp_irq(pdev, 0); - if (acard->type == CMI8330) + if (pnp_port_start(pdev, 1)) fmport[dev] = pnp_port_start(pdev, 1); /* allocate SB16 resources */ @@ -377,8 +377,13 @@ 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); + /* On CMI8239, the OPL3 port might be present in SB16 PnP resources */ + if (fmport[dev] == SNDRV_AUTO_PORT) { + if (pnp_port_start(pdev, 1)) + fmport[dev] = pnp_port_start(pdev, 1); + else + fmport[dev] = 0x388; /* Or hardwired */ + } /* allocate MPU-401 resources */ pdev = acard->mpu; -- Ondrej Zary

2 2

[alsa-devel] ASoC updates for 2.6.32
by Mark Brown 09 Jul '09

09 Jul '09

The following changes since commit 4ec5c9693b46ab34976511cd43bf75c3a0fc704d: Mark Brown (1): Merge branch 'for-2.6.31' into for-2.6.32 are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound-2.6.git for-2.6.32 Chaithrika U S (4): ASoC: Introduce platform driver model for dm644x, dm355 ASoC: Add mcasp support for DM646x ASoC: Add machine driver support for DM646x ASoC: Minor fixes to DaVinci I2S probe function Mark Brown (5): Merge branch 'davinci' into for-2.6.32 ASoC: Add TLV information for WM8731 ASoC: Correct WM8731 Mic Capture Switch control name ASoC: DaVinci I2S needs mach/asp.h ASoC: Add WM8993 CODEC driver Troy Kisky (1): ASoC: DaVinci: pcm, don't play 1st sound period twice include/sound/wm8993.h | 44 + sound/soc/codecs/Kconfig | 4 + sound/soc/codecs/Makefile | 2 + sound/soc/codecs/wm8731.c | 17 +- sound/soc/codecs/wm8993.c | 2203 +++++++++++++++++++++++++++++++++++++ sound/soc/codecs/wm8993.h | 2132 +++++++++++++++++++++++++++++++++++ sound/soc/davinci/Kconfig | 13 + sound/soc/davinci/Makefile | 3 + sound/soc/davinci/davinci-evm.c | 102 +- sound/soc/davinci/davinci-i2s.c | 123 ++- sound/soc/davinci/davinci-mcasp.c | 874 +++++++++++++++ sound/soc/davinci/davinci-mcasp.h | 55 + sound/soc/davinci/davinci-pcm.c | 1 + sound/soc/davinci/davinci-pcm.h | 18 +- 14 files changed, 5473 insertions(+), 118 deletions(-) create mode 100644 include/sound/wm8993.h create mode 100644 sound/soc/codecs/wm8993.c create mode 100644 sound/soc/codecs/wm8993.h create mode 100644 sound/soc/davinci/davinci-mcasp.c create mode 100644 sound/soc/davinci/davinci-mcasp.h

2 1