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

Re: [alsa-devel] RFC: PCM extra attributes
by Takashi Iwai 19 Jun '09

19 Jun '09

At Fri, 19 Jun 2009 10:54:15 +0200, Florian Faber wrote: > > Takashi, > > > An important note is that I'm planning to use this framework for > > getting/setting the PCM (surround) channel mapping. > > I don't understand what this means. Who maps what on what and why? It's a mapping of surround channels. Right now, ALSA assumes (usually) the order of channels like front-left, front-rear, surround-left, surround-rear, center, LFE, ... But this really depends on the device. Some (or many) need FL/FR/C/LFE/SR/SR order, for example. And, some devices can allow you even to reassign the channel map. This is likely an additional information, which not all drivers have to provide. Takashi

1 0

[alsa-devel] RFC: "patch" loading for HD-audio driver
by Takashi Iwai 19 Jun '09

19 Jun '09

Hi, another changes I've worked recently on is a "patch"-loading mechanism for HD-audio. Here, a "patch" refers to a sort of firmware file, corresponding "*.INI" file on Windows. As many of you know, HD-audio hardwares have many problems, partly because of crappy broken BIOS and partly because of lack of information that the driver can detect automatically. Until now, these are provided statically in the driver. In the recent version of HD-audio driver, you can override the setup and reconfigure the driver via sysfs. For example, changing the default pin-configurations can be done via sysfs and then reconfigure. However, this procedure can be done only after the driver is set up, not before the driver initialization. So an idea of "patching" the setup before the driver initialization came up. A "patch" file is a text file looks like: ================================================================ [codec] 0x12345678 0xabcd1234 2 [model] auto [pincfg] 0x12 0x411111f0 [verb] 0x20 0x500 0x03 0x20 0x400 0xff [hint] hp_detect = yes ================================================================ This file can be provided in the standard firmware path, typically /lib/firmware, through a module parameter "patch", e.g. options snd-hda-intel patch=my-hda-patch where /lib/firmware/my-hda-patch is the patch file path. The whole patch (I mean program patch) series can be found in topic/hda-patch branch of sound-unstable GIT tree. git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-unstable-2.6.git topic/hda-patch If you are interested, please take a look. Any comments appreciated. This work is intended for 2.6.32 merge as well as other hacks there. thanks, Takashi

1 0

Re: [alsa-devel] kerneloops.org report for the week of June 14 2009
by Arjan van de Ven 19 Jun '09

19 Jun '09

On Thu, 18 Jun 2009 13:08:39 -0400 Bob Copeland <me(a)bobcopeland.com> wrote: > On Sun, Jun 14, 2009 at 8:33 PM, Arjan van de > Ven<arjan(a)infradead.org> wrote: > > Rank 9: minstrel_get_rate (warning) > > Reported 64 times (384 total reports) > > Issue with the ath5k driver > > This warning was last seen in version 2.6.30-rc3, and first > > seen in 2.6.27.12. More info: > > http://www.kerneloops.org/searchweek.php?search=minstrel_get_rate > > I believe this is fixed by http://lkml.org/lkml/2009/6/5/269, now > in pre-2.6.31. Hmm, odd though, we should be seeing reports from > other wireless drivers since it's a general memory corruption > unrelated to ath5k (but not all use the mac80211 rate controllers). > well.. out of the 534 reports or so that I have by now... 525 have ath5k loaded..... it's not 100% but it'd pretty close. -- Arjan van de Ven Intel Open Source Technology Centre For development, discussion and tips for power savings, visit http://www.lesswatts.org

1 0

Re: [alsa-devel] [PATCH v2] alsa-plugins/pulse: Implement 'pause'.
by Takashi Iwai 18 Jun '09

18 Jun '09

At Thu, 18 Jun 2009 14:55:21 +0100 (BST), Troy Moure wrote: > > Just cork or uncork the stream to pause or unpause it. > > Signed-off-by: Troy Moure <twmoure(a)szypr.net> Applied now. Thanks! Takashi > --- > On Wed, 17 Jun 2009, Lennart Poettering wrote: > > > Looks mostly good to me, but: > > > ... > > > > pa_stream_cork() will return a pa_operation object on success. The > > least you need to do is call pa_operation_unref() on it, which you can > > safely do right-away. Otherwise this will leak memory. > > > > Lennart > > Thanks, Lennart, for looking at the first verson I sent. I've added a > call to pa_operation_unref() as you suggested. > > pulse/pcm_pulse.c | 25 +++++++++++++++++++++++++ > 1 files changed, 25 insertions(+), 0 deletions(-) > > diff --git a/pulse/pcm_pulse.c b/pulse/pcm_pulse.c > index db8d1e1..c276839 100644 > --- a/pulse/pcm_pulse.c > +++ b/pulse/pcm_pulse.c > @@ -739,6 +739,30 @@ static int pulse_close(snd_pcm_ioplug_t * io) > return 0; > } > > +static int pulse_pause(snd_pcm_ioplug_t * io, int enable) > +{ > + snd_pcm_pulse_t *pcm = io->private_data; > + int err = 0; > + > + assert (pcm); > + assert (pcm->p); > + > + pa_threaded_mainloop_lock(pcm->p->mainloop); > + > + if (pcm->stream) { > + pa_operation *o; > + o = pa_stream_cork(pcm->stream, enable, NULL, NULL); > + if (o) > + pa_operation_unref(o); > + else > + err = -EIO; > + } > + > + pa_threaded_mainloop_unlock(pcm->p->mainloop); > + > + return err; > +} > + > static const snd_pcm_ioplug_callback_t pulse_playback_callback = { > .start = pulse_start, > .stop = pulse_stop, > @@ -750,6 +774,7 @@ static const snd_pcm_ioplug_callback_t pulse_playback_callback = { > .prepare = pulse_prepare, > .hw_params = pulse_hw_params, > .close = pulse_close, > + .pause = pulse_pause > }; > > > -- > 1.6.2.2 > > > > > > > > > -- > > Lennart Poettering Red Hat, Inc. > > lennart [at] poettering [dot] net > > http://0pointer.net/lennart/ GnuPG 0x1A015CC4 > > >

1 0

Re: [alsa-devel] [PATCH v2] alsa-plugins/pulse: Implement 'pause'.
by Lennart Poettering 18 Jun '09

18 Jun '09

On Thu, 18.06.09 14:55, Troy Moure (twmoure(a)szypr.net) wrote: > > pa_stream_cork() will return a pa_operation object on success. The > > least you need to do is call pa_operation_unref() on it, which you can > > safely do right-away. Otherwise this will leak memory. > > > > Lennart > > Thanks, Lennart, for looking at the first verson I sent. I've added a > call to pa_operation_unref() as you suggested. Looks good to me now. > > pulse/pcm_pulse.c | 25 +++++++++++++++++++++++++ > 1 files changed, 25 insertions(+), 0 deletions(-) > > diff --git a/pulse/pcm_pulse.c b/pulse/pcm_pulse.c > index db8d1e1..c276839 100644 > --- a/pulse/pcm_pulse.c > +++ b/pulse/pcm_pulse.c > @@ -739,6 +739,30 @@ static int pulse_close(snd_pcm_ioplug_t * io) > return 0; > } > > +static int pulse_pause(snd_pcm_ioplug_t * io, int enable) > +{ > + snd_pcm_pulse_t *pcm = io->private_data; > + int err = 0; > + > + assert (pcm); > + assert (pcm->p); > + > + pa_threaded_mainloop_lock(pcm->p->mainloop); > + > + if (pcm->stream) { > + pa_operation *o; > + o = pa_stream_cork(pcm->stream, enable, NULL, NULL); > + if (o) > + pa_operation_unref(o); > + else > + err = -EIO; > + } > + > + pa_threaded_mainloop_unlock(pcm->p->mainloop); > + > + return err; > +} > + > static const snd_pcm_ioplug_callback_t pulse_playback_callback = { > .start = pulse_start, > .stop = pulse_stop, > @@ -750,6 +774,7 @@ static const snd_pcm_ioplug_callback_t pulse_playback_callback = { > .prepare = pulse_prepare, > .hw_params = pulse_hw_params, > .close = pulse_close, > + .pause = pulse_pause > }; > > Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4

1 0

Re: [alsa-devel] Regarding internal mic on Aspire 6935G
by Karthik Ramgopal 18 Jun '09

18 Jun '09

Hi, How to check if it works in stereo or mono mode? I remember reading hector's entry on his blog that on account of some wierd sum/difference problem he had duplicated the + signal across both outputs so it was actually mono? Regards, Karthik

2 1

[alsa-devel] preventing SNDRV_PCM_STATE_XRUN
by Sergey Lapin 18 Jun '09

18 Jun '09

Hi, all! I have uncontrollable data stream which I need to play through kernel via ALSA snd_pcm_lib_write call. Everything is fine, but once a few seconds I get SNDRV_PCM_STATE_XRUN on stream and thus, -EPIPE. Sound glitches are minor, but annoying. Is it possible to somehow prevent this from happenning? Is it possible to distinguish if my next chunk of data will fit? Thanks a lot, S.

1 0

[alsa-devel] Regarding internal mic on Aspire 6935G
by Karthik Ramgopal 18 Jun '09

18 Jun '09

Hi, Sorry for the confusion. My internal mic does work, but wierdly not in Gnome Sound recorder. Skype detects it just fine and I am able to talk without making any changes to the code. So, I guess 8930G and 6935G are same after all. Thanks and Regards, Karthik PS: Please also add the PCI ID's of 6920G (0x1025 0146) and 8920G (0x1025 0145) under the same quirk. They also use ALC889 chipset with the same pinconfig.

2 2

Re: [alsa-devel] trace PCM data from usb bus to alsa lib
by Takashi Iwai 18 Jun '09

18 Jun '09

At Wed, 17 Jun 2009 16:10:26 +0800, Zero Luo wrote: > > Dear Takashi, > > Data from usb dongle is 16K*16 bit PCM data. And what is the format and channels you are using in alsa-lib? alsa-lib itself can convert formats and channels automatically if needed. Takashi > 2009/6/17, Takashi Iwai <tiwai(a)suse.de>: > > At Wed, 17 Jun 2009 07:25:25 +0000 (UTC), > ZeroCluo wrote: > > > > Hi > > > > I am trying to trace the Audio data from usb bus. > > in kernel: > > dump data in retire_capture_urb() ,found data format is like: > > AABB 0000 CCDD 0000 ; > > > > but in alsa library , > > dump data in snd_pcm_mmap_begin(),the "0000" is cut,only "AABB CCDD", > > > > Do you know when and where those "0000" is cut? > > Are you using the native format that the hardware runs? > > Takashi > >

2 3

Re: [alsa-devel] snd-ctxfi oops
by The Source 18 Jun '09

18 Jun '09

On 15.06.2009 17:01, Takashi Iwai wrote: > At Mon, 15 Jun 2009 15:00:03 +0200, > I wrote: > >> At Mon, 15 Jun 2009 16:59:53 +0400, >> The Source wrote: >> >>> On 15.06.2009 16:56, Takashi Iwai wrote: >>> >>>> At Sat, 13 Jun 2009 10:07:49 +0200, >>>> I wrote: >>>> >>>> >>>>> >>>>> >>>>>> Tested the patch more. Really no oopses. Instead of them I get rare >>>>>> system lockups. >>>>>> >>>>>> >>>>> In which situation, exactly? >>>>> Could you check whether it happens with use_system_timer=1 module >>>>> option, too? >>>>> >>>>> >>>> Or try the very latest alsa-driver-snapshot (not daily tarball). >>>> I fixed a deadlock issue in cttimer.c now. >>>> >>>> >>>> thanks, >>>> >>>> Takashi >>>> >>>> >>>> >>> Should I apply that patch to this snapshot? >>> >> Which patch do you mean? >> Just grab the latest alsa-driver-snapshot.tar.gz from >> ftp://ftp.kernel.org/pub/linux/kernel/people/tiwai/snapshot/ >> > Also, check alsa-driver/alsa-kernel/HEAD whether the commit > 8dca419721d188bfee5f19fad45275856c619a5c > ALSA: ctxfi - Fix deadlock with xfi-timer > is included. > > > Takashi > > Tested the driver and it's fine so far. No craches with any application including Doom 3, which caused system lockups often with earlier versions of the driver.

2 1