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

[alsa-devel] [LOCKDEP] 33-rc8 Running aplay with pulse as the default
by Ed Tomlinson 18 Feb '10

18 Feb '10

Hi, Inorder to get skype working with linux I have the following in .asoundrc for my normal userid. --- pcm.pulse { type pulse } ctl.pulse { type pulse } pcm.!default { type pulse } ctl.!default { type pulse --- Try #1 Starting as root if I do: su - <id> aplay sound.wav <traceback inlined below> aplay sound.wav (silence) killall pulseaudio aplay sound.wav (works as expected now going thru pulseaudio) Try #2 Starting as root if I do: aplay sound.wav (works as expected using alsa alone) su - <id> aplay sound.wav <another lockdep traceback> aplay sound.wav (works as expected now going thru pulseaudio) With .32 there were no tracebacks (lockdep was enabled) and try #1 would work where I now get silence. Ideas? Ed Tomlinson aplay -l **** List of PLAYBACK Hardware Devices **** card 0: SB [HDA ATI SB], device 0: ALC1200 Analog [ALC1200 Analog] Subdevices: 0/1 Subdevice #0: subdevice #0 card 0: SB [HDA ATI SB], device 1: ALC1200 Digital [ALC1200 Digital] Subdevices: 1/1 Subdevice #0: subdevice #0 card 1: HDMI [HDA ATI HDMI], device 3: ATI HDMI [ATI HDMI] Subdevices: 1/1 Subdevice #0: subdevice #0 "ALC1200 Analog" is what has speakers connected The em28xx in the traceback is an input source from a usb hdtv dongle. pavucontrol setup has been verified. [ 91.070620] [ 91.070621] ======================================================= [ 91.071378] [ INFO: possible circular locking dependency detected ] [ 91.071378] 2.6.33-rc8-crc #106 [ 91.071378] ------------------------------------------------------- [ 91.071378] pulseaudio/2717 is trying to acquire lock: [ 91.071378] (&dev->lock){+.+.+.}, at: [<ffffffffa02797f1>] snd_em28xx_capture_open+0x61/0x190 [em28xx_alsa] [ 91.071378] [ 91.071378] but task is already holding lock: [ 91.071378] (&pcm->open_mutex){+.+.+.}, at: [<ffffffffa010ecd2>] snd_pcm_open+0x182/0x450 [snd_pcm] [ 91.071378] [ 91.071378] which lock already depends on the new lock. [ 91.071378] [ 91.071378] [ 91.071378] the existing dependency chain (in reverse order) is: [ 91.071378] [ 91.071378] -> #3 (&pcm->open_mutex){+.+.+.}: [ 91.071378] [<ffffffff81083215>] __lock_acquire+0xfc5/0x1550 [ 91.071378] [<ffffffff8108383c>] lock_acquire+0x9c/0x140 [ 91.071378] [<ffffffff814b96c1>] __mutex_lock_common+0x61/0x610 [ 91.071378] [<ffffffff814b9d53>] mutex_lock_nested+0x43/0x50 [ 91.071378] [<ffffffffa010ad32>] snd_pcm_release+0x42/0xb0 [snd_pcm] [ 91.071378] [<ffffffff8112115d>] __fput+0x15d/0x290 [ 91.071378] [<ffffffff811212ad>] fput+0x1d/0x30 [ 91.071378] [<ffffffff810fe001>] remove_vma+0x51/0x80 [ 91.071378] [<ffffffff810ffa1d>] do_munmap+0x2fd/0x390 [ 91.071378] [<ffffffff810ffb06>] sys_munmap+0x56/0x80 [ 91.071378] [<ffffffff81002adb>] system_call_fastpath+0x16/0x1b [ 91.071378] [ 91.071378] -> #2 (&mm->mmap_sem){++++++}: [ 91.071378] [<ffffffff81083215>] __lock_acquire+0xfc5/0x1550 [ 91.071378] [<ffffffff8108383c>] lock_acquire+0x9c/0x140 [ 91.071378] [<ffffffff810f62c7>] might_fault+0xa7/0xd0 [ 91.071378] [<ffffffff8113102b>] filldir+0x7b/0xe0 [ 91.071378] [<ffffffff8118aa21>] sysfs_readdir+0xf1/0x1b0 [ 91.071378] [<ffffffff81131268>] vfs_readdir+0xb8/0xe0 [ 91.071378] [<ffffffff8113144d>] sys_getdents+0xad/0x110 [ 91.071378] [<ffffffff81002adb>] system_call_fastpath+0x16/0x1b [ 91.071378] [ 91.071378] -> #1 (sysfs_mutex){+.+.+.}: [ 91.071378] [<ffffffff81083215>] __lock_acquire+0xfc5/0x1550 [ 91.071378] [<ffffffff8108383c>] lock_acquire+0x9c/0x140 [ 91.071378] [<ffffffff814b96c1>] __mutex_lock_common+0x61/0x610 [ 91.071378] [<ffffffff814b9d53>] mutex_lock_nested+0x43/0x50 [ 91.071378] [<ffffffff8118b082>] sysfs_addrm_start+0x22/0x30 [ 91.071378] [<ffffffff8118bc58>] create_dir+0x58/0xb0 [ 91.514885] [<ffffffff8118bd0a>] sysfs_create_dir+0x5a/0x70 [ 91.514885] [<ffffffff8123ebbd>] kobject_add_internal+0xbd/0x1f0 [ 91.514885] [<ffffffff8123ee08>] kobject_add_varg+0x38/0x60 [ 91.514885] [<ffffffff8123eee4>] kobject_add+0x44/0x70 [ 91.514885] [<ffffffff81392510>] device_add+0xb0/0x5e0 [ 91.514885] [<ffffffff81392a5e>] device_register+0x1e/0x30 [ 91.514885] [<ffffffff8140a50d>] i2c_register_adapter+0x12d/0x250 [ 91.514885] [<ffffffff8140a7f1>] i2c_add_adapter+0xb1/0xd0 [ 91.514885] [<ffffffffa0231ba4>] em28xx_i2c_register+0x104/0x520 [em28xx] [ 91.514885] [<ffffffffa0233daa>] em28xx_usb_probe+0x68a/0xb90 [em28xx] [ 91.514885] [<ffffffff813eb4ab>] usb_probe_interface+0xeb/0x1b0 [ 91.514885] [<ffffffff81395546>] driver_probe_device+0xc6/0x1d0 [ 91.514885] [<ffffffff813956eb>] __driver_attach+0x9b/0xa0 [ 91.514885] [<ffffffff8139492c>] bus_for_each_dev+0x6c/0xa0 [ 91.514885] [<ffffffff8139535e>] driver_attach+0x1e/0x20 [ 91.514885] [<ffffffff81394c11>] bus_add_driver+0xe1/0x280 [ 91.514885] [<ffffffff81395a58>] driver_register+0x98/0x140 [ 91.514885] [<ffffffff813ea06c>] usb_register_driver+0xdc/0x1a0 [ 91.514885] [<ffffffffa0248023>] 0xffffffffa0248023 [ 91.514885] [<ffffffff810001dc>] do_one_initcall+0x3c/0x1d0 [ 91.514885] [<ffffffff81092d75>] sys_init_module+0xe5/0x250 [ 91.514885] [<ffffffff81002adb>] system_call_fastpath+0x16/0x1b [ 91.514885] [ 91.514885] -> #0 (&dev->lock){+.+.+.}: [ 91.514885] [<ffffffff81083668>] __lock_acquire+0x1418/0x1550 [ 91.514885] [<ffffffff8108383c>] lock_acquire+0x9c/0x140 [ 91.514885] [<ffffffff814b96c1>] __mutex_lock_common+0x61/0x610 [ 91.514885] [<ffffffff814b9d53>] mutex_lock_nested+0x43/0x50 [ 91.514885] [<ffffffffa02797f1>] snd_em28xx_capture_open+0x61/0x190 [em28xx_alsa] [ 91.514885] [<ffffffffa010adee>] snd_pcm_open_substream+0x4e/0x90 [snd_pcm] [ 91.514885] [<ffffffffa010ece9>] snd_pcm_open+0x199/0x450 [snd_pcm] [ 91.514885] [<ffffffffa010efd4>] snd_pcm_capture_open+0x34/0x40 [snd_pcm] [ 91.514885] [<ffffffffa00c5778>] snd_open+0x198/0x4e0 [snd] [ 91.514885] [<ffffffff8112384d>] chrdev_open+0x17d/0x320 [ 91.514885] [<ffffffff8111d358>] __dentry_open+0x1a8/0x400 [ 91.514885] [<ffffffff8111d6b4>] nameidata_to_filp+0x54/0x70 [ 91.514885] [<ffffffff8112e7f1>] do_filp_open+0x841/0xc00 [ 91.514885] [<ffffffff8111e954>] do_sys_open+0xa4/0x180 [ 91.514885] [<ffffffff8111ea70>] sys_open+0x20/0x30 [ 91.514885] [<ffffffff81002adb>] system_call_fastpath+0x16/0x1b [ 91.514885] [ 91.514885] other info that might help us debug this: [ 91.514885] [ 91.514885] 1 lock held by pulseaudio/2717: [ 91.514885] #0: (&pcm->open_mutex){+.+.+.}, at: [<ffffffffa010ecd2>] snd_pcm_open+0x182/0x450 [snd_pcm] [ 91.514885] [ 91.514885] stack backtrace: [ 91.514885] Pid: 2717, comm: pulseaudio Not tainted 2.6.33-rc8-crc #106 [ 91.514885] Call Trace: [ 91.514885] [<ffffffff81080fd9>] print_circular_bug+0xe9/0xf0 [ 91.514885] [<ffffffff81083668>] __lock_acquire+0x1418/0x1550 [ 91.514885] [<ffffffff81081dc8>] ? debug_check_no_locks_freed+0xc8/0x150 [ 91.514885] [<ffffffff8108383c>] lock_acquire+0x9c/0x140 [ 91.514885] [<ffffffffa02797f1>] ? snd_em28xx_capture_open+0x61/0x190 [em28xx_alsa] [ 91.514885] [<ffffffff814b96c1>] __mutex_lock_common+0x61/0x610 [ 91.514885] [<ffffffffa02797f1>] ? snd_em28xx_capture_open+0x61/0x190 [em28xx_alsa] [ 91.514885] [<ffffffffa02797f1>] ? snd_em28xx_capture_open+0x61/0x190 [em28xx_alsa] [ 91.514885] [<ffffffffa0109c70>] ? snd_pcm_hw_rule_muldivk+0x0/0xa0 [snd_pcm] [ 91.514885] [<ffffffff8107fd54>] ? lockdep_init_map+0x44/0x130 [ 91.514885] [<ffffffff814b9d53>] mutex_lock_nested+0x43/0x50 [ 91.514885] [<ffffffffa02797f1>] snd_em28xx_capture_open+0x61/0x190 [em28xx_alsa] [ 91.514885] [<ffffffffa010adee>] snd_pcm_open_substream+0x4e/0x90 [snd_pcm] [ 91.514885] [<ffffffffa010ece9>] snd_pcm_open+0x199/0x450 [snd_pcm] [ 91.514885] [<ffffffff81081cfd>] ? trace_hardirqs_on+0xd/0x10 [ 91.514885] [<ffffffff810434f0>] ? default_wake_function+0x0/0x20 [ 91.514885] [<ffffffff814b965e>] ? mutex_unlock+0xe/0x10 [ 91.514885] [<ffffffffa010efd4>] snd_pcm_capture_open+0x34/0x40 [snd_pcm] [ 91.514885] [<ffffffffa00c5778>] snd_open+0x198/0x4e0 [snd] [ 91.514885] [<ffffffff8112384d>] chrdev_open+0x17d/0x320 [ 91.514885] [<ffffffff8111d358>] __dentry_open+0x1a8/0x400 [ 91.514885] [<ffffffff811236d0>] ? chrdev_open+0x0/0x320 [ 91.514885] [<ffffffff8111d6b4>] nameidata_to_filp+0x54/0x70 [ 91.514885] [<ffffffff8112e7f1>] do_filp_open+0x841/0xc00 [ 91.514885] [<ffffffff814bf981>] ? sub_preempt_count+0x51/0x60 [ 91.514885] [<ffffffff814bbb7c>] ? _raw_spin_unlock+0x5c/0x70 [ 91.514885] [<ffffffff8111e954>] do_sys_open+0xa4/0x180 [ 91.514885] [<ffffffff8111ea70>] sys_open+0x20/0x30 [ 91.514885] [<ffffffff81002adb>] system_call_fastpath+0x16/0x1b [ 92.643423] hda-intel: IRQ timing workaround is activated for card #0. Suggest a bigger bdl_pos_adj.

2 12

[alsa-devel] ASoC updates for 2.6.34
by Mark Brown 17 Feb '10

17 Feb '10

The following changes since commit 7833ae0edf50b0eb303e95b1bec5fbd63a1e2672: Peter Ujfalusi (1): ASoC: tlv320dac33: Correct the OSCSET calculation are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound-2.6.git for-2.6.34 Mark Brown (1): ASoC: Make pmdown_time a long Peter Ujfalusi (1): ASoC: TWL4030: Use codec defaults for Headset initial configuration include/sound/soc.h | 2 +- sound/soc/codecs/twl4030.c | 4 ++-- sound/soc/soc-core.c | 2 +- 3 files changed, 4 insertions(+), 4 deletions(-)

2 1

[PATCH] ALSA: usbaudio Mbox support, output only
by Chris J Arges 17 Feb '10

17 Feb '10

Signed-off-by: Chris J Arges <christopherarges(a)gmail.com> --- sound/usb/usbquirks.h | 45 +++++++++++++++++++++++++++++++++++++++++++++ 1 files changed, 45 insertions(+), 0 deletions(-) diff --git a/sound/usb/usbquirks.h b/sound/usb/usbquirks.h index e691eba..14552d2 100644 --- a/sound/usb/usbquirks.h +++ b/sound/usb/usbquirks.h @@ -2215,6 +2215,51 @@ YAMAHA_DEVICE(0x7010, "UB99"), } }, +/* Digidesign Mbox */ +{ + /* Thanks to Clemens Ladisch <clemens(a)ladisch.de> */ + USB_DEVICE(0x0dba, 0x1000), + .driver_info = (unsigned long) &(const struct snd_usb_audio_quirk) { + .vendor_name = "Digidesign", + .product_name = "MBox", + .ifnum = QUIRK_ANY_INTERFACE, + .type = QUIRK_COMPOSITE, + .data = (const struct snd_usb_audio_quirk[]){ + { + .ifnum = 0, + .type = QUIRK_IGNORE_INTERFACE, + }, + { + .ifnum = 1, + .type = QUIRK_AUDIO_FIXED_ENDPOINT, + .data = &(const struct audioformat) { + .format = SNDRV_PCM_FORMAT_S24_3BE, + .channels = 2, + .iface = 1, + .altsetting = 1, + .altset_idx = 1, + .attributes = EP_CS_ATTR_SAMPLE_RATE, + .endpoint = 0x02, + .ep_attr = 0x01, + .maxpacksize = 0x130, + .rates = SNDRV_PCM_RATE_44100 | + SNDRV_PCM_RATE_48000, + .rate_min = 44100, + .rate_max = 48000, + .nr_rates = 2, + .rate_table = (unsigned int[]) { + 44100, 48000 + } + } + }, + { + .ifnum = -1 + } + } + + } +}, + { /* * Some USB MIDI devices don't have an audio control interface, -- 1.6.3.3 --=-g9t4QPaQL9hW42/Pyv3o--

1 0

[alsa-devel] What is the required accuracy of audio sampling rate?
by Yiliang Bao 17 Feb '10

17 Feb '10

Hi, I have a PCI-e audio card that does not give very accurate sampling rate (about -0.2% error, i.e., if I set the sampling rate to 8K, I got only 7984 samples per second on average). It caused various synchronization problems in applications like gstreamer. Since there will be some difference from one clock domain to another, I am wondering if there is any defined tolerance on the sampling rate, and where the right place is to correct this kind of error. I would really appreciate if someone can point me to the related documents/links. Thanks, Yiliang

4 4

[alsa-devel] [PATCH] Echoaudio, fix Guru Meditation #00000005.48454C50
by Giuliano Pochini 17 Feb '10

17 Feb '10

(resend: I mistyped the list address) There is a small window between the hw_params() callback and when runtime->frame_bits is set by ALSA middle layer. When another substream is already running, if an interrupt is delivered during that window the irq handler calls pcm_pointer() which does a division by zero. The patch below makes the irq handler skip substreams that are initialized but not started yet. Cc to Clemens Ladisch because he proposed an alternate fix. For more information, please read the original thread in the linux-kernel mailing list: http://lkml.org/lkml/2010/2/2/187 Short description: This patch fixes a division by zero error in the irq handler. Signed-off-by: Giuliano Pochini <pochini(a)shiny.it> --- alsa-driver-1.0.22.1/alsa-kernel/pci/echoaudio/echoaudio.c__orig 2010-02-16 22:21:36.000000000 +0100 +++ alsa-driver-1.0.22.1/alsa-kernel/pci/echoaudio/echoaudio.c 2010-02-16 22:21:45.000000000 +0100 @@ -1864,7 +1864,9 @@ static irqreturn_t snd_echo_interrupt(in /* The hardware doesn't tell us which substream caused the irq, thus we have to check all running substreams. */ for (ss = 0; ss < DSP_MAXPIPES; ss++) { - if ((substream = chip->substream[ss])) { + substream = chip->substream[ss]; + if (substream && ((struct audiopipe *)substream->runtime-> + private_data)->state == PIPE_STATE_STARTED) { period = pcm_pointer(substream) / substream->runtime->period_size; if (period != chip->last_period[ss]) { -- Giuliano.

2 1

[alsa-devel] [PATCH] ASoC: TWL4030: Use codec defaults for Headset initial configuration
by Peter Ujfalusi 17 Feb '10

17 Feb '10

Disable the amplifiers for the headset outputs, and do not select routings by default to the headset outputs. Signed-off-by: Peter Ujfalusi <peter.ujfalusi(a)nokia.com> --- The obvious side effect of this patch is that on boards which are using the headset output the playback will not work 'out of box'. The user need to specifically enable the routings for the boards. Board that came to my mind is the Beagle, and probably it's clones as well. sound/soc/codecs/twl4030.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/sound/soc/codecs/twl4030.c b/sound/soc/codecs/twl4030.c index 277862e..6f5d4af 100644 --- a/sound/soc/codecs/twl4030.c +++ b/sound/soc/codecs/twl4030.c @@ -75,8 +75,8 @@ static const u8 twl4030_reg[TWL4030_CACHEREGNUM] = { 0x00, /* REG_BTPGA (0x1F) */ 0x00, /* REG_BTSTPGA (0x20) */ 0x00, /* REG_EAR_CTL (0x21) */ - 0x24, /* REG_HS_SEL (0x22) */ - 0x0a, /* REG_HS_GAIN_SET (0x23) */ + 0x00, /* REG_HS_SEL (0x22) */ + 0x00, /* REG_HS_GAIN_SET (0x23) */ 0x00, /* REG_HS_POPN_SET (0x24) */ 0x00, /* REG_PREDL_CTL (0x25) */ 0x00, /* REG_PREDR_CTL (0x26) */ -- 1.7.0

3 2

[alsa-devel] Is Intel 82801G (ICH7 family) with VIA VT1708B 8-Ch supported?
by Zaar Hai 17 Feb '10

17 Feb '10

Good day, dear ALSA developers! I've got several boards based on Intel G41 chipset, which has ICH7 south bridge with VT1708B codec on it. While VT1708B seems to be supported since 2007, on all my computers the card is recognized, but mixer does not work: $ alsamixer alsamixer: function snd_mixer_load failed: Invalid argument I've tried it on Debian, OpenSuse and Ubuntu (including nightly builds), both 32 and 64 bit version, on 4 computers (all have the same hardware) - result is the same: card recognized, sound is played, but mixer (volume channels, etc.) does not. So, I've thought, that since G41 is rather new, may be this ICH7 with VT1708B combo is not supported by alsa yet? [1]. http://pastebin.com/m50dcbff0 - contents of /proc/asound/card0/codec#0 [2]. http://pastebin.com/m42320afc - lspci output [3]. http://pastebin.com/m443eaa12 - aplay -l output P.S. If you think this message rather belongs to users and not devel list, just tell me to go there. I've just thought that supported/not supported question should better be asked devel list. -- Zaar

1 1

[alsa-devel] Understanding SND_PCM_INFO_ [BATCH, BLOCK_TRANSFER, DOUBLE]
by Eliot Blennerhassett 17 Feb '10

17 Feb '10

I've been looking at these info flags, and whether they cause the driver to be accessed any differently by the upper layers. So far I can find hardly any examples where they are used in any significant way - what am I missing if anything? SND_/SNDRV_ _PCM_INFO_BATCH double buffering skips the check enabled by XRUN_DEBUG_JIFFIESCHECK alsa-lib returns it in snd_pcm_hw_params_is_batch() _PCM_INFO_BLOCK_TRANSFER /* hardware transfer block of samples */ translated by pcm_oss.c into ~DSP_CAP_REALTIME lib: snd_pcm_hw_params_is_block_transfer() _PCM_INFO_DOUBLE /* double buffering needed for PCM start/stop */ snd_pcm_hw_params_is_double() I don't see any of these functions called by aplay... -- Eliot

1 0

[alsa-devel] ASoC updates for 2.6.34
by Mark Brown 16 Feb '10

16 Feb '10

The following changes since commit 3a66d3877eaa4ab9818000a15c07326adaa9ca79: Mark Brown (1): ASoC: Add WM2000 driver are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound-2.6.git for-2.6.34 Mark Brown (2): ASoC: Make pmdown_time a per-card setting ASoC: Make pmdown_time runtime configurable Peter Ujfalusi (2): ASoC: tlv320dac33: Clearing FIFOFLUSH flag before playback ASoC: tlv320dac33: Correct the OSCSET calculation include/sound/soc.h | 2 ++ sound/soc/codecs/tlv320dac33.c | 5 ++++- sound/soc/soc-core.c | 31 ++++++++++++++++++++++++++++++- 3 files changed, 36 insertions(+), 2 deletions(-)

2 1

[alsa-devel] Strange behaviour in snd-usb-cayak with Audio4DJ
by Pedro Ribeiro 16 Feb '10

16 Feb '10

Hi all, I'm trying to setup my Audio4DJ usb soundcard. It has 4 channels (2 stereo ones). ALSA information script output is here http://www.alsa-project.org/db/?f=fe4cc3eda2df49c6055f55d4cef935524124d1a1 and my .asoundrc is here http://pastebin.com/m3f70572d Currently my .asoundrc has 4 devices: - Audio4DJ_A (combines channels 1 and 2) - Audio4DJ_B (combines channels 3 and 4) - Audio4DJ (combines Audio4DJ_A and Audio4DJ_B) - ttable is a device for JACK according to this http://alsa-project.org/main/index.php/Asoundrc#Virtual_multi_channel_devic… My goal is to have a separate ALSA soundcard for each pair of channels, an ALSA soundcard for 4 channels and a JACK device for all 4 channels. Running speaker-test -c2 -D plughw:Audio4DJ,0,X -twav -l1 with X=0 and X=1 correctly outputs to each channel. Also, pcm.Audio4DJ_A and pcm.Audio4DJ_B correctly work through both ALSA and JACK for each pair of channels. However, if I try to use the pcm.Audio4DJ (which combines both pcm.Audio4DJ_A and pcm.Audio4DJ_B), I get correct output through channels 1 and 2, but channels 3 and 4 have a lot of garbage - you can hear the track playing but it is at a very high pitch and distorted. JACK doesn't even start with the Audio4DJ device: # jackd -R --timeout 4500 -d alsa -d Audio4DJ -p 128 -n 3 -r 44100 -i 4 -o apparent rate = 44100 creating alsa driver ... Audio4DJ|Audio4DJ|128|3|44100|4|4|nomon|swmeter|-|32bit configuring for 44100Hz, period = 128 frames (2.9 ms), buffer = 3 periods ALSA: final selected sample format for capture: 32bit float little-endian ALSA: use 3 periods for capture ALSA: final selected sample format for playback: 32bit float little-endian ALSA: use 3 periods for playback ALSA: could not complete read of 0 frames: error = -32 cycle execution failure, exiting DRIVER NT: could not run driver cycle jack main caught signal 12 (crashes immediately) The ttable device locks up the system for a few seconds and then JACK crashes: # jackd -R --timeout 4500 -d alsa -d ttable -p 128 -n 3 -r 44100 -i 4 -o apparent rate = 44100 creating alsa driver ... ttable|ttable|128|3|44100|4|4|nomon|swmeter|-|32bit configuring for 44100Hz, period = 128 frames (2.9 ms), buffer = 3 periods ALSA: final selected sample format for capture: 32bit integer little-endian ALSA: use 3 periods for capture ALSA: final selected sample format for playback: 32bit integer little-endian ALSA: use 3 periods for playback jackd watchdog: timeout - killing jackd Without a .asoundrc it doesn't even work. Can someone please tell me if this is expected behaviour or a bug? Thanks, Pedro

2 3