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

[alsa-devel] Vostro 1400 patch
by Martin van Es 26 Mar '08

26 Mar '08

Hi, I recently bought a Dell Vostro 1400 and thought I'd let you know my experiences with Alsa: I use Kubuntu Gutsy distribution as a base, but follow kernel at a close pace so I use compiled 2.6.24. This didn't support the hda-intel as I expected (don't remember exactly, but master/front/pcm/surround were all in the game but not as expected and I couldn't get built-in mic to work, but this may be due to too little testing). So I decided to google around and found the model=3stack, dell-3stack options and tried those. Still no luck. Next I dl'ed alsa 1.0.16 and noticed a mail describing a vostro 1400 PCI quirck patch (model dell-bios). So I tried that, but no luck. After that I experimented with all 3stack variants I could find in the code and concluded that dell-3stack is the best. I now have sound, master/front/pcm volume sliders that work but above all: built-in mic (Digital 1) recording (and skype) works! I don't know if it's of any value: I immediately flashed the standard A06 Bios to A07 when I found the update on the Dell site and can not tell if the dell-bios model worked for the preloaded A06 version bios. Hope this helps. If there's anything else I can provide I'd be more than happy to collect the data. Regards, Martin -- if but was of any use, it would be a logic operator

1 0

Re: [alsa-devel] PXA2xx/3xx AC97 Driver(s)
by Mark Brown 26 Mar '08

26 Mar '08

On Wed, Mar 26, 2008 at 01:52:39PM +0000, Oliver Ford wrote: > The machine no longer reboots out of linux though. I assume there were > some changes in 2.6.25-rc4 mainline that aren't in the asoc-v2-dev yet. > I will wait for the pxa3xx stuff to be merged into the mainline for > this. What version of the mainline kernel is the latest asoc-v2-dev > branch based on. (I'm still a little hazy on the git stuff I'm afraid). The last version that was merged in appears to be 2.6.25-rc2 (say 'git log' then search for 'Merge.*v2\.6'). For production use I would recommend going with ASoC v1 at the moment. The PXA3xx support should be straightforward to backport (I wouldn't be suprised if the patches introducing it could just applied against mainline but I've not actually tried yet). > > I know that there are a number of users currently using the tree for > > that use case so the asoc-v2-dev branch should hopefully work for you. > > If you run into trouble please let me know. > The WM97xx touchscreen driver only appears to be in the linux-2.6-touch > repository (dev branch, iirc), rather than linux-2.6-asoc where the > pxa3xx support is. Since I want both the wm97xx touchscreen and pxa3xx > support, is there a simple way I can get the necessary changes in one > applied to the other? You can track both multiple git trees using the remotes feature of git - see git-remote(1) for usage information. For example, this: git remote add wolfson-touch \ git://opensource.wolfsonmicro.com/linux-2.6-touch will tell git to track the Wolfson touch drivers using the name 'wolfson-touch'. If you do that and then say: git remote update git merge wolfson-touch/dev it will fetch the current state of all remote trees it knows about and then merge the current dev branch of the Wolfson touch drivers git into your current working copy. The touchscreen drivers and git usage are both rather off-topic for either list, though - probably best to follow up off-list or on linux-input.

1 0

[alsa-devel] Plugin default and sw_params
by Emmanuel Milou 26 Mar '08

26 Mar '08

Hi all, I have some questions about the /default/ plugin. I am developping a softphone based on ALSA on Ubuntu 7.10. I use read/write IO. When I open a device with the /plughw /plugin, quite everything works fine, the quality sound is good. But with the /default/ plugin or the /dmix/ plugin ( the user can choose one of them ), I can't set my own hw parameters or sw parameters. Actually I set my own value of period size, buffer size, start threshold, stop threshold, but when I check in /proc/asound/cardx/pcm0p/sub0/sw_params or /proc/asound/cardx/pcm0p/sub0/hw_params, the values are totally different. For instance, the start threshold is set to 1 even if I set it to period_size. As a result, I get crackling sound. I suspect this is due to buffer underrun. Maybe if I could change the start threshold or the period size, the sound would be better. So my question: is it possible to modify this values for /default/ plugin without changing the alsa config file ( asoundrc ) ? Thank you very much Manu

1 0

[alsa-devel] snd-bt87x
by Bizon 26 Mar '08

26 Mar '08

Hello! I have WinTV TV card based on BT878A, correctly detected by driver. But there is no sound. I have just something like a single tone. How to fix it? For compare i have also Flyvideo 98 card based on BT878, detected as unknown - it works well. Here is it's lsmod : 00:0b.1 0480: 109e:0878 (rev 02) Subsystem: 1852:1852 Thanks Karol

1 0

[alsa-devel] [PATCH] hda: Add 5.1 support for second headphone jack
by Matthew Ranostay 25 Mar '08

25 Mar '08

Several 92hd7xxx and STAC9228 laptops have multiple headphone jacks, the second headphone jack should be used for the 5.1 surround sound. Add support for 'Headphone as Line Out' switch, which allows it be used in 5.1 surround sound. Signed-off-by: Matthew Ranostay <mranostay(a)embeddedalley.com> --- diff -r 547e051a88b5 pci/hda/patch_sigmatel.c --- a/pci/hda/patch_sigmatel.c Wed Mar 12 13:12:15 2008 +0100 +++ b/pci/hda/patch_sigmatel.c Tue Mar 18 10:45:08 2008 -0400 @@ -179,6 +179,7 @@ struct sigmatel_spec { /* i/o switches */ unsigned int io_switch[2]; unsigned int clfe_swap; + unsigned int hp_switch; unsigned int aloopback; struct hda_pcm pcm_rec[2]; /* PCM information */ @@ -1251,7 +1252,7 @@ static unsigned int ref92hd73xx_pin_conf static unsigned int dell_m6_pin_configs[13] = { 0x0321101f, 0x4f00000f, 0x4f0000f0, 0x90170110, - 0x03a11020, 0x03011050, 0x4f0000f0, 0x4f0000f0, + 0x03a11020, 0x0321101f, 0x4f0000f0, 0x4f0000f0, 0x4f0000f0, 0x90a60160, 0x4f0000f0, 0x4f0000f0, 0x4f0000f0, }; @@ -2029,6 +2030,33 @@ static void stac92xx_auto_set_pinctl(str AC_VERB_SET_PIN_WIDGET_CONTROL, pin_type); } +#define stac92xx_hp_switch_info snd_ctl_boolean_mono_info + +static int stac92xx_hp_switch_get(struct snd_kcontrol *kcontrol, + struct snd_ctl_elem_value *ucontrol) +{ + struct hda_codec *codec = snd_kcontrol_chip(kcontrol); + struct sigmatel_spec *spec = codec->spec; + + ucontrol->value.integer.value[0] = spec->hp_switch; + return 0; +} + +static int stac92xx_hp_switch_put(struct snd_kcontrol *kcontrol, + struct snd_ctl_elem_value *ucontrol) +{ + struct hda_codec *codec = snd_kcontrol_chip(kcontrol); + struct sigmatel_spec *spec = codec->spec; + + spec->hp_switch = ucontrol->value.integer.value[0]; + + /* check to be sure that the ports are upto date with + * switch changes */ + codec->patch_ops.unsol_event(codec, STAC_HP_EVENT << 26); + + return 1; +} + #define stac92xx_io_switch_info snd_ctl_boolean_mono_info static int stac92xx_io_switch_get(struct snd_kcontrol *kcontrol, struct snd_ctl_elem_value *ucontrol) @@ -2099,6 +2127,15 @@ static int stac92xx_clfe_switch_put(stru return 1; } + +#define STAC_CODEC_HP_SWITCH(xname) \ + { .iface = SNDRV_CTL_ELEM_IFACE_MIXER, \ + .name = xname, \ + .index = 0, \ + .info = stac92xx_hp_switch_info, \ + .get = stac92xx_hp_switch_get, \ + .put = stac92xx_hp_switch_put, \ + } #define STAC_CODEC_IO_SWITCH(xname, xpval) \ { .iface = SNDRV_CTL_ELEM_IFACE_MIXER, \ @@ -2124,6 +2161,7 @@ enum { STAC_CTL_WIDGET_VOL, STAC_CTL_WIDGET_MUTE, STAC_CTL_WIDGET_MONO_MUX, + STAC_CTL_WIDGET_HP_SWITCH, STAC_CTL_WIDGET_IO_SWITCH, STAC_CTL_WIDGET_CLFE_SWITCH }; @@ -2132,6 +2170,7 @@ static struct snd_kcontrol_new stac92xx_ HDA_CODEC_VOLUME(NULL, 0, 0, 0), HDA_CODEC_MUTE(NULL, 0, 0, 0), STAC_MONO_MUX, + STAC_CODEC_HP_SWITCH(NULL), STAC_CODEC_IO_SWITCH(NULL, 0), STAC_CODEC_CLFE_SWITCH(NULL, 0), }; @@ -2396,6 +2435,14 @@ static int stac92xx_auto_create_multi_ou } } + if (cfg->hp_outs > 1) { + err = stac92xx_add_control(spec, + STAC_CTL_WIDGET_HP_SWITCH, + "Headphone as Line Out Switch", 0); + if (err < 0) + return err; + } + if (spec->line_switch) { nid = cfg->input_pins[AUTO_PIN_LINE]; pincap = snd_hda_param_read(codec, nid, @@ -3144,6 +3191,7 @@ static void stac92xx_hp_detect(struct hd { struct sigmatel_spec *spec = codec->spec; struct auto_pin_cfg *cfg = &spec->autocfg; + int nid = cfg->hp_pins[cfg->hp_outs - 1]; int i, presence; presence = 0; @@ -3154,11 +3202,15 @@ static void stac92xx_hp_detect(struct hd for (i = 0; i < cfg->hp_outs; i++) { if (presence) break; + if (spec->hp_switch && cfg->hp_pins[i] == nid) + break; presence = get_hp_pin_presence(codec, cfg->hp_pins[i]); } if (presence) { /* disable lineouts, enable hp */ + if (spec->hp_switch) + stac92xx_reset_pinctl(codec, nid, AC_PINCTL_OUT_EN); for (i = 0; i < cfg->line_outs; i++) stac92xx_reset_pinctl(codec, cfg->line_out_pins[i], AC_PINCTL_OUT_EN); @@ -3167,6 +3219,8 @@ static void stac92xx_hp_detect(struct hd AC_PINCTL_OUT_EN); } else { /* enable lineouts, disable hp */ + if (spec->hp_switch) + stac92xx_set_pinctl(codec, nid, AC_PINCTL_OUT_EN); for (i = 0; i < cfg->line_outs; i++) stac92xx_set_pinctl(codec, cfg->line_out_pins[i], AC_PINCTL_OUT_EN); @@ -3174,6 +3228,8 @@ static void stac92xx_hp_detect(struct hd stac92xx_set_pinctl(codec, cfg->speaker_pins[i], AC_PINCTL_OUT_EN); } + if (!spec->hp_switch && cfg->hp_outs > 1 && presence) + stac92xx_set_pinctl(codec, nid, AC_PINCTL_OUT_EN); } static void stac92xx_pin_sense(struct hda_codec *codec, int idx) @@ -3427,6 +3483,7 @@ again: switch (spec->multiout.num_dacs) { case 0x3: /* 6 Channel */ + spec->multiout.hp_nid = 0x17; spec->mixer = stac92hd73xx_6ch_mixer; spec->init = stac92hd73xx_6ch_core_init; break;

2 1

Re: [alsa-devel] PATCH - ESI Juli driver
by Demian Martin 25 Mar '08

25 Mar '08

Pavel: I want to thank you for getting the Juli@ driver sorted out. Its all working right and I can play the 176.4 KHz 24 bit files now properly. Along with 96K, 88.2K 48K and 44.1K. I had to borrow an Apogee 192K mini-dac to test the system. The inexpensive DAC I got off eBay from China was never tested properly for high bit rate files and let me off track until I got a known DAC to test with. The unique clocking scheme of the Juli@ card should give lower jitter and better audio than the other solutions since the clock isn’t generated from a PLL. It’s a relative bargain compared to a Hammerfall or a Lynx card. And now with a good Linux driver very useable. -Demian Demian Martin Product Design Service 784 Cary Drive San Leandro, CA 94577 209 613 6990 No virus found in this outgoing message. Checked by AVG. Version: 7.5.519 / Virus Database: 269.21.8/1340 - Release Date: 3/23/2008 6:50 PM

1 0

[alsa-devel] Wrong offset, step and size passed from alsa-lib layers to external io type plugin
by Pharaoh . 25 Mar '08

25 Mar '08

Hi, In my external io type plugin, the alsa buffer is not accessible in the transfer function, symptom of this is I am unable to memcpy period size data from alsa buffer to my local buffers. after debugging a little I found out that values of offset, size and areas->step are wrong. #aplay --period-size =1024 --buffer-size=8192 test.wav static snd_pcm_sframes_t alsa_transfer(snd_pcm_ioplug_t *io, const snd_pcm_channel_area_t *areas, snd_pcm_uframes_t offset, snd_pcm_uframes_t size) I get following, Buffer size = 32768 bytes Period size = 4096 bytes *ALSA buffer base addr = 0x2c6e0 //wrong Offset = 0xbeb4c7dc **//wrong* *size = 1063777280 **//wrong* step = 32 What could be the reason? -Pharaoh.

1 0

[alsa-devel] ALSA Debugging
by Vinod Koul 24 Mar '08

24 Mar '08

Hello, I am new to ALSA and Linux. I was trying to understand the ALSA architecture. I have Linux Box with Intel sound card. with Suse 10.1 on it. I launched the audio player (Real player) and audio plays fine. Then, I built the kernel and installed it. I put some printk's in intel8x0.cand control.c. (could see the my code was complied) Even though I changed volume muted etc couldn't see any of my printk in dmesg. One default printk in intel8x0.c was there, so I have put my print before that line as well, but couldn't see anything. Apologies If my problem is very basic. I read on forums that best way to learn is to put printk's. Can anyone help me with where I am doing incorrectly, Am I supposed to do it this way or some other way? Thanks in advance -Vinod

2 2

[alsa-devel] ALSA driver for Native Instruments sound hardware
by Daniel Mack 23 Mar '08

23 Mar '08

Hi, some months after the last posting, we finally managed to finish a new version of the ALSA driver for Native Instruments' external USB sound cards such as "Rig Kontrol 2", "Kore Kontroller", "Audio Kontrol 1" and "Audio 8 DJ". Compared to the last release, the following things were changed: - the streaming logic was completely reworked so that multiple substreams are handled correctly - a Linux input device layer was added to support the knobs, buttons and pedals on "Rig Kontrol 2" and "AudioKontrol 1" - workqueues were entirely removed from the code - most data structures are now allocated within one big struct to avoid multiple, smaller allocations - many more cleanups according to Clemens' reply on my last posting[1] The driver was properly tested with all the mentioned hardware on both record and playback channels. The patchset should apply to the current mecurial alsa-kernel tree. Please let me know what you think. Best regards, Daniel [1] http://article.gmane.org/gmane.linux.alsa.devel/34324/ Signed-off-by: Daniel Mack <daniel(a)caiaq.org> Signed-off-by: Karsten Wiese <fzu(a)wemgehoertderstaat.de>

4 10

[alsa-devel] Buffer size/periods (Layla3G)
by Mark Hills 23 Mar '08

23 Mar '08

Hello, I am investigating problems I'm having with recording over long periods. I'm using a Layla3G and tested various ALSA versions including 1.0.14 and 1.0.16 on different machines. I've noticed that when I open the first pair of subdevices, my request for 1000ms buffer size is handled differently to other devices: $ ./test_buffers "hw:Layla3G,0,0" 1000 buffer_size=16384 period_size=128 $ ./test_buffers "hw:Layla3G,0,2" 1000 buffer_size=32768 period_size=256 $ ./test_buffers "hw:Layla3G,0,4" 1000 buffer_size=32768 period_size=256 $ ./test_buffers "hw:Layla3G,0,6" 1000 buffer_size=32768 period_size=256 If I try other buffer sizes, I can see is a limit to buffer size of 16384 samples on the ,0 subdevice, which is also affecting the chosen period size. But only on the first subdevice. Is there a reason, or is this a bug? Also, there seem to be failures at certain buffer sizes: $ ./test_buffers "hw:Layla3G,0,2" 429 buffer_size=18912 period_size=96 $ ./test_buffers "hw:Layla3G,0,2" 430 set_buffer_time_near: Invalid argument $ ./test_buffers "hw:Layla3G,0,2" 431 buffer_size=19008 period_size=96 Can anyone explain to me what's going on here, or is this also a bug? The overall problem I'm investigating is snd_pcm_readi() returning incomplete buffers after running for long periods until another snd_pcm_prepare(). It seems possible that this is related. Any help is greatly appreciated. Thanks, Mark

2 4