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

Re: [alsa-devel] ESI MAYA44 driver status
by Piotr Makowski 22 Sep '07

22 Sep '07

If anybody would like to help with ESI MAYA44 PCI please bid on getacoder - we offer up to 300$ for the driver http://www.getacoder.com/projects/esi_maya_pci_alsa_driver_59542.html Please don't start working on it without bidding and before your bid is accepted. Thank you! Regards, Piotr

1 0

[alsa-devel] [PATCH -mm] sb16: Shut up uninitialized var build warning
by Satyam Sharma 22 Sep '07

22 Sep '07

sound/isa/sb16/sb16.c: In function ‘snd_sb16_isa_probe’: sound/isa/sb16/sb16.c:559: warning: ‘err’ may be used uninitialized in this function is a bogus warning, so let's shut it up. Signed-off-by: Satyam Sharma <satyam(a)infradead.org> --- sound/isa/sb/sb16.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) --- linux-2.6.23-rc4-mm1/sound/isa/sb/sb16.c‾fix 2007-09-02 21:41:51.000000000 +0530 +++ linux-2.6.23-rc4-mm1/sound/isa/sb/sb16.c 2007-09-02 21:42:56.000000000 +0530 @@ -556,7 +556,6 @@ static int __devinit snd_sb16_isa_match( static int __devinit snd_sb16_isa_probe(struct device *pdev, unsigned int dev) { - int err; static int possible_irqs[] = {5, 9, 10, 7, -1}; static int possible_dmas8[] = {1, 3, 0, -1}; static int possible_dmas16[] = {5, 6, 7, -1}; @@ -585,6 +584,8 @@ static int __devinit snd_sb16_isa_probe( else { static int possible_ports[] = {0x220, 0x240, 0x260, 0x280}; int i; + int uninitialized_var(err); + for (i = 0; i < ARRAY_SIZE(possible_ports); i++) { port[dev] = possible_ports[i]; err = snd_sb16_isa_probe1(dev, pdev);

3 4

[alsa-devel] Tascam US122 on ARM [PATCH] and error :-(
by ST 21 Sep '07

21 Sep '07

Hi I managed to get the snd_usb_usx2y driver running on an Linksys NSLU2. The whole stuff is running under debian etch. Kernel Version is 2.6.18 with Debian patches. Below is a little patch to be able to enable the driver. Unfortunatly the driver gives the error: Sequence Error!(hcd_frame=7 ep=8in;wait=65539,frame=3). Most propably some urb of usb-frame 65539 is still missing. Cause could be too long delays in usb-hcd interrupt handling. Which is the output of the function usX2Y_error_sequence. This function is only called from usbusx2yaudio.c:328. Since all numbers lie just above 65535 (They are all between 65537 and 65540) is suspect that there is some wrap around error, especially because the values are anded with a 16 bit mask (0xffff). But unfortunatly i don't know to much about usb right now. Any hints to resolve this problem? The cpu runs with 266Mhz, so it could be that it would be really to slow, but i really suspect an wrap-around error. Any hints or ideas to solve this issue? Thanks ST --- a/sound/usb/Kconfig +++ b/sound/usb/Kconfig @@ -18,7 +18,7 @@ config SND_USB_AUDIO config SND_USB_USX2Y tristate "Tascam US-122, US-224 and US-428 USB driver" - depends on SND && USB && (X86 || PPC || ALPHA) + depends on SND && USB && (X86 || PPC || ALPHA ||ARM) select SND_HWDEP select SND_RAWMIDI select SND_PCM

1 0

[alsa-devel] When to start the capture device?
by Sheng (Sean) Liu 21 Sep '07

21 Sep '07

Hello everyone, I am using ALSA to capture sound from a micrphone. I need to know when the capture device starts. In Paul Davis' Tutorial, he mentioned two approaches. But, I have questions on each of them. When to start the device When you open the audio interface, ALSA ensures that it is not active - no data is being moved to or from its external connectors. Presumably, at some point you want this data transfer to begin. There are several options for how to make this happen. 1. The control point here the start threshold, which defines the number of frames of space/data necessary to start the device automatically. If set to some value other than zero for playback, it is necessary to prefill the playback buffer before the device will start. If set to zero, the first data written to the device (or first attempt to read from a capture stream) will start the device. My question: what does he means on " If set to zero"? Does anyone know which parameter of which API should be set to zero? 2. You can also start the device explicitly using snd_pcm_start, but this requires buffer prefilling in the case of the playback stream. If you attempt to start the stream without doing this, you will get -EPIPE as a return code, indicating that there is no data waiting to deliver to the playback hardware buffer. My question: Is there anything to be done before calling snd_pcm_start in the case of capturing stream? If there is, what are they? Thanks in advance, Sheng

4 9

[alsa-devel] [PATCH] ad1848 ac loop
by Trent Piepho 21 Sep '07

21 Sep '07

New thread for the the final version of the patches for my fixes to the ad1848 auto-calibration loop. I made a couple suggested changes. These should be ok to apply, and should be independent of the other as yet un-applied patches that have been posted by Rene and Krzysztof. I'm not an expert on this chip by any means, but from looking at the code I think there are few things that could be fixed. The reg_lock spinlock isn't acquired from the irq handler, as the handler doesn't use any of the indirect registers. I think this means that is isn't necessary to use the irq disabling versions of the spin_lock functions with reg_lock. It does look like there is a different SMP race condition wrt the irq handler.

5 9

[alsa-devel] OSS app works but aplay does not with SNDRV_PCM_FMTBIT_U32_LE
by Steve Strobel 21 Sep '07

21 Sep '07

I am developing an ALSA driver for the AD1938 codec on uClinux for Blackfin (I don't believe my problem is specific to that platform). When I set up the snd_pcm_hardware_t structure with .formats = SNDRV_PCM_FMTBIT_S32_LE, I can run both "aplay < /dev/urandom" and an OSS test application ("tone") that sends a sine wave, but the sine wave is "inside out" (see <http://www.link-comm.com/temp/inside_out.gif> for a screen shot) because the codec needs unsigned data. If I set up the snd_pcm_hardware_t structure with .formats = SNDRV_PCM_FMTBIT_U32_LE, the OSS test application sends a nice sine wave, but aplay fails with the following messages: root:~> aplay < /dev/urandom ALSA sound/blackfin/ad1836.c:1050: snd_ad1836_playback_open Playing raw data 'stdin' : Unsigned 8 bit, Rate 8000 Hz, Mono snd_pcm_hw_refine() ACCESS = 00000000ffffffffffffffff -> 0000000000000008 FORMAT = 0000000000000400 -> 0000000000000000 snd_pcm_hw_refine() ACCESS = 333f8fc000a32c60c0333f8fc -> 333f8fc000a00000008 ALSA lib ALSA sound/blackfin/ad1836.c:1172: snd_ad1836_hw_free ../../../src/pcm/pcm_params.c:2152:(snd_pcm_hw_refine_slave) Slave PCM not usable aplay: set_params:882: Broken configuration for this PCM: no configurations available I am working my way through the ALSA source, but I have not yet figured out why aplay won't work with the unsigned codec configuration. Any suggestions? Steve P.S. A more complete log of the console output with both settings for those commands and most of the info from aadebug can be found at the following URLs: <http://www.link-comm.com/temp/SNDRV_PCM_FMTBIT_S32_LE.txt> <http://www.link-comm.com/temp/SNDRV_PCM_FMTBIT_U32_LE.txt> --- Steve Strobel Link Communications, Inc. 1035 Cerise Rd Billings, MT 59101-7378 (406) 245-5002 ext 102 (406) 245-4889 (fax) WWW: http://www.link-comm.com MailTo:steve.strobel@link-comm.com

3 6

[alsa-devel] Pending patches for 1.0.15
by Takashi Iwai 21 Sep '07

21 Sep '07

Hi, we're planning to release 1.0.15rc3 tomorrow. This should be the last candidate before 1.0.15 (hopefully). If you have pending "hotfix" patches, please submit as soon as possible. Thanks. Takashi

3 4

[alsa-devel] [PATCH] alsa: Add the MCP79 support to hda_intel driver
by Peer Chen 21 Sep '07

21 Sep '07

Resend the patch for description modification and send to correct alsa maillist. Add the MCP79 support to hda driver. The patch base on kernel 2.6.23-rc7 Signed-off-by: Peer Chen <peerchen(a)gmail.com> --- --- linux-2.6.23-rc7/sound/pci/hda/hda_intel.c.orig 2007-09-20 15:40:51.000000000 -0400 +++ linux-2.6.23-rc7/sound/pci/hda/hda_intel.c 2007-09-21 13:50:33.000000000 -0400 @@ -1791,6 +1791,10 @@ static struct pci_device_id azx_ids[] = { 0x10de, 0x0775, PCI_ANY_ID, PCI_ANY_ID, 0, 0, AZX_DRIVER_NVIDIA }, /* NVIDIA MCP77 */ { 0x10de, 0x0776, PCI_ANY_ID, PCI_ANY_ID, 0, 0, AZX_DRIVER_NVIDIA }, /* NVIDIA MCP77 */ { 0x10de, 0x0777, PCI_ANY_ID, PCI_ANY_ID, 0, 0, AZX_DRIVER_NVIDIA }, /* NVIDIA MCP77 */ + { 0x10de, 0x0ac0, PCI_ANY_ID, PCI_ANY_ID, 0, 0, AZX_DRIVER_NVIDIA }, /* NVIDIA MCP79 */ + { 0x10de, 0x0ac1, PCI_ANY_ID, PCI_ANY_ID, 0, 0, AZX_DRIVER_NVIDIA }, /* NVIDIA MCP79 */ + { 0x10de, 0x0ac2, PCI_ANY_ID, PCI_ANY_ID, 0, 0, AZX_DRIVER_NVIDIA }, /* NVIDIA MCP79 */ + { 0x10de, 0x0ac3, PCI_ANY_ID, PCI_ANY_ID, 0, 0, AZX_DRIVER_NVIDIA }, /* NVIDIA MCP79 */ { 0, } }; MODULE_DEVICE_TABLE(pci, azx_ids); - -------------- Peer Chen 2007-09-21

1 0

[alsa-devel] [PATCH] sun-cs4231: mce_down cleanup after ad1848
by Krzysztof Helt 20 Sep '07

20 Sep '07

From: Krzysztof Helt <krzysztof.h1(a)wp.pl> This simplifies and fixes waiting loops of the mce_down() function after Trent Piepho's patch for AD1848. It also makes busy_wait() function call not atomic. Signed-off-by: Krzysztof Helt <krzysztof.h1(a)wp.pl> --- diff -urp linux-ref/sound/sparc/cs4231.c linux-2.6.23/sound/sparc/cs4231.c --- linux-ref/sound/sparc/cs4231.c 2007-09-19 23:31:30.603838619 +0200 +++ linux-2.6.23/sound/sparc/cs4231.c 2007-09-19 23:23:24.552140109 +0200 @@ -392,62 +392,45 @@ static void snd_cs4231_mce_up(struct snd static void snd_cs4231_mce_down(struct snd_cs4231 *chip) { - unsigned long flags; - int timeout; + unsigned long flags, timeout; + int reg; - spin_lock_irqsave(&chip->lock, flags); snd_cs4231_busy_wait(chip); + spin_lock_irqsave(&chip->lock, flags); #ifdef CONFIG_SND_DEBUG if (__cs4231_readb(chip, CS4231U(chip, REGSEL)) & CS4231_INIT) snd_printdd("mce_down [%p] - auto calibration time out (0)\n", CS4231U(chip, REGSEL)); #endif chip->mce_bit &= ~CS4231_MCE; - timeout = __cs4231_readb(chip, CS4231U(chip, REGSEL)); - __cs4231_writeb(chip, chip->mce_bit | (timeout & 0x1f), + reg = __cs4231_readb(chip, CS4231U(chip, REGSEL)); + __cs4231_writeb(chip, chip->mce_bit | (reg & 0x1f), CS4231U(chip, REGSEL)); - if (timeout == 0x80) - snd_printdd("mce_down [%p]: serious init problem - codec still busy\n", chip->port); - if ((timeout & CS4231_MCE) == 0) { + if (reg == 0x80) + snd_printdd("mce_down [%p]: serious init problem " + "- codec still busy\n", chip->port); + if ((reg & CS4231_MCE) == 0) { spin_unlock_irqrestore(&chip->lock, flags); return; } - snd_cs4231_busy_wait(chip); - /* calibration process */ + /* + * Wait for auto-calibration (AC) process to finish, i.e. ACI to go low. + */ - snd_cs4231_ready(chip); - snd_cs4231_ready(chip); - if ((snd_cs4231_in(chip, CS4231_TEST_INIT) & CS4231_CALIB_IN_PROGRESS) == 0) { - snd_printd("cs4231_mce_down - auto calibration time out (1)\n"); + timeout = jiffies + msecs_to_jiffies(250); + do { spin_unlock_irqrestore(&chip->lock, flags); - return; - } - - /* in 10ms increments, check condition, up to 250ms */ - timeout = 25; - while (snd_cs4231_in(chip, CS4231_TEST_INIT) & CS4231_CALIB_IN_PROGRESS) { - spin_unlock_irqrestore(&chip->lock, flags); - if (--timeout < 0) { - snd_printk("mce_down - auto calibration time out (2)\n"); - return; - } - msleep(10); - spin_lock_irqsave(&chip->lock, flags); - } - - /* in 10ms increments, check condition, up to 100ms */ - timeout = 10; - while (__cs4231_readb(chip, CS4231U(chip, REGSEL)) & CS4231_INIT) { - spin_unlock_irqrestore(&chip->lock, flags); - if (--timeout < 0) { - snd_printk("mce_down - auto calibration time out (3)\n"); - return; - } - msleep(10); + msleep(1); spin_lock_irqsave(&chip->lock, flags); - } + reg = snd_cs4231_in(chip, CS4231_TEST_INIT); + reg &= CS4231_CALIB_IN_PROGRESS; + } while (reg && time_before(jiffies, timeout)); spin_unlock_irqrestore(&chip->lock, flags); + + if (reg) + snd_printk(KERN_ERR + "mce_down - auto calibration time out (2)\n"); } static void snd_cs4231_advance_dma(struct cs4231_dma_control *dma_cont, ---------------------------------------------------------------------- Bedac w toalecie korzystala z ... >>> http://link.interia.pl/f1bd8

2 3

[alsa-devel] Realtek ALC660-VD jack sense
by Vladimir Pouzanov 20 Sep '07

20 Sep '07

Hello all, I wonder if it could be possible to somehow fix jack sense detection on Realtek ALC660-VD and speaker output. When I plug in headphones speakers are still working and there's no way to separately mute them.

2 1