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

[alsa-devel] no front speaker sound with ALC262
by Rene Dohmen 17 Mar '08

17 Mar '08

Dear List, I have a problem with an Intel HDA soundcard lspci output: ----- 00:1b.0 Audio device: Intel Corporation 82801G (ICH7 Family) High Definition Audio Controller (rev 01) The sound volume is very very low when i use the headphone output. The device has integrated speakers but i don't hear any sound coming out of them (maybe because the volume is so low...). I've put all the mixer channels to the maximum values. When booted in Win XP the soundcard works correctly. Is see one line in my logs that indicate that something is wrong: hda_codec: Unknown model for ALC262, trying auto-probe from BIOS... I didn't have it working with other versions of ALSA. Tested with 1.0.14(provided with ubunty gutsy), then started reading, lots of suggestions stated that the problem would be solved in 1.0.15, so i compiled 1.0.16 from src and replaced the default alsa modules with the new ones. De device i 'm using is supplied by tangent ( http://www.tangent.com/t_all_in_one_LCDPC/vita_8000s.htm) its an all in one solution with touchscreen and speakers integrated in one small cabinet. I runned the alsa-info.sh script output and uploaded it: http://pastebin.ca/913865 I don't know if this is the correct place for getting help but all help is appreciated, Best Regards, Rene Dohmen

5 14

[alsa-devel] Emvy24control s/pidf input issue
by Udo van den Heuvel 17 Mar '08

17 Mar '08

Hello, I just noticed that S/PDIF input on my Audiophile 2496 does not work. I see: [udo@wda ~]$ envy24control using --- input_channels: 0 --- output_channels: 4 --- pcm_output_channels: 8 --- spdif in/out channels: 2 Unable to read S/PDIF input switch: No such file or directory Changing the Digital Input from coax to optical or vice versa gives: Unable to write S/PDIF on/off switch: No such file or directory Unable to write S/PDIF input switch: No such file or directory This is on Fedora 8 x86_64 with alsa-tools 1.0.12-4 from Fedora Core 7, envycontrol 0.6.0. S/PDIF output works without a problem. Did not have S/PDIF input working before, as far as I remember. Using -v I do not see signal in the meters. In the source I see in spdif_input_update: if ((card_eeprom.subvendor != ICE1712_SUBDEVICE_DELTADIO2496) && ! card_is_dmx6fire) return; if ((err = snd_ctl_elem_read(ctl, spdif_input)) < 0) g_print("Unable to read S/PDIF input switch: %s\n", snd_strerror(err)); (etc) Why does snd_ctl_elem_read fail? How could I make S/PDIF input work again? Tips are very welcome! Kind regards, Udo

2 4

[alsa-devel] AD1988B: ALSA doesn't use dmix automatically
by Dâniel Fraga 17 Mar '08

17 Mar '08

ALSA 1.0.15 http://alsa.opensrc.org/index.php/Dmix NOTE: For ALSA 1.0.9rc2 and higher you don't need to setup dmix. Dmix is enabled as default for soundcards which don't support hw mixing. So why if I try to play 2 sounds at the same time, the second one complains the "resource is busy"? Shouldn't it detect that AD1988B can't do hardware mixing and use dmix automatically? Obs.: I don't have any ~/.asoundrc or /etc/asound.conf lying around. Thanks! -- Linux 2.6.24: Arr Matey! A Hairy Bilge Rat! http://u-br.net http://www.abusar.org/FELIZ_2008.html Napalm Death - "Circle Of Hypocrisy" (Harmony Corruption - 1990)

4 4

Re: [alsa-devel] ALSACTL wrong restore on ARM9
by Liam Girdwood 17 Mar '08

17 Mar '08

On Fri, 2008-03-07 at 16:28 +0100, Alexandre BOUIN wrote: > > Can you describe 'bad values' in a little more detail. > > You're right, some details are missing. > > For example, for first control, a playback volume control, value can go from > 0 to 63. > Before "store" command, I'd set it to 20. > I've check that in "/var/lib/alsa/asound/state", I had the same value. Here > is a part of this file : > > state.codec { > control.1 { > comment.access 'read write' > comment.type INTEGER > comment.count 2 > comment.range '0 - 63' > iface MIXER > name 'HP Playback Volume' > value.0 20 > value.1 20 > } > > So saved value seems ok. > > After "restore" command, I get this : > > $amixer cget numid=1 > numid=1,iface=MIXER,name='HP Playback Volume' > ; type=INTEGER,access=rw------,values=2,min=0,max=63,step=0 > : values=45,45 > > That's why I say that values are not correct. > I'm currently using debian alsa-utils_1.0.16-1_arm package. > It's possible that your codec drivers register caching is borked. This can be easily confirmed with debug in your driver kcontrol code. If your driver looks ok, then I'd suggest looking into your alsa-lib cross build. There have been some problems with it being incorrectly cross compiled for ARM in the past (pls search the list for details). Fwiw, I use OpenEmbedded to build ALSA for ARM and I've never ran into this issue. Liam

2 2

[alsa-devel] PATCH - some fixes and cleanup for ICE1724 cards
by Pavel Hofman 17 Mar '08

17 Mar '08

Hi Takashi, here is a small patch with minor fixes and cleanup. * removing the hack with NON_AKM ak4xxx type * support for card-specific flags in ak4114_stats * definition of the flags for corresponding cards Signed-by: Pavel Hofman <dustin(a)seznam.cz> Thanks, Pavel

2 1

[alsa-devel] [PATCH] [ML403-AC97CR] Remove duplicate snd_card_set_dev().
by Joachim Foerster 17 Mar '08

17 Mar '08

Hi Takashi, I noticed, that there was a change in ml403-ac97cr.c, which introduces a second call of snd_card_set_dev() in the _probe()-function. The "original" one is in the snd_ml403_ac97cr_create()-function. According the other changes, I guess, we want to have it in the _probe()-function, now (=> following patch)? From: Joachim Foerster <JOFT(a)gmx.de> We want to have snd_card_set_dev() in _probe(), but not a second one in snd_ml403_ac97cr_create(). Signed-off-by: Joachim Foerster <JOFT(a)gmx.de> --- sound/drivers/ml403-ac97cr.c | 2 -- 1 files changed, 0 insertions(+), 2 deletions(-) diff --git a/sound/drivers/ml403-ac97cr.c b/sound/drivers/ml403-ac97cr.c index 05a871a..b654007 100644 --- a/sound/drivers/ml403-ac97cr.c +++ b/sound/drivers/ml403-ac97cr.c @@ -1191,8 +1191,6 @@ snd_ml403_ac97cr_create(struct snd_card *card, struct platform_device *pfdev, return err; } - snd_card_set_dev(card, &pfdev->dev); - *rml403_ac97cr = ml403_ac97cr; return 0; } -- 1.5.4.3

2 1

[alsa-devel] Grab PCM stream into file
by Alexander Indenbaum 17 Mar '08

17 Mar '08

Hello, I'm playing with embedded system without any hardware sound device. Strategically we'd like to forward PCM stream from ALSA clients on user level to proprietary application. As initial proof of concept stage I'd like to grab sound from ALSA application, for instance Firefox displaying YouTube clip inside flash plugin and to store output PCM stream into file on local disk. Please advice how I could achieve this goal. Alexander Indenbaum

1 0

[alsa-devel] How to stop playback on alsa synth?
by Lukasz Pawelczyk 16 Mar '08

16 Mar '08

Hello. I'd like to ask how to completely stop playback using alsa synth. Basically my program initialized output in the following way: snd_seq_open() snd_seq_set_client_name() snd_seq_client_id() snd_seq_parse_address() snd_seq_create_simple_port() snd_seq_connect_to() snd_seq_alloc_named_queue() Then I create a new thread that processes events. It sets tempo and in infinite loop it does: snd_seq_ev_set_fixed() snd_seq_event_output() This all is based on aplaymidi code. How can I asynchronously immediately stop all the playback? Basicaly it requires breaking snd_seq_event_output() thats locked on my thread. I tried everything I could come up with. I know very little about alsa synth programming and basically thats the only thing i need to do now. Tried: snd_seq_ev_set_queue_stop() snd_seq_stop_queue() snd_seq_remove_events() or even closing the seq completely to reopen it on another file playback with: snd_seq_stop_queue() snd_seq_disconnect_to() snd_seq_delete_simple_port() snd_seq_close() All failed, results were very various. I simply run out of ideas. It doesn't matter if the method would require to close seq or not. I just need to stop the playback so i can gracefully stop the thread and play another file (with eventual reopening ports/seq). Would appreciate any help. -- Regards Havner {jid,mail}:havner(at)pld-linux.org "Quis custodiet ipsos custodes?"

1 1

[PATCH] Correct dapm controls length.
by Robert Jarzmik 16 Mar '08

16 Mar '08

Dapm control names should follow alsa standard, which defines controls name's length to 44 and not 32. Signed-off-by: Robert Jarzmik <rjarzmik(a)free.fr> Signed-off-by: Mark Brown <broonie(a)opensource.wolfsonmicro.com> --- sound/soc/soc-dapm.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/sound/soc/soc-dapm.c b/sound/soc/soc-dapm.c index 4b03e3f..a61024c 100644 --- a/sound/soc/soc-dapm.c +++ b/sound/soc/soc-dapm.c @@ -281,7 +281,7 @@ static int dapm_new_mixer(struct snd_soc_card *soc_card, struct snd_soc_dapm_widget *w) { int i, ret = 0; - char name[32]; + char name[44]; struct snd_soc_dapm_path *path; /* add kcontrol */ @@ -295,7 +295,7 @@ static int dapm_new_mixer(struct snd_soc_card *soc_card, continue; /* add dapm control with long name */ - snprintf(name, 32, "%s %s", w->name, w->kcontrols[i].name); + snprintf(name, 44, "%s %s", w->name, w->kcontrols[i].name); path->long_name = kstrdup (name, GFP_KERNEL); if (path->long_name == NULL) return -ENOMEM; -- 1.5.6.5

1 0

[PATCH] Dirty hack to use GPIO95 in AC97 reset.
by Robert Jarzmik 16 Mar '08

16 Mar '08

Mio Mitac A701 uses GPIO95 instead of GPIO113 as the reset line connected to the WM9713 chip. This is dirty, and should be replaced by an elegant solution where cold and warm reset are implemented in machine driver mioa701_wm9713.c Signed-off-by: Robert Jarzmik <rjarzmik(a)free.fr> --- sound/soc/pxa/pxa2xx-ac97.c | 12 ++++++------ 1 files changed, 6 insertions(+), 6 deletions(-) diff --git a/sound/soc/pxa/pxa2xx-ac97.c b/sound/soc/pxa/pxa2xx-ac97.c index cb12544..86fb9c2 100644 --- a/sound/soc/pxa/pxa2xx-ac97.c +++ b/sound/soc/pxa/pxa2xx-ac97.c @@ -145,10 +145,10 @@ static void pxa2xx_ac97_warm_reset(struct snd_ac97 *ac97) #ifdef CONFIG_PXA27x /* warm reset broken on Bulverde, so manually keep AC97 reset high */ - pxa_gpio_mode(113 | GPIO_OUT | GPIO_DFLT_HIGH); + pxa_gpio_mode(95 | GPIO_OUT | GPIO_DFLT_HIGH); udelay(10); GCR |= GCR_WARM_RST; - pxa_gpio_mode(113 | GPIO_ALT_FN_2_OUT); + pxa_gpio_mode(95 | GPIO_ALT_FN_1_OUT); udelay(500); #elif defined(CONFIG_PXA3xx) /* Can't use interrupts */ @@ -303,8 +303,8 @@ static int pxa2xx_ac97_resume(struct platform_device *dev) pxa_gpio_mode(GPIO29_SDATA_IN_AC97_MD); #endif #ifdef CONFIG_PXA27x - /* Use GPIO 113 as AC97 Reset on Bulverde */ - pxa_gpio_mode(113 | GPIO_ALT_FN_2_OUT); + /* Use GPIO 95 as AC97 Reset on Bulverde */ + pxa_gpio_mode(95 | GPIO_ALT_FN_1_OUT); #endif clk_enable(ac97_clk); return 0; @@ -457,8 +457,8 @@ static int pxa2xx_ac97_probe(struct platform_device *pdev) return -ENOMEM; #ifdef CONFIG_PXA27x - /* Use GPIO 113 as AC97 Reset on Bulverde */ - pxa_gpio_mode(113 | GPIO_ALT_FN_2_OUT); + /* Use GPIO 95 as AC97 Reset on Bulverde */ + pxa_gpio_mode(95 | GPIO_ALT_FN_1_OUT); ac97conf_clk = clk_get(&pdev->dev, "AC97CONFCLK"); if (IS_ERR(ac97conf_clk)) { -- 1.5.5.3 --=-=-= Content-Type: text/x-diff Content-Disposition: inline; filename=0002-Dirty-hack-to-workaround-pxa27x-buggy-hardreset.patch

1 0