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

[alsa-devel] ALSA Support for Maya44 PCI?
by Nicolas Rodriguez 09 Oct '07

09 Oct '07

I bought a Maya44 PCI 4-channel soundcard and I'll like to use it in Linux. I couldn't get it to work with Ubuntu (I don't remember the ALSA version, sorry). Do you support this card? If you don't, I can create the driver for it. I've read somewhere that ESI-PRO can give the card specifications to developers interested in build drivers for their cards. I've sent them an email asking for the card specifications for I've got no response. What do you recommend? Thanks in advance, Nico.

1 0

[alsa-devel] Envy24control s/pdif input bugfix
by Stephan Zaubzer 09 Oct '07

09 Oct '07

Hi! This patch against the stable version of envy24control fixes a bug where the S/Pdif input switch doesn't work on Terratec DMX 6fire cards. This bug first appeared in version 1.0.11rc3. diff -ubr alsa-tools-1.0.14patch/envy24control/hardware.c alsa-tools-1.0.14/envy24control/hardware.c --- alsa-tools-1.0.14patch/envy24control/hardware.c 2007-09-23 15:58:53.000000000 +0200 +++ alsa-tools-1.0.14/envy24control/hardware.c 2007-06-04 13:27:25.000000000 +0200 @@ -775,7 +775,7 @@ snd_ctl_elem_value_set_interface(volume_rate, SND_CTL_ELEM_IFACE_MIXER); snd_ctl_elem_value_set_name(volume_rate, "Multi Track Volume Rate"); - if (card_is_dmx6fire) { + if (! card_is_dmx6fire) { snd_ctl_elem_value_set_interface(spdif_input, SND_CTL_ELEM_IFACE_MIXER); snd_ctl_elem_value_set_name(spdif_input, "Optical Digital Input Switch"); } else { Regards Stephan

3 4

Re: [alsa-devel] [Alsa-user] Asus M2NPV-VM snd_hda_intel problem - also with Alsa 1.0.15rc3
by Ma Begaj 09 Oct '07

09 Oct '07

> Firstly, I don't have the same board. Similar, but different. > > I have an Asus A8N-VM CSM board, but it has the same AD1986A chip on it. > I didn't have the same issue with sound muting, but I did have issues > with surround (it just didn't work). I don't remember the details of how > > > --- patch_analog.c.backup 2007-04-14 11:01:17.209146249 +0100 > +++ patch_analog.c 2007-04-14 13:37:47.005206476 +0100 > @@ -895,14 +895,14 @@ > case AD1986A_3STACK: > spec->num_mixers = 2; > spec->mixers[1] = ad1986a_3st_mixers; > - spec->num_init_verbs = 3; > +/* spec->num_init_verbs = 3; > spec->init_verbs[1] = ad1986a_3st_init_verbs; > - spec->init_verbs[2] = ad1986a_ch2_init; > + spec->init_verbs[2] = ad1986a_ch2_init; */ > spec->channel_mode = ad1986a_modes; > spec->num_channel_mode = ARRAY_SIZE(ad1986a_modes); > spec->need_dac_fix = 1; > - spec->multiout.max_channels = 2; > - spec->multiout.num_dacs = 1; > + spec->multiout.max_channels = 6; > + spec->multiout.num_dacs = 3; > break; > case AD1986A_LAPTOP: > spec->mixers[0] = ad1986a_laptop_mixers; > thanks for your try. it helped partly ... I tried 3 patches (incl. yours) and only yours helped partly at least. I patched Alsa 1.0.15rc3. Sound mutes as soon as I change volume, and I can only rmmod/modprobe snd-hda-intel to get it back. But Surround is working with your patch as I can see: "speaker-test -Dplug:surround51 -c6 -t waw" recognizes correctly all speakears. "speaker-test -c6 -t waw" does not recognize the speakers correctly, but it probably should not, or ?! MythTv is playing stereo files only on the right speakers. I do not now is this a MythTv or Alsa problem. probably MythTv and I should create a .asoundrc which should correct this somehow. I did not try hg, because I thought that Alsa 1.0.15rc3 is very new. Thanks. M.

1 1

[alsa-devel] Capturing of Samsung Q1 Ultra (ALC262) does not work
by Pengcheng Zou 09 Oct '07

09 Oct '07

Hi, capture function of the Samsung Q1 Ultra (using ALC262 codec) does not work. I tried the most recent ALSA build (alsa-driver-1.0.15rc3), the playback works well, however the recording does not work. Samsung Q1 (using AD1986A codec) has been supported already, wonder if there is any patches for Q1 Ultra? please note Samsung released 2 types of UPMC, Q1 and Q1 Ultra. the Q1 ultra is the one I have: http://computers.pricegrabber.com/tablet-pcs/m/37616779/details/ TIA, -- Pengcheng

3 2

[alsa-devel] snd_pcm_drain and lock-ups
by Mike Gorse 08 Oct '07

08 Oct '07

Hi all, I've followed Arve Knudsen over here. I am getting a lock-up when calling snd_pcm_drain(). This happens when using espeak, which is using portaudio. Portaudio calls snd_pcm_drain while trying to recover from a XRUN. snd_pcm_drain is calling snd_pcm_rate_drain in my case. snd_pcm_rate_drain then calls snd_pcm_wait. snd_pcm_wait first checks if snd_pcm_mmap_avail(pcm) >= pcm->avail_min. snd_pcm_map_avail is returning a number less than 300, often between 135 and 140 but not always, where pcm->avail_min == 1024. So it does not check for the XRUN state since it is conditional on snd_pcm_mmap_avail returning >= 1024. This is on my laptop, which is running Linux 2.6.22 and alsa-lib 1.0.15-rc1 and uses the snd-intel8x0 driver. Does this give people enough information to tell what might be going on? I have a small test program that causes the lock-up on my laptop where the rate plugin gets used (it sometimes locks up immediately, sometimes after a few seconds), but it needs espeak and portaudio to be installed. Thanks, -- Mike Gorse / AIM:linvortex / http://mgorse.freeshell.org --

2 6

Re: [alsa-devel] [Alsa-user] How to get set/fixed sample rate of ALSA device?
by Rene Herman 08 Oct '07

08 Oct '07

On 10/08/2007 12:41 AM, Mark Constable wrote: > Any chance that your program could take an arg to investigate > other cards (or perhaps plugins) and also return an errno so > it could be used in scripts ? Only if you promise to never drop CCs again (although I don't know about plugins). > # gcc -W -Wall -o snd_rate snd_rate.c -l asound > snd_rate.c: In function 'main': > snd_rate.c:14: warning: the address of ‘params’ will always evaluate as 'true' That's the ALSA snd_pcm_hw_params_alloca(). No such warning here, but I've made it a regular malloc. > # snd_rate > snd_pcm_open: Device or resource busy > > In fact, why isn't there a single simple "alsainfo" type > program that tells a user some (or a lot) of info about > their hardware and alsa-lib install ? I guess because noone wrote one :-) It seems by the way that dir != 0 _can_ be returned for hw devices, and this just ignores it. Just some rounding issue I guess. Rene. /* gcc -W -Wall -o alsa-rate alsa-rate.c -lasound */ #include <stdio.h> #include <alsa/asoundlib.h> int main(int argc, char *argv[]) { char *device; snd_pcm_t *handle; snd_pcm_hw_params_t *params; unsigned int min; unsigned int max; int dir; int err; device = argc > 1 ? argv[1] : "hw:0,0"; err = snd_pcm_open(&handle, device, SND_PCM_STREAM_PLAYBACK, 0); if (err < 0) { fprintf(stderr, "snd_pcm_open: %s\n", snd_strerror(err)); return err; } err = snd_pcm_hw_params_malloc(&params); if (err < 0) { fprintf(stderr, "snd_pcm_hw_params_alloc: %s\n", snd_strerror(err)); return err; } err = snd_pcm_hw_params_any(handle, params); if (err < 0) { fprintf(stderr, "snd_pcm_hw_params_any: %s\n", snd_strerror(err)); return err; } err = snd_pcm_close(handle); if (err < 0) { fprintf(stderr, "snd_pcm_close: %s\n", snd_strerror(err)); return err; } err = snd_pcm_hw_params_get_rate_min(params, &min, &dir); if (err < 0) { fprintf(stderr, "snd_pcm_hw_params_get_rate_min: %s\n", snd_strerror(err)); return err; } err = snd_pcm_hw_params_get_rate_max(params, &max, &dir); if (err < 0) { fprintf(stderr, "snd_pcm_hw_params_get_rate_max: %s\n", snd_strerror(err)); return err; } snd_pcm_hw_params_free(params); printf("%u-%u\n", min, max); return 0; }

1 0

[alsa-devel] Use-before-initialization in alsa-oss
by Alexander E. Patrakov 06 Oct '07

06 Oct '07

dsp->oss_format was used before it was set correctly spotted by running "aoss flite_time 10:00" Signed-Off-By: Alexander E. Patrakov --- alsa-oss-1.0.14.orig/alsa/pcm.c 2007-09-29 16:12:44.000000000 +0600 +++ alsa-oss-1.0.14/alsa/pcm.c 2007-09-29 16:13:06.000000000 +0600 @@ -215,10 +215,10 @@ unsigned int rate, periods_min; if (!pcm) continue; + dsp->format = oss_format_to_alsa(dsp->oss_format); str->frame_bytes = snd_pcm_format_physical_width(dsp->format) * dsp->channels / 8; snd_pcm_hw_params_alloca(&hw); snd_pcm_hw_params_any(pcm, hw); - dsp->format = oss_format_to_alsa(dsp->oss_format); err = snd_pcm_hw_params_set_format(pcm, hw, dsp->format); if (err < 0) -- Alexander E. Patrakov

2 1

[alsa-devel] ASoC v2 on PowerPC
by Jon Smirl 05 Oct '07

05 Oct '07

I'm looking into write a ASoC v2 driver for the Efika. Efika uses a Freescale MPC5200B and a STAC9766. This is a practice driver before writing one for our target hardware (which doesn't work yet, same CPU but different codec). I've brought the changes from wolfson/asoc-v2-dev into my powerpc tree and got a couple of config errors with ARCH=powerpc. sound/soc/pxa/Kconfig:23:warning: 'select' used by config symbol 'SND_PXA2XX_SOC_SSP' refers to undefined symbol 'PXA_SSP' sound/soc/au1x/Kconfig:35:warning: 'select' used by config symbol 'SND_SOC_EXM1200_SSI' refers to undefined symbol 'SND_SOC_CS4251X' Suggestions on the best way to start? Target hardware also has a WM8804 on it. -- Jon Smirl jonsmirl(a)gmail.com

3 5

[alsa-devel] Why was the built-in software volume control removed?
by kyle cronan 04 Oct '07

04 Oct '07

I think I may have posted this to the wrong list. There wasn't any response yet on alsa-user, so I'm reposting here. Summary: I'm seeing a lot of glitches ever since the built-in software volume was removed. What was the reason for this change? Softvol doesn't work nearly as well for me. ________________ Hi everyone, I recently updated my media center which is running Fedora devel. It pulled down a new kernel with updated ALSA drivers for my HDA audio chip (Intel 82801H + ALC883). I use IEC958 output to a pair of studio monitors (good sound with minimal fuss). The first thing I noticed about the update was that my software volume control was no longer saving state. It was resetting to something around 80% every time an app opened the audio device, a level which, in my setup, is quite loud! Then I saw that in alsamixer I had no master volume control, not even a PCM control! So I started experimented with my settings, and I found that after I selected "PCM" under "Default Mixer Tracks" in gnome-sound-properties I had a PCM volume control again (still no master), and apps using alsa output would once again remember the system volume. Don't know what that gnome setting actually did, but I've not been able to get it back to the original state, even when I ctrl-click to deselect "PCM" in the list. However, apps that use legacy OSS output still blast me with nearly full volume every time. I've also noticed another glitch: using the volume control applet to adjust my PCM volume, the audio sometimes skips. If I quickly drag the slider back and forth, it always does. I'm pretty sure I would have noticed this if it occurred with my previous kernel (haven't had a chance to test that yet). Anyway, looking into this problem, I found the following note in the changes document at http://www.alsa-project.org/main/index.php/Changes_v1.0.15rc2_v1.0.15rc3 Sound Core ... - Remove the built-in software volume control in favour of softvol. So, my (main) question is: is there a good reason that the built-in software volume was removed? I didn't find anything about it in the archives for this list or -devel. I'm really not in favor of this change, because It used to work flawlessly for me, whereas now I'm running into all these strange problems with my IEC958 output. Thanks, Kyle Cronan <kyle(a)pbx.org>

2 1

[alsa-devel] Tascam US122 on Arm
by ST 04 Oct '07

04 Oct '07

Hi I am a little irritated that there has been no replies to my questions to this list (http://mailman.alsa-project.org/pipermail/alsa-devel/2007-September/003387.…, http://mailman.alsa-project.org/pipermail/alsa-devel/2007-September/003083.…). Am i on the wrong list? Please tell me if so. Probably its also that i didn't make clear in my last post that the tascam driver works on arm with my US122 sound card, for ca. 51 seconds. After that i get the following error: Sequence Error!(hcd_frame=6 ep=8in;wait=65538,frame=2). Most propably some urb of usb-frame 65538 is still missing. Cause could be too long delays in usb-hcd interrupt handling. I also tried insmod ./2.6.18/kernel/sound/usb/usx2y/snd-usb-usx2y.ko nrpacks=X with X=[1,2,4,8]. I thought that if it is really an CPU performance problem than probably a bigger buffer would eliminate the problem. However the error persisted. Even commenting out /* #define USX2Y_NRPACKS_VARIABLE y */ and setting #define USX2Y_NRPACKS 1 didn't help. So my question is now, is the 250Mhz ARM really to slow or is there any chance that there is an error in either the usb stack or the driver exposed only on the ARM architecture? Things speaking for the latter are: *Error allways in the 65536-65540 value. *Error happens most of the times after about 50secs. Since i do not know much about USB any hint is apreciated. ST

2 2