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

[alsa-devel] snd-hda-intel module now working
by randall 19 Jun '08

19 Jun '08

After rebuilding the kernel about 5 times and double-checking the KMixer controls, I have finally successfully been able to get the onboard sound working. Took 2 days tweaking and rebuilding the kernel. I used the "3stack-6ch-dig" setting for the model and turned on a SND debug variable. - Randall

2 2

[alsa-devel] [PATCH - asihpi 2/2] Disable S24_3LE incompatible with 2^N buffer size.
by linux＠audioscience.com 19 Jun '08

19 Jun '08

From: Eliot Blennerhassett <eblennerhassett(a)audioscience.com> Signed-off-by: Eliot Blennerhassett <eblennerhassett(a)audioscience.com> diff --git a/pci/asihpi/asihpi.c b/pci/asihpi/asihpi.c index ab90b08..c715ad2 100644 --- a/pci/asihpi/asihpi.c +++ b/pci/asihpi/asihpi.c @@ -328,21 +328,28 @@ static void print_hwparams(struct snd_pcm_hw_params *p) static snd_pcm_format_t hpi_to_alsa_formats[] = { -1, /* INVALID */ - SNDRV_PCM_FORMAT_U8, /* { HPI_FORMAT_PCM8_UNSIGNED 1 */ - SNDRV_PCM_FORMAT_S16, /* { HPI_FORMAT_PCM16_SIGNED 2 */ - -1, /* { HPI_FORMAT_MPEG_L1 3 */ - SNDRV_PCM_FORMAT_MPEG, /* { HPI_FORMAT_MPEG_L2 4 */ - SNDRV_PCM_FORMAT_MPEG, /* { HPI_FORMAT_MPEG_L3 5 */ - -1, /* { HPI_FORMAT_DOLBY_AC2 6 */ - -1, /* { HPI_FORMAT_DOLBY_AC3 7 */ - SNDRV_PCM_FORMAT_S16_BE,/* { HPI_FORMAT_PCM16_BIGENDIAN 8 */ - -1, /* { HPI_FORMAT_AA_TAGIT1_HITS 9 */ - -1, /* { HPI_FORMAT_AA_TAGIT1_INSERTS 10 */ - SNDRV_PCM_FORMAT_S32, /* { HPI_FORMAT_PCM32_SIGNED 11 */ - -1, /* { HPI_FORMAT_RAW_BITSTREAM 12 */ - -1, /* { HPI_FORMAT_AA_TAGIT1_HITS_EX1 13 */ - SNDRV_PCM_FORMAT_FLOAT, /* { HPI_FORMAT_PCM32_FLOAT 14 */ - SNDRV_PCM_FORMAT_S24 /* { HPI_FORMAT_PCM24_SIGNED 15 */ + SNDRV_PCM_FORMAT_U8, /* HPI_FORMAT_PCM8_UNSIGNED 1 */ + SNDRV_PCM_FORMAT_S16, /* HPI_FORMAT_PCM16_SIGNED 2 */ + -1, /* HPI_FORMAT_MPEG_L1 3 */ + SNDRV_PCM_FORMAT_MPEG, /* HPI_FORMAT_MPEG_L2 4 */ + SNDRV_PCM_FORMAT_MPEG, /* HPI_FORMAT_MPEG_L3 5 */ + -1, /* HPI_FORMAT_DOLBY_AC2 6 */ + -1, /* HPI_FORMAT_DOLBY_AC3 7 */ + SNDRV_PCM_FORMAT_S16_BE,/* HPI_FORMAT_PCM16_BIGENDIAN 8 */ + -1, /* HPI_FORMAT_AA_TAGIT1_HITS 9 */ + -1, /* HPI_FORMAT_AA_TAGIT1_INSERTS 10 */ + SNDRV_PCM_FORMAT_S32, /* HPI_FORMAT_PCM32_SIGNED 11 */ + -1, /* HPI_FORMAT_RAW_BITSTREAM 12 */ + -1, /* HPI_FORMAT_AA_TAGIT1_HITS_EX1 13 */ + SNDRV_PCM_FORMAT_FLOAT, /* HPI_FORMAT_PCM32_FLOAT 14 */ +#if 1 + /* ALSA can't handle 3 byte sample size together with power-of-2 + * constraint on buffer_bytes, so disable this format + */ + -1 +#else + /* SNDRV_PCM_FORMAT_S24_3LE */ /* { HPI_FORMAT_PCM24_SIGNED 15 */ +#endif }; @@ -978,7 +985,7 @@ static int snd_card_asihpi_playback_open(struct snd_pcm_substream *substream) runtime->hw = snd_card_asihpi_playback; /* Strictly only necessary for HPI6205 adapters */ err = snd_pcm_hw_constraint_pow2(runtime, 0, - SNDRV_PCM_HW_PARAM_BUFFER_SIZE); + SNDRV_PCM_HW_PARAM_BUFFER_BYTES); if (err < 0) return err; @@ -1195,7 +1202,7 @@ static int snd_card_asihpi_capture_open(struct snd_pcm_substream *substream) /* Strictly only necessary for HPI6205 adapters */ err = snd_pcm_hw_constraint_pow2(runtime, 0, - SNDRV_PCM_HW_PARAM_BUFFER_SIZE); + SNDRV_PCM_HW_PARAM_BUFFER_BYTES); if (err < 0) return err; @@ -2025,6 +2032,7 @@ static int snd_asihpi_meter_get(struct snd_kcontrol *kcontrol, short anGain0_01dB[HPI_MAX_CHANNELS], i; u16 err; + //err = HPI_MeterGetRms(phSubSys, hControl, anGain0_01dB); err = HPI_MeterGetPeak(phSubSys, hControl, anGain0_01dB); for (i = 0; i < HPI_MAX_CHANNELS; i++) { -- 1.5.4.3

3 2

[alsa-devel] [PATCH][asihpi] Meter control return peak.
by Eliot Blennerhassett 19 Jun '08

19 Jun '08

Use Peak meter instead of Rms meter because it is supported by all card families. Minor checkpatch cleanups. Signed-off-by: Eliot Blennerhassett <linux(a)audioscience.com> --- diff --git a/pci/asihpi/asihpi.c b/pci/asihpi/asihpi.c index 8cbefab..ab90b08 100644 --- a/pci/asihpi/asihpi.c +++ b/pci/asihpi/asihpi.c @@ -383,15 +383,15 @@ static void snd_card_asihpi_pcm_samplerates(struct snd_card_asihpi *asihpi, rate_max = 100000; } else { /* on cards without SRC, - valid rates are determined by sampleclock */ + valid rates are determined by sampleclock */ err = HPI_MixerGetControl(phSubSys, asihpi->hMixer, HPI_SOURCENODE_CLOCK_SOURCE, 0, 0, 0, HPI_CONTROL_SAMPLECLOCK, &hControl); for (idx = 0; idx < 100; idx++) { if (HPI_ControlQuery(phSubSys, hControl, - HPI_SAMPLECLOCK_SAMPLERATE, idx, 0, - &sampleRate)) + HPI_SAMPLECLOCK_SAMPLERATE, + idx, 0, &sampleRate)) break; rate_min = min(rate_min, sampleRate); @@ -443,7 +443,7 @@ static void snd_card_asihpi_pcm_samplerates(struct snd_card_asihpi *asihpi, } } - /*printk(KERN_INFO "Supported rates %X %d %d\n", + /* printk(KERN_INFO "Supported rates %X %d %d\n", rates, rate_min, rate_max); */ pcmhw->rates = rates; pcmhw->rate_min = rate_min; @@ -885,7 +885,7 @@ static void snd_card_asihpi_playback_format(struct snd_card_asihpi *asihpi, u32 hStream, struct snd_pcm_hardware *pcmhw) { - struct hpi_format hpi_format; + struct hpi_format hpi_format; u16 wFormat; u16 err; u32 hControl; @@ -1126,10 +1126,10 @@ static void snd_card_asihpi_capture_format(struct snd_card_asihpi *asihpi, for (wFormat = HPI_FORMAT_PCM8_UNSIGNED; wFormat <= HPI_FORMAT_PCM24_SIGNED; wFormat++) { - HPI_FormatCreate( - &hpi_format, 2, wFormat, dwSampleRate, 128000, 0); - - err = HPI_InStreamQueryFormat(phSubSys, hStream, + HPI_FormatCreate(&hpi_format, 2, wFormat, dwSampleRate, + 128000, 0); + err = + HPI_InStreamQueryFormat(phSubSys, hStream, &hpi_format); if (!err) pcmhw->formats |= @@ -2025,7 +2025,7 @@ static int snd_asihpi_meter_get(struct snd_kcontrol *kcontrol, short anGain0_01dB[HPI_MAX_CHANNELS], i; u16 err; - err = HPI_MeterGetRms(phSubSys, hControl, anGain0_01dB); + err = HPI_MeterGetPeak(phSubSys, hControl, anGain0_01dB); for (i = 0; i < HPI_MAX_CHANNELS; i++) { #if ASIHPI_LINEAR_METERS @@ -2796,7 +2796,7 @@ int __devinit snd_asihpi_probe(struct pci_dev *pci_dev, asihpi->support_mmap = (!err); asihpi->support_mrx = (((asihpi->wType & 0xFF00) == 0x8900) || - ((asihpi->wType & 0xF000) == 0x6000)); + ((asihpi->wType & 0xF000) == 0x6000)); printk(KERN_INFO "Supports mmap:%d grouping:%d\n", -- -- Eliot Blennerhassett www.audioscience.com

2 1

[alsa-devel] question on hda_codec.c behavior
by randall 18 Jun '08

18 Jun '08

I've not yet been able to get the Nvidia MCP61 (RealTek ALC662) onboard sound working (EliteGroup Computer Systems) on the Athlon 64 3200+ motherboard. A hwinfo is enclosed: 21: PCI 05.0: 0403 Audio device [Created at pci.301] UDI: /org/freedesktop/Hal/devices/pci_10de_3f0 Unique ID: CvwD.9hpqWdunz16 SysFS ID: /devices/pci0000:00/0000:00:05.0 SysFS BusID: 0000:00:05.0 Hardware Class: sound Model: "Elitegroup MCP61 High Definition Audio" Vendor: pci 0x10de "nVidia Corporation" Device: pci 0x03f0 "MCP61 High Definition Audio" SubVendor: pci 0x1019 "Elitegroup Computer Systems" SubDevice: pci 0x2151 Revision: 0xa2 Driver: "HDA Intel" Driver Modules: "snd_hda_intel" Memory Range: 0xfe028000-0xfe02bfff (rw,non-prefetchable) IRQ: 22 (409 events) Module Alias: "pci:v000010DEd000003F0sv00001019sd00002151bc04sc03i00" Driver Info #0: Driver Status: snd_hda_intel is active Driver Activation Cmd: "modprobe snd_hda_intel" Config Status: cfg=no, avail=yes, need=no, active=unknown and the pastebin is http://pastebin.ca/1048637 for all the information on the sound setup. YaST2 does the typical sound card editing, and you can hear the speakers click when the card is (de)activated. But no sound is available, even using the speaker-test command or running alsaconf. I've gradually worked my way up from v1.0.14 to the current v1.0.17rl1 but have no success yet in getting the sound modules to work for the Nvidia MCP61 setup. After posting in the install newsgroup one of the persons trying to help me out suggested that I send a note to the developer's group for the following reason, the /var/log/message file contains the following upon booting up > hda_codec: Unknown model for ALC662, trying auto-probe from BIOS... > ALSA sound/pci/hda/hda_codec.c:2333: autoconfig: line_outs=1 > (0x14/0x0/0x0/0x0/0x0) > ALSA sound/pci/hda/hda_codec.c:2337: speaker_outs=0 (0x0/0x0/0x0/0x0/0x0) > ALSA sound/pci/hda/hda_codec.c:2341: hp_outs=1 (0x1b/0x0/0x0/0x0/0x0) > ALSA sound/pci/hda/hda_codec.c:2349: inputs: mic=0x18, fmic=0x19, > line=0x1a, fline=0x0, cd=0x0, aux=0x0 > hda_codec: num_steps = 0 for NID=0xc And the thought was that "Unknown model" should not be occurring. The /etc/modprobe.d/sound file has one of the allowed models for this codec. Any ideas? Does hda_codec.c need a patch? Randall

1 0

Re: [alsa-devel] Listing raw midi devices "The Right Way"?
by Clemens Ladisch 18 Jun '08

18 Jun '08

Jacob Ole Juul Kolding wrote: > I already found a code example that reads raw midi packages form a > specified device but I need to have a complete list of ALL raw midi > capable devices and ports on the system. > > What is the "Right Way" for an app to build such a list? See the source code of amidi. You probably should be using the sequencer instead of the raw MIDI interface, in which case look at the source code of arecordmidi. HTH Clemens

2 2

[alsa-devel] Listing raw midi devices "The Right Way"?
by Jacob Ole Juul Kolding 18 Jun '08

18 Jun '08

Hello all I'm working on an app that used to run on Linux but then moved to OS X and gained MIDI capabilities. Now it's moving back to Linux so I need to be able to read midi events from devices. I already found a code example that reads raw midi packages form a specified device but I need to have a complete list of ALL raw midi capable devices and ports on the system. What is the "Right Way" for an app to build such a list? Sincerely Jacob Kolding Juvul Tech

1 0

[alsa-devel] [PATCH] ASoC: fix PM=n build
by Mark Brown 17 Jun '08

17 Jun '08

From: Randy Dunlap <randy.dunlap(a)oracle.com> Fix sound/soc build failure when CONFIG_PM=n: linux-next-20080617/sound/soc/soc-core.c:829: error: 'soc_resume_deferred' undeclared (first use in this function) soc3.out:make[3]: *** [sound/soc/soc-core.o] Error 1 Signed-off-by: Randy Dunlap <randy.dunlap(a)oracle.com> Signed-off-by: Mark Brown <broonie(a)opensource.wolfsonmicro.com> --- sound/soc/soc-core.c | 2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/sound/soc/soc-core.c b/sound/soc/soc-core.c index b931039..bdbbc6a 100644 --- a/sound/soc/soc-core.c +++ b/sound/soc/soc-core.c @@ -825,8 +825,10 @@ static int soc_probe(struct platform_device *pdev) /* DAPM stream work */ INIT_DELAYED_WORK(&socdev->delayed_work, close_delayed_work); +#ifdef CONFIG_PM /* deferred resume work */ INIT_WORK(&socdev->deferred_resume_work, soc_resume_deferred); +#endif return 0; -- 1.5.2.5

1 0

[alsa-devel] hda-intel on Asus M2N-X Plus NVIDIA GeForce 6100/nForce 430 mobo
by Nigel Henry 17 Jun '08

17 Jun '08

I've just built a new machine, and expected problems with the onboard soundcard, and also have problems with the onboard NIC, but that's another problem, which is resolved by installing my last remaining realtek 8139 PCI card. Anyway the mobo is an Asus M2N-X Plus NVIDIA GeForce 6100/nForce 430, and the Southbridge (which appears to handle allsorts of stuff) is MCP61. the specs for the soundcard from the Asus site are below. ALC662 6-Channel High Definition Audio Azalia CODEC Support Jack-Sensing, Enumeration, Multi-streaming S/PDIF out on back I/O port This is using the Fedora 8 distro, which has alsa driver 1.0.15, and is probably a bit old. The card is not detected at bootup, but I did a modprobe snd-hda-intel, using various model options. the modules were loaded, but a cat /proc/asound/cards showed "no soundcards detected" I don't want to waste too much time on this onboard card, and will probably buy a cheap well supported card, just to get some sounds on this new machine. All the same I've run the alsa-info.sh script, and the link is below. http://pastebin.ca/1048647 Any comments, as always welcome. Btw: My other machines use Audigy2 soundblaster (emu10k1) on the first machine, and Ensoniq (ens1371) on the other machine, and no problems with these cards at all. I cannot repeat my opinions/thoughts about hda-intel cards. Thanks for all your work you folks. Nigel.

2 4

[alsa-devel] Thoughts on ASOC v2 driver architecture
by Jon Smirl 17 Jun '08

17 Jun '08

I'm trying to sort out an architecture that will let all of the code used in my ASOC drivers to be automatically loaded by the kernel. So if I'm confused and have some of this wrong please explain where I've gone astray. First, what are the physical hardware devices present? From the device tree it says I have two i2s controllers each with an i2c controlled codec. It also says I have a system wide DMA controller. And finally there is the "fabric" which represent the specific pcb (populated jacks, etc) used by the system (the root of the device tree). Upon booting the kernel it will find the five open firmware devices (two i2s, two codecs, one DMA) and load the appropriate of drivers for them. Note that this is the system wide DMA driver, not the ASOC one. Three drivers will be loaded and five devices will be created. The codec devices will each register one codec and multiple codec DAIs. Each i2c channel will register a platform_dai. The next part, the platform device, is where I'm having trouble. Why is the DMA subsystem in it's own ASOC device? I already have a separate system wide device for my DMA hardware. Looking at the implementations of a couple of the ASOC DMA drivers, there is nothing global about the driver, everything is done with per channel instances. Should the DMA code instead simply be a library that is linked to by the i2s drivers? And then move the entry points registered by the DMA driver up into the platform_dai? It seems to me like implementation of the DMA code should be a private matter for the platform_dai/i2s driver. Note that I'm not saying that there shouldn't be modularized ASOC DMA code, instead, why should ASOC be aware of this shared code? To see if this model would work I tried to visualize a system where one i2s controller is using DMA and the second is doing programmed IO. So if the DMA API is pushed into the platform_dai that would free up the platform device. It could then be used to support the fabric code (fabric is the motherboard specific bits of code). It should probably be renamed to the machine device instead of platform device. To handle the case of HDA not needing a fabric driver, ASOC would have a default internal machine driver that a fabric driver could override. This also implies that the fabric driver can't be the last driver registered with ASOC. There would be one global fabric driver, but it would get called on a per instance basis. You could implement (made up scenarios) two amps on the motherboard and only enough power to turn one of them on. Or maybe a front panel switch that switches which channel the front panel controls act on. I'd end up with this object model generic machine (optional machine specific fabric override) platform i2s (platform_dai, soc_snd_card) generic codec (choice of codec dai) platform i2s (platform_dai, soc_snd_card) generic codec (choice of codec dai) The platform specific i2s drivers are linked to a shared library of platform DMA code. -- Jon Smirl jonsmirl(a)gmail.com

4 22

[alsa-devel] git-http interface to ALSA git repositories?
by Timur Tabi 17 Jun '08

17 Jun '08

My company's firewall blocks the git protocol, so I need to use http:// to clone git repositories. What is the http path for the ALSA git repository? -- Timur Tabi Linux kernel developer at Freescale

3 2