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

[alsa-devel] [PATCH v20 0/3] ASoC/MFD/V4L2: WL1273 FM Radio driver
by Matti J. Aaltonen 28 Feb '11

28 Feb '11

Hello. And thanks for the comments. If we now move quickly enough we can get this thing in before it becomes deprecated... Samuel wrote: > for Mauro to take this one you'd have to provide a > diff against the already existing wl1273-core. I've made these patches against the existing stuff. >> + * Copyright (C) 2010 Nokia Corporation >2011. Changed. >> +} > I'm confused with this one: Isn't WL1273_VOLUME_SET a command ? Also, > how can reading from it set the volume ? It cannot... so I've changed it (back) to write. >> + i2c_set_clientdata(client, NULL) >Not needed. Removed. >> +err: >> + i2c_set_clientdata(client, NULL); >Ditto. Ditto. Cheers, Matti Matti J. Aaltonen (3): MFD: Wl1273 FM radio core: Add I2C IO functions. V4L2: Wl1273 FM Radio: Remove I2C IO functions. ASoC: WL1273 FM radio: Access I2C IO functions through pointers. drivers/media/radio/radio-wl1273.c | 360 +++++++++++------------------------- drivers/mfd/Kconfig | 2 +- drivers/mfd/wl1273-core.c | 149 +++++++++++++++- include/linux/mfd/wl1273-core.h | 2 + sound/soc/codecs/Kconfig | 2 +- sound/soc/codecs/wl1273.c | 11 +- 6 files changed, 264 insertions(+), 262 deletions(-)

1 3

[alsa-devel] [PATCH - powermac] Allow input from microphone on Tumbler
by Risto Suominen 28 Feb '11

28 Feb '11

From: Risto Suominen <Risto.Suominen(a)gmail.com> Allow input from microphone on remaining PowerBooks and iBooks with Tumbler. Tested only with PowerBook G4 Gigabit Ethernet (PowerBook3,3). Signed-off-by: Risto Suominen <Risto.Suominen(a)gmail.com> --- Kernel version 2.6.32 (probably any 2.6), ALSA 1.0.22.1. The patch is available here, too: http://ristosu.wippiespace.com/pub/alsa-pmac-1.0.22.1-p1.diff --- a/alsa-kernel/ppc/pmac.c.org 2009-12-28 16:21:33.000000000 +0200 +++ b/alsa-kernel/ppc/pmac.c 2011-02-27 21:42:53.000000000 +0200 @@ -1034,7 +1034,11 @@ static int __devinit snd_pmac_detect(str if (of_device_is_compatible(sound, "tumbler")) { chip->model = PMAC_TUMBLER; chip->can_capture = machine_is_compatible("PowerMac4,2") - || machine_is_compatible("PowerBook4,1"); + || machine_is_compatible("PowerBook3,2") + || machine_is_compatible("PowerBook3,3") + || machine_is_compatible("PowerBook4,1") + || machine_is_compatible("PowerBook4,2") + || machine_is_compatible("PowerBook4,3"); chip->can_duplex = 0; // chip->can_byte_swap = 0; /* FIXME: check this */ chip->num_freqs = ARRAY_SIZE(tumbler_freqs);

2 1

[alsa-devel] [[PATCH] ALSA 1/1] Fix alsa-lib to regard 3D control - Depth as Playback Controls
by Raymond Yau 28 Feb '11

28 Feb '11

Fix alsa-lib to regard 3D control - Depth as Playback Controls This allow those mixer or recording application to find those controls which are really used for capturing

2 1

[alsa-devel] Problem when using silence 'trick'
by Bryan Ischo 28 Feb '11

28 Feb '11

Hi ALSA developers! I am working on my first project that uses sound under Linux, and I've chosen to implement directly to the ALSA API. I am amazed that I was able to get sound working in so few lines of code with ALSA. I like the API and its performance alot but I have a problem! My program, early in its development, wanted to play just one sound stream at a time; and it is a sound stream which normally delivers audio at a sufficent rate to avoid XRUN but in some circumstances the thread generating audio cannot keep up and it falls behind, resulting in XRUN. Well I found that in cases where the audio thread is 'almost' keeping up, the standard behavior of allowing an XRUN to occur, detecting it on the next call to snd_pcm_writei, and 'fixing' it by calling snd_pcm_prepare() and then proceeding to continue delivering audio frames, had the following unfortunate problems: 1. The audio sounds crackly and awful (which is to be expected to some degree with XRUN) 2. The time taken to re-prepare the ALSA device is counterproductive; it takes even more time away from the thread that is delivering audio and thus makes the case where the audio is very marginally behind 'real time' much worse. I thought, if only I could tell ALSA to just play silence if it has run out of frames of audio instead of XRUNning, and then I can add real frames of audio back in as soon as they are available and pick up the audio stream where it left off. Some digging into the ALSA API and I found that someone on the ALSA team had already beaten me to the thought! The API docs kind of hint at how you would go about doing this, and I found this technique to be very successful: 1. Use snd_pcm_sw_params_set_stop_threshold to set the stop threshold to 0. Now, no XRUN - ALSA will keep looping in the circular buffer and play whatever is there; and if you haven't updated quickly enough, you just get looping snippets of audio. 2. Use snd_pcm_sw_params_set_silence_threshold to 0 and snd_pcm_sw_params_set_silence_size to set the silence 'size' to the boundary value obtained by calling snd_pcm_sw_params_get_boundary(). Now ALSA is instructed to fill the already-played portions of the circular buffer with silence, which means that even when looping due to XRUN, no sound is played over and over, instead silence is played. Hey presto - works perfectly! Then later on I needed to play more than one sound simultaneously. It turns out that I had been opening the "plughw:0,0" device originally and this had been working great with my sound trick. The problem is, you cannot use plughw:0,0 and open it more than once to play more than one sound simultaneously; the second open will fail. So after some digging I found that the device I really should have been using all along is called "default" (hey, you'd think it would be obvious, but somehow I never found ALSA documentation that told me to do this). Now the real problem: when I use the "default" device with my silence technique, I have no problem playing multiple audio streams simultaneously by opening the "default" device multiple times and simultaneously playing streams into the different devices. BUT, whenever I cannot deliver audio fast enough to a stream, and the silence trick takes over and the stream plays some silence - boom, the device goes silent forever. I don't get any errors from any ALSA function, I just get silence no matter what I write into the device after that point. This is in sharp contrast to the plughw:0,0 device, which does play silence if I don't deliver audio fast enough but immediately plays whatever audio I do end up delivering to it when I finally have audio to deliver. Am I using an invalid technique with this silence trick? Is this a known and expected behavior of the "default" device? Or could something else be going on? Thanks for any advice you can give! Best wishes, Bryan

2 2

[alsa-devel] Tascam M-164UF module request/information
by Dan Swain 28 Feb '11

28 Feb '11

Dear ALSA developers, After talking with nevyn on the ALSA IRC channel on Freenode, I have been recommended to submit the device information to this list so that the developers can take it further! The pastebin for this device is at: http://alsa.pastebin.com/YsMDfyxi (a lsusb -v -d 0644: output) The device shows up in dmesg, but so far ALSA is unaware of the device. I don't have much programming experience, but if I can offer any help, please let me know and I'll do what I can :-) Many Thanks, Dan PS: Official information for the device can be found at: http://www.tascam.de/en/m-164.html

1 0

[alsa-devel] [PATCH 17/17]sound:core:seq:seq_ports.c Remove one to many n's in a word.
by Justin P. Mattock 27 Feb '11

27 Feb '11

The Patch below removes one to many "n's" in a word.. Signed-off-by: Justin P. Mattock <justinmattock(a)gmail.com> CC: Jaroslav Kysela <perex(a)perex.cz> CC: Takashi Iwai <tiwai(a)suse.de> CC: alsa-devel(a)alsa-project.org --- sound/core/seq/seq_ports.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/sound/core/seq/seq_ports.c b/sound/core/seq/seq_ports.c index 3bf7d73..e12bcd9 100644 --- a/sound/core/seq/seq_ports.c +++ b/sound/core/seq/seq_ports.c @@ -412,7 +412,7 @@ int snd_seq_get_port_info(struct snd_seq_client_port * port, * initialization or termination of devices (see seq_midi.c). * * If callback_all option is set, the callback function is invoked - * at each connnection/disconnection. + * at each connection/disconnection. */ static int subscribe_port(struct snd_seq_client *client, -- 1.7.4.1

2 1

Re: [alsa-devel] [PATCH] intel8x0m: schedule timeout before warm reset check
by Takashi Iwai 27 Feb '11

27 Feb '11

At Sun, 27 Feb 2011 01:23:58 +0100, Paul Bolle wrote: > > At every resume a laptop I use prints this message (at KERN_ERR level): > ALSA sound/pci/intel8x0m.c:904: AC'97 warm reset still in progress? > [0x2] > > The thing to note here is that 0x2 corresponds to ICH_AC97COLD. Ie, what > seems to be happening is that the register involved indicated a warm > reset for some time (as the ICH_AC97WARM bit was set) but by the time > the warning is printed, and that same register is checked again, that > bit is already cleared and only the ICH_AC97COLD bit is still set. > > It turns out a warm reset needs some time to settle, but it is currently > checked right away. The test therefore fails the first time it is done > and schedule_timeout_uninterruptible() will be called. Once we return > from that jiffies is already (far) past end_time on this laptop, so we > exit the loop, print a warning, and exit the function while the warm > reset actually succeeded. > > One way to fix this is to call schedule_timeout_uninterruptible() at the > start of the loop. (This might punish the "finish cold reset" case, but > on this laptop such a cold reset apparently never happens, so I can't > say for sure.) > > While we're at it drop the extra single tick from end_time, as it looks > rather silly. > > Signed-off-by: Paul Bolle <pebolle(a)tiscali.nl> > --- > The question I asked in the previous message ("snd_intel8x0m: error > message because return value is unused?") made little sense. I probably > got quite confused by my own efforts to debug this. It'd be better to put a more proper delay time than tick, e.g. usleep_range() or whatever. schedule_timeout(1) can be a different length depending on HZ. Could you figure out? thanks, Takashi > > sound/pci/intel8x0m.c | 4 ++-- > 1 files changed, 2 insertions(+), 2 deletions(-) > > diff --git a/sound/pci/intel8x0m.c b/sound/pci/intel8x0m.c > index 13cec1e..9abff7b 100644 > --- a/sound/pci/intel8x0m.c > +++ b/sound/pci/intel8x0m.c > @@ -894,11 +894,11 @@ static int snd_intel8x0m_ich_chip_init(struct intel8x0m *chip, int probing) > /* finish cold or do warm reset */ > cnt |= (cnt & ICH_AC97COLD) == 0 ? ICH_AC97COLD : ICH_AC97WARM; > iputdword(chip, ICHREG(GLOB_CNT), cnt); > - end_time = (jiffies + (HZ / 4)) + 1; > + end_time = jiffies + HZ / 4; > do { > + schedule_timeout_uninterruptible(1); > if ((igetdword(chip, ICHREG(GLOB_CNT)) & ICH_AC97WARM) == 0) > goto __ok; > - schedule_timeout_uninterruptible(1); > } while (time_after_eq(end_time, jiffies)); > snd_printk(KERN_ERR "AC'97 warm reset still in progress? [0x%x]\n", > igetdword(chip, ICHREG(GLOB_CNT))); > -- > 1.7.4.1 > > > >

1 0

[alsa-devel] ASoC update for 2.6.38
by Mark Brown 26 Feb '11

26 Feb '11

The following changes since commit 4bfc4e2508234f9149fd33fae853e99fb9e4a75b: ASoC: correct pxa AC97 DAI names (2011-02-25 11:42:18 +0000) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound-2.6.git for-2.6.38 Eric Bénard (1): eukrea-tlv320: fix platform_name sound/soc/imx/eukrea-tlv320.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)

2 1

Re: [alsa-devel] [PATCH v5] ASoC: Add Freescale SGTL5000 codec support
by Timur Tabi 26 Feb '11

26 Feb '11

On Fri, Feb 25, 2011 at 9:56 AM, Zeng Zhaoming <zengzm.kernel(a)gmail.com> wrote: > I have not remove void* since my toolchain ( gcc 4.4.4) complains > about the type mismatch, I will test > it with other version toolchain to confirm. That's because you declared sgtl5000_regs[] as "const", which it isn't. The compiler is trying to tell you that you made a mistake. -- Timur Tabi Linux kernel developer at Freescale

1 0

Re: [alsa-devel] [PATCH v5] ASoC: Add Freescale SGTL5000 codec support
by Timur Tabi 25 Feb '11

25 Feb '11

On Fri, Feb 25, 2011 at 9:56 AM, Zeng Zhaoming <zengzm.kernel(a)gmail.com> wrote: >>> + memcpy((void *)(&sgtl5000_regs[0] + (SGTL5000_DAP_REG_OFFSET >> 1)), >>> + sgtl5000_dap_regs, >>> + SGTL5000_MAX_REG_OFFSET - SGTL5000_DAP_REG_OFFSET); >> >> As has been pointed out on previous revisions of the patch there is no >> need to cast away from void in C and it can be actively harmful. >> > I have not remove void* since my toolchain ( gcc 4.4.4) complains > about the type mismatch, I will test > it with other version toolchain to confirm. It would probably be simpler if you did this instead: memcpy((void *)sgtl5000_regs + SGTL5000_DAP_REG_OFFSET, IMHO, you should be using a struct instead of an array for stgtl5000_regs. -- Timur Tabi Linux kernel developer at Freescale

1 0