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

Re: [alsa-devel] Noise on snd-hda-intel
by Raymond Yau 04 Jul '11

04 Jul '11

2011/6/24 Sune Mølgaard <sune(a)molgaard.org>: Refer to patch eb541337b7a43822fce7d0c9d967ee149b2d9a96 "ALSA: hda - Make converter setups sticky" The patch create an array of 8 elements for converter caches but there are more than 8 converters in ad1988/ad1989 5 analog Audio Output + 3 analog Audio Input + Digital Audio Output + DIgital Input + snd_array_init(&codec->cvt_setups, sizeof(struct hda_cvt_setup), 8); >> >> Is this a clean install of 11.4 or upgrade from previous version of >> ubuntu which use "default:2" and create "Digital Capture Volume" ? > > It is an upgrade. !!Modprobe options (Sound related) !!-------------------------------- snd-usb-audio: index=-2 snd_hda_intel: model=6stack enable=1 index=0 Seem those snd-usb-audio are loaded before snd-hda-intel and that's why your onboard become card 2 instead of card 0 > >> since pulseaudio use "front:2" for playback and capture and this won't >> create "digital capture volume" control > > How to remedy? Are you upgarded from version which use dmix/dsnoop ? or the "Digital Capture Volume" control is created when remove alsa-pulse-plugin There are three capture subdevices since ad1988/ad1989 have 3 [Audio Input] when application using dsnoop which use subdevice 0 by default However for PA server release the capture device after probe so it is possible that other application (e.g. arecord ) can open subdevice 0 PA server will open the next available subdevice https://qa.mandriva.com/show_bug.cgi?id=52175 card 2: Intel [HDA Intel], device 0: AD198x Analog [AD198x Analog] Subdevices: 3/3 Subdevice #0: subdevice #0 Subdevice #1: subdevice #1 Subdevice #2: subdevice #2 Simple mixer control 'Capture',0 Capabilities: cvolume cswitch penum Capture channels: Front Left - Front Right Limits: Capture 0 - 54 Front Left: Capture 48 [89%] [13.50dB] [on] Front Right: Capture 48 [89%] [13.50dB] [on] Simple mixer control 'Capture',1 Capabilities: cvolume cswitch penum Capture channels: Front Left - Front Right Limits: Capture 0 - 54 Front Left: Capture 0 [0%] [-58.50dB] [off] Front Right: Capture 0 [0%] [-58.50dB] [off] Simple mixer control 'Capture',2 Capabilities: cvolume cswitch penum Capture channels: Front Left - Front Right Limits: Capture 0 - 54 Front Left: Capture 0 [0%] [-58.50dB] [off] Front Right: Capture 0 [0%] [-58.50dB] [off]

2 1

[alsa-devel] [PATCH] ASoC: core - Make platform probe more like codec probe.
by Liam Girdwood 02 Jul '11

02 Jul '11

In preparation for ASoC dynamic PCM support (AKA ASoC DSP) Platform will also support DAPM so separate out the probe function to simplify the code (just like the codec probe). Signed-off-by: Liam Girdwood <lrg(a)ti.com> --- sound/soc/soc-core.c | 51 +++++++++++++++++++++++++++++++++++-------------- 1 files changed, 36 insertions(+), 15 deletions(-) diff --git a/sound/soc/soc-core.c b/sound/soc/soc-core.c index 32bc503..d49f0ed 100644 --- a/sound/soc/soc-core.c +++ b/sound/soc/soc-core.c @@ -986,6 +986,39 @@ err_probe: return ret; } +static int soc_probe_platform(struct snd_soc_card *card, + struct snd_soc_platform *platform) +{ + int ret = 0; + const struct snd_soc_platform_driver *driver = platform->driver; + + platform->card = card; + + if (!try_module_get(platform->dev->driver->owner)) + return -ENODEV; + + if (driver->probe) { + ret = driver->probe(platform); + if (ret < 0) { + dev_err(platform->dev, + "asoc: failed to probe platform %s: %d\n", + platform->name, ret); + goto err_probe; + } + } + + /* mark platform as probed and add to card platform list */ + platform->probed = 1; + list_add(&platform->card_list, &card->platform_dev_list); + + return 0; + +err_probe: + module_put(platform->dev->driver->owner); + + return ret; +} + static void rtd_release(struct device *dev) {} static int soc_post_component_init(struct snd_soc_card *card, @@ -1109,21 +1142,9 @@ static int soc_probe_dai_link(struct snd_soc_card *card, int num, int order) /* probe the platform */ if (!platform->probed && platform->driver->probe_order == order) { - if (!try_module_get(platform->dev->driver->owner)) - return -ENODEV; - - if (platform->driver->probe) { - ret = platform->driver->probe(platform); - if (ret < 0) { - printk(KERN_ERR "asoc: failed to probe platform %s\n", - platform->name); - module_put(platform->dev->driver->owner); - return ret; - } - } - /* mark platform as probed and add to card platform list */ - platform->probed = 1; - list_add(&platform->card_list, &card->platform_dev_list); + ret = soc_probe_platform(card, platform); + if (ret < 0) + return ret; } /* probe the CODEC DAI */ -- 1.7.4.1

2 1

[alsa-devel] Roland UM-ONE support
by xl600＠teamspode.org 02 Jul '11

02 Jul '11

I am in need of adding UM-ONE support. I believe this interface is simply a repackaged UM-1G, but ALSA 1.0.17 simply won't recognize it. Being new to this level of development, any clues as to how to add this interface support would be welcome. I'd first like to start off by assuming it will work as a UM-1G. If it doesn't, then I'll have to dig deeper. Thanks, Robert

3 3

Re: [alsa-devel] Bug#631963: linux-image-3.0.0-rc4-686-pae: no sound out the rear plugs
by Ben Hutchings 01 Jul '11

01 Jul '11

On Fri, Jul 01, 2011 at 11:06:56PM +0200, Toni Mueller wrote: > > Hi Takashi, > > On Thu, 30.06.2011 at 07:59:19 +0200, Takashi Iwai <tiwai(a)suse.de> wrote: > > I guess this must be the new feature, "Auto-Mute Mode". > > it turns out that you're right - I just had the opportunity to verify > that. Can we consider this closed, then? Or should that feature be disabled by default? Ben. -- Ben Hutchings We get into the habit of living before acquiring the habit of thinking. - Albert Camus

1 0

[alsa-devel] PCM DMA only can fire ISR when it receives 4 samples more than the period, from McBSP port?
by Philip Chu 01 Jul '11

01 Jul '11

HI, I got a problem with my audio capture using McBSP 3 port on OMAP 3530. Linux kernel 2.6.32. For the very first audio data capture, when I expect to receive only one exact period of data through McBSP, PCM DMA ISR never comes. When I check the DMA pointer by using snd_pcm_update_hw_ptr_pos(), I found it was just trash value. If I ask the data sender to send 4 samples more than the period defined, DMA ISR gets fired, the it points to the exact period position, and I assume the extra 4 bytes just get lost? My McBSP is configured as a slave which needs the sender to provide Frame Sync, clocks etc, and those signals are designed to just kick in at the same time. Do the clock signal need to be present earlier than the Frame Sync? Anybody knows what the issue could be? Thanks in advance. Philip Chu

3 5

Re: [alsa-devel] [PATCH 2/5] ASoC: atmel-ssc: add phybase in device structure
by Mark Brown 01 Jul '11

01 Jul '11

On Wed, Jun 29, 2011 at 08:00:16PM +0200, Nicolas Ferre wrote: > struct ssc_device { > struct list_head list; > + resource_size_t phybase; The type here looks rather wrong?

2 1

[alsa-devel] alsa-lib rate plugins - float samples
by Pavel Hofman 01 Jul '11

01 Jul '11

Hi, This is probably a question for Jaroslav Kysela. The better-quality rate plugins offer float resolution, but currently we are deliberately loosing information by down-converting to s16 in plugin_rate API (convert_s16). In rate_samplerate.c, the samples are up-converted to float before calling the libsamplerate API. Speex offers float API too, while we are using the int16 one. There are two ways to handle this: A. Implementing the generic "convert" API function for these plugins, handling the sample - float conversion in each plugin individually. B. Extending the pcm_rate API (pcm_rate.h) with a new optional function convert_float. Since the conversion from general sample format to float is not trivial (using the plugin_ops.h operations), I would be inclined to suggest the extension (well I have it hacked already :-) ). On the other hand, the conversion routine can be located in some common code shared by all the plugins involved and we could keep the existing API, using the generic convert function. Thanks a lot for suggestions. Best regards, Pavel.

2 5

Re: [alsa-devel] [PATCH 1/5] ASoC: wm8731: rework power management
by Mark Brown 01 Jul '11

01 Jul '11

On Wed, Jun 29, 2011 at 08:00:15PM +0200, Nicolas Ferre wrote: Don't mix multiple changes into a single patch! There's no perceptible code overlap between these so I don't understand why you've merged them, it just makes review harder and the changelog less descriptive. > - preserve crystal oscillator across suspend/resume sequence: > enabled by default, it should be kept enabled on resume. This isn't what your code does... > - if codec is in active state: set the active bit at resume time. Your changelog doesn't explain what the actual problem is here... I can see it by studying the diff but the changelog makes me think the change is bad as the subsystem shuts everything down before it enters CODEC suspend... > snd_soc_write(codec, WM8731_ACTIVE, 0x0); > - snd_soc_write(codec, WM8731_PWR, 0xffff); > + /* standby: keep crystal oscillator enabled */ > + snd_soc_write(codec, WM8731_PWR, 0x00df); This doesn't keep the crystal oscillator enabled, this forces it on in suspend (and without looking at the datasheet it also changes way more than the one register bit I'd expect to be changed). If the system isn't using the oscillator then that's not good. I'd expect to see a change to using snd_soc_update_bits() based on your description, or more likely something more involved. > @@ -533,6 +534,8 @@ static int wm8731_suspend(struct snd_soc_codec *codec, pm_message_t state) > static int wm8731_resume(struct snd_soc_codec *codec) > { > wm8731_set_bias_level(codec, SND_SOC_BIAS_STANDBY); > + if (codec->active) > + snd_soc_write(codec, WM8731_ACTIVE, 0x0001); This should be handled as part of the bias level managemnent and cache sync, if the disable happens in bias level management so should the restore.

2 4