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

Re: [alsa-devel] 2.6.25-rc8-mm1 -- INFO: possible circular locking dependency detected (while using iw to debug a wireless issue)
by Johannes Berg 04 Apr '08

04 Apr '08

On Thu, 2008-04-03 at 10:41 -0400, Miles Lane wrote: > After collecting the wireshark log, I found this in my messages log: Below is a better version of the trace Miles sent me privately, but I have no idea what would be causing it. I don't think it's related to wireless. ======================================================= [ INFO: possible circular locking dependency detected ] 2.6.25-rc8-mm1 #15 ------------------------------------------------------- iw/9417 is trying to acquire lock: (genl_mutex){--..}, at: [ctrl_dumpfamily+0x37/0xda] ctrl_dumpfamily+0x37/0xda but task is already holding lock: (nlk->cb_mutex){--..}, at: [netlink_dump+0x39/0x22e] netlink_dump+0x39/0x22e which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (nlk->cb_mutex){--..}: [__lock_acquire+0xa02/0xbaf] __lock_acquire+0xa02/0xbaf [lock_acquire+0x76/0x9d] lock_acquire+0x76/0x9d [snd_mixer_oss:mutex_lock_nested+0xd5/0x67b] mutex_lock_nested+0xd5/0x274 [netlink_dump_start+0xbd/0x15a] netlink_dump_start+0xbd/0x15a [genl_rcv_msg+0x9d/0x13a] genl_rcv_msg+0x9d/0x13a [netlink_rcv_skb+0x30/0x75] netlink_rcv_skb+0x30/0x75 [genl_rcv+0x1e/0x2e] genl_rcv+0x1e/0x2e [cfg80211:netlink_unicast+0x1c1/0x1867] netlink_unicast+0x1c1/0x293 [netlink_sendmsg+0x21f/0x22c] netlink_sendmsg+0x21f/0x22c [sock_sendmsg+0xca/0xe1] sock_sendmsg+0xca/0xe1 [sys_sendmsg+0x14d/0x1a8] sys_sendmsg+0x14d/0x1a8 [sys_socketcall+0x163/0x17e] sys_socketcall+0x163/0x17e [sysenter_past_esp+0x6d/0xc5] sysenter_past_esp+0x6d/0xc5 [<ffffffff>] 0xffffffff -> #0 (genl_mutex){--..}: [__lock_acquire+0x929/0xbaf] __lock_acquire+0x929/0xbaf [lock_acquire+0x76/0x9d] lock_acquire+0x76/0x9d [snd_mixer_oss:mutex_lock_nested+0xd5/0x67b] mutex_lock_nested+0xd5/0x274 [ctrl_dumpfamily+0x37/0xda] ctrl_dumpfamily+0x37/0xda [netlink_dump+0x51/0x22e] netlink_dump+0x51/0x22e [netlink_recvmsg+0x156/0x203] netlink_recvmsg+0x156/0x203 [sock_recvmsg+0xd1/0xe9] sock_recvmsg+0xd1/0xe9 [sys_recvmsg+0xf2/0x17f] sys_recvmsg+0xf2/0x17f [sys_socketcall+0x16f/0x17e] sys_socketcall+0x16f/0x17e [sysenter_past_esp+0x6d/0xc5] sysenter_past_esp+0x6d/0xc5 [<ffffffff>] 0xffffffff other info that might help us debug this: 1 lock held by iw/9417: #0: (nlk->cb_mutex){--..}, at: [netlink_dump+0x39/0x22e] netlink_dump+0x39/0x22e stack backtrace: Pid: 9417, comm: iw Not tainted 2.6.25-rc8-mm1 #15 [print_circular_bug_tail+0x5b/0x66] print_circular_bug_tail+0x5b/0x66 [print_circular_bug_header+0xa5/0xb0] ? print_circular_bug_header+0xa5/0xb0 [__lock_acquire+0x929/0xbaf] __lock_acquire+0x929/0xbaf [lock_acquire+0x76/0x9d] lock_acquire+0x76/0x9d [ctrl_dumpfamily+0x37/0xda] ? ctrl_dumpfamily+0x37/0xda [snd_mixer_oss:mutex_lock_nested+0xd5/0x67b] mutex_lock_nested+0xd5/0x274 [ctrl_dumpfamily+0x37/0xda] ? ctrl_dumpfamily+0x37/0xda [ctrl_dumpfamily+0x37/0xda] ? ctrl_dumpfamily+0x37/0xda [ctrl_dumpfamily+0x37/0xda] ctrl_dumpfamily+0x37/0xda [netlink_dump+0x51/0x22e] netlink_dump+0x51/0x22e [mac80211:kfree_skb+0x40/0x45] ? kfree_skb+0x40/0x45 [netlink_recvmsg+0x156/0x203] netlink_recvmsg+0x156/0x203 [sock_sendmsg+0xca/0xe1] ? sock_sendmsg+0xca/0xe1 [sock_recvmsg+0xd1/0xe9] sock_recvmsg+0xd1/0xe9 [<c01313d9>] ? autoremove_wake_function+0x0/0x30 [snd_pcm_oss:copy_from_user+0x3b/0x236] ? copy_from_user+0x3b/0x5e [verify_iovec+0x40/0x70] ? verify_iovec+0x40/0x70 [sys_recvmsg+0xf2/0x17f] sys_recvmsg+0xf2/0x17f [snd_hda_intel:_spin_unlock_irqrestore+0x56/0x6c] ? _spin_unlock_irqrestore+0x56/0x6c [paravirt_get_lazy_mode+0xe/0x1b] ? paravirt_get_lazy_mode+0xe/0x1b [crypto_algapi:kunmap_atomic+0x9e/0x2e8e] ? kunmap_atomic+0x9e/0xbb [handle_mm_fault+0x7aa/0x7bb] ? handle_mm_fault+0x7aa/0x7bb [sys_socketcall+0x16f/0x17e] sys_socketcall+0x16f/0x17e [processor:trace_hardirqs_on+0xf0/0x5d38] ? trace_hardirqs_on+0xf0/0x12c [sysenter_past_esp+0x6d/0xc5] sysenter_past_esp+0x6d/0xc5

4 3

[alsa-devel] Edirol M-16 DX
by James Trevelyan 04 Apr '08

04 Apr '08

I recently bought an Edirol M-16DX and am trying to get it working with Linux. I'm almost there but would appreciate some help in getting it over the line. The M-16DX (http://www.rolandus.com/products/productdetails.aspx?ObjectId=860&ParentId= 114) is a fairly new and pretty neat piece of kit - it works as a standalone 16-channel hardware mixer, with a USB2.0 connection which can send each separate input to the computer, with the ability also to send a stereo stream back to the mixer. In addition it can be put in a DAW controller mode where it acts a control surface with almost all the mixer knobs usable. It's set up as a vendor specific device so at first nothing happens when the usb cable connected. The usb configuration has three interfaces, like some of the other Edirol devices. So I put a new quirk in usbquirks.h for the appropriate device id, with a QUIRK_AUDIO_STANDARD_INTERFACE on interfaces 1 and 2, and a QUIRK_MIDI_FIXED_ENDPOINT on interface 3. Accodring to lsusb -v, each interface provides what looks like a proper class-specific descriptor. Having recompiled, the system now detects the device and loads the usb-audio module when the device is plugged in. It successfully creates alsa devices for capture and playback, as well as midi, with the correct sample rate (44.1, 48 or 96 as set on the device), correct number of channels (18 in and 2 out). All looks as it should. When I aplay an audio file to the device, it plays fine - almost. Everything sounds good, except that every 9-10 seconds, there is a kind of nasty high pitched digital distortion which lasts for a second. (definitely not in the audio file!) This seems to be synchronised to the start of the stream - when I aplay a file, it opens a new stream and the distortion is always in the same places in the song. If I open the ports on jack so the stream stays open, and play music through it on ardour, the distortion is at different points in the song (always about 9-10 seconds apart). I haven't tried capture yet. It all runs fine under windows in the same configuration. I'm at a bit of a loss as to the problem here - perhaps there is something wrong with the detection, and I haven't yet tried creating an AUDIO_FIXED_ENDPOINT quirk to play with the settings manually. But I would have thought in that case it just wouldn't work at all. I know the sample rate and # channels is correct. My system's pretty up to date (2.6.24.3 kernel, alsa-libs 1.0.16). I can provide full lsusb and /proc/asound information as necessary. Suggestions welcome! James

1 0

[alsa-devel] Altec Lansing FX5051 mixer
by Jeremy Nickurak 04 Apr '08

04 Apr '08

I recently purchased an Altec Lansing USB Surround speaker set. (It's a set of 5.1 speakers, with a built-in USB sound card). I've got about a week before the return policy expires and I'd have to return it. The mixer doesn't work at all w/linux kernel 2.6.22, everything is locked at 100% volume, which is pretty unhelpful, as it's the only way to adjust the volume. (no analog controls). Also, the digital control panel locks up when the speakers power up, further preventing any access to the volume controls. The device works out-of-the-box without any drivers under XP, so I have to so-far assume that alsa's usb-audio is missing something. Any thoughts as to what could be wrong? I'm more than happy to prod the device and submit any information I can extract about it, or even potentially opening the device up for remote access if a reputable developer is interested in examining it. -- Jeremy Nickurak -= Email/Jabber: atrus(a)rifetech.com =-

3 4

Re: [alsa-devel] + es1968-fix-jitter-on-some-maestro-cards.patch added to -mm tree
by Rene Herman 03 Apr '08

03 Apr '08

On 03-04-08 20:54, akpm(a)linux-foundation.org wrote: > The patch titled > es1968: fix jitter on some maestro cards > has been added to the -mm tree. Its filename is > es1968-fix-jitter-on-some-maestro-cards.patch [ ... ] > Subject: es1968: fix jitter on some maestro cards > From: Andreas Mueller <andreas(a)stapelspeicher.org> > > This patch suppresses jitter on several Maestro cards in stereo mode (ALSA of > course). > > The patch is also incorporated in the *BSD drivers where I "ported" it from. > > Without this patch most of the stereo audio gets out of sync and really > distorted (oss-emulation with mplayer at 48000khz worked somehow). > > Cc: Rene Herman <rene.herman(a)keyaccess.nl> > Cc: Jaroslav Kysela <perex(a)suse.cz> > Cc: Takashi Iwai <tiwai(a)suse.de> > Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> > --- Tested-By: Rene Herman <rene.herman(a)gmail.com> on a TerraTec DMX (ESS Canyon3D, ES1970MS-3D) which doesn't need this but doesn't seem to be suffering from it either. No idea about this otherwise. > sound/pci/es1968.c | 22 +++++++++++++++++++++- > 1 file changed, 21 insertions(+), 1 deletion(-) > > diff -puN sound/pci/es1968.c~es1968-fix-jitter-on-some-maestro-cards sound/pci/es1968.c > --- a/sound/pci/es1968.c~es1968-fix-jitter-on-some-maestro-cards > +++ a/sound/pci/es1968.c > @@ -1815,6 +1815,23 @@ snd_es1968_pcm(struct es1968 *chip, int > > return 0; > } > +/* > + * suppress jitter on some maestros when playing stereo > + */ > +static void snd_es1968_suppress_jitter(struct es1968 *chip, struct esschan *es) > +{ > + unsigned int cp1; > + unsigned int cp2; > + unsigned int diff; > + > + cp1 = __apu_get_register(chip, 0, 5); > + cp2 = __apu_get_register(chip, 1, 5); > + diff = (cp1 > cp2 ? cp1 - cp2 : cp2 - cp1); > + > + if (diff > 1) { > + __maestro_write(chip, IDR0_DATA_PORT, cp1); > + } > +} > > /* > * update pointer > @@ -1936,8 +1953,11 @@ static irqreturn_t snd_es1968_interrupt( > struct esschan *es; > spin_lock(&chip->substream_lock); > list_for_each_entry(es, &chip->substream_list, list) { > - if (es->running) > + if (es->running) { > snd_es1968_update_pcm(chip, es); > + if (es->fmt & ESS_FMT_STEREO) > + snd_es1968_suppress_jitter(chip, es); > + } > } > spin_unlock(&chip->substream_lock); > if (chip->in_measurement) { Rene.

1 0

[alsa-devel] HDA-Intel ALC880, fujitsu siemens amilo PI1536 and flavours
by Luca Bonora 03 Apr '08

03 Apr '08

Hello developers. I've got a problem with my laptop, I've asked help on alsa-user and now I have a request for you (if it's possible). For a year I tried to use my microphone unsuccessfully. Now I've found a solution, that is to use the flavour "6stack"/"6stack-digout" in place of the flavour "fujitsu". I've read the ALSA-configuration.txt and fujitsu is properly the flavour for _my_ laptop but with 6stack-digout the microphone works and the volume control does not work. Is it possible to 'merge' the two flavours to have both microphone and volume control working? Can I ask it to you? Thank you for your help! Luca

1 0

[alsa-devel] [PATCH] snd_usb_caiaq: fix potential lockups locking
by Daniel Mack 03 Apr '08

03 Apr '08

Hi, attached is a patch for snd_usb_caiaq which fixes system potential lockups when stoping and restarting the stream very quickly multiple times in a row which is what some players do when the user drags the song position slider. Also, it seems that snd_pcm_period_elapsed() must not be called when holding a spinlock? The documentation[*], however, doesn't state that. As this fixes an annoying bug, I would appreciate seeing that one being pushed into 2.6.25. Still possible? Thanks and best regards, Daniel [*] http://www.alsa-project.org/~tiwai/writing-an-alsa-driver/x773.htm#PCM-INTE… ---- Subject: [PATCH] snd_usb_caiaq: fix potential lockups This patch fixes potential lockups in snd_usb_caiaq by refining the locking mechanims and by using usb_kill_urb() in favor to usb_unlink_urb(). Signed-off-by: Daniel Mack <daniel(a)caiaq.de>

1 0

[alsa-devel] Problems in writing test apps
by haoshun 03 Apr '08

03 Apr '08

Hi: sorry,forget to add the subject right now... I'm confused by a problem when i modify a test application "alsa-lib-1.0.13/test/control.c". I wanna use the structure "snd_ctl_elem_value_t",but when i write like this: snd_ctl_elem_value_t aaa; there will be an error: storage size of 'aaa' isn't known while snd_ctl_elem_value_t *aaa; makes no errors. But i can't change it directly such as: aaa->id=test_id ; //test_id is defined before cause it will bring an error: dereferencing pointer to incomplete type I think i should use the function like "snd_ctl_elem_info_set_id",but i just want to know why,i don't think it disobeys the C syntax.Is there something different in the ALSA making procedure?or Makefile? haoshun 2008-04-03

2 1

[alsa-devel] (no subject)
by 郝舜 03 Apr '08

03 Apr '08

Hi: I'm confused by a problem when i modify a test application "alsa-lib-1.0.13/test/control.c". I wanna use the structure "snd_ctl_elem_value_t",but when i write like this: snd_ctl_elem_value_t aaa; there will be an error: storage size of 'aaa' isn't known while snd_ctl_elem_value_t *aaa; makes no errors. But i can't change it directly such as: aaa->id=test_id ; //test_id is defined before cause it will bring an error: dereferencing pointer to incomplete type I think i should use the function like "snd_ctl_elem_info_set_id",but i just want to know why,i don't think it disobeys the C syntax.Is there something different in the ALSA making procedure?or Makefile? haoshun 2008-04-03

2 1

[alsa-devel] ASoC for TI OMAP - Multiformat ASoC DAI link driver?
by Jarkko Nikula 03 Apr '08

03 Apr '08

Currently in ASoC v1 we have one DAI driver per one format? E.g. separate drivers for I2S, AC97, etc and type field in cpu_dai structure is not a bit field or at least not used such way in soc-core.c and DAI link drivers. struct snd_soc_cpu_dai pxa_i2s_dai = { ... .type = SND_SOC_DAI_I2S, ... I looked shortly asoc-v2-dev branch and now this type field is gone. Does it mean that there you can have DAI link driver which supports multiple formats in set_fmt callback? I'm asking this since McBSP (Multichannel Buffered Serial Port) found in OMAP processors can be configured to almost any imaginable format and IMO it doesn't make a sense to have separate drivers for each of them if there is a difference only in few configuration bits. -- Jarkko

2 2

[alsa-devel] ASoC for TI OMAP - alsa-devel submission?
by Jarkko Nikula 03 Apr '08

03 Apr '08

I've been doing generic ASoC drivers for Texas Instruments OMAP processors and I recently released the first version on linux-omap mailing list: http://marc.info/?l=linux-omap&m=120643770810683&w=2 http://marc.info/?l=linux-omap&m=120643766610623&w=2 Currently patch tries to cover OMAPs from 1x10 to 2420 and is tested on Nokia N810 having OMAP2420 and TLV320AIC33 codec. I'm going to release it here also but there are few issues I would like to discuss before it: - McBSP used in OMAP2430 and OMAP3430 are bit different than other 1510-2420 OMAPs and that support we have currently missing in linux-omap either. However, changes to my drivers should be quite minimal in order to support them. E.g. base address definitions and different DMA data type. - Solving the channel synchronization problem might require API change to linux-omap McBSP driver. - ASoC v2 considerations? Like multiformat DAI. - Multiformat McBSP DAI link driver (I'll send an another mail on that). So what I mean that should I post the patch like as it now, rebased to dev branch of linux-2.6-asoc tree and with some minor changes, or wait a bit when all linux-omap and ASoC v2 evolve? What you think? -- Jarkko

2 2