* Opening dev/dsp takes very long @ 2004-03-13 20:01 Lars Heineken 2004-03-13 20:24 ` Additional info: " Lars Heineken 2004-03-15 10:35 ` Takashi Iwai 0 siblings, 2 replies; 17+ messages in thread From: Lars Heineken @ 2004-03-13 20:01 UTC (permalink / raw) To: alsa-devel -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi ! I switched from 2.4 to 2.6 a few days ago and noticed this strange problem. Whatever program uses OSS-emulation takes 1-3 seconds to open /dev/dsp and start playing sound. It seems that this has something to do with the preemptive kernel option, because I experienced the same when I tried a 2.4 kernel with the preemptive patch. I thought that having a prememtive kernel would reduce delays in general ~ and not increase them dramatically. How can I be of help to find and locate this problem ? Greetings, Lars. PS: Hardware is EWX24/96, if that helps. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFAU2iBrp9JEomxNXERAuAtAJ0SqH7CtAidytYox5ZmWw1gOfMIpACdHRf6 xJQw7Ug3+gvimU11ECwGY4c= =ko6Q -----END PGP SIGNATURE----- ------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click ^ permalink raw reply [flat|nested] 17+ messages in thread
* Additional info: Opening dev/dsp takes very long 2004-03-13 20:01 Opening dev/dsp takes very long Lars Heineken @ 2004-03-13 20:24 ` Lars Heineken 2004-03-15 10:35 ` Takashi Iwai 1 sibling, 0 replies; 17+ messages in thread From: Lars Heineken @ 2004-03-13 20:24 UTC (permalink / raw) Cc: alsa-devel -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 .. some more infos on the issue: - - The delay does not affect output via alsa directly, only the OSS-emulation. - - Using XMMS and jumping around in the song (via the main slider) creates the same delay every time the player jumps to the new position. - - Some applications suffer from more delay than others, the worst one is wavbreaker (3-4 seconds), it's barely usable. Lars. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFAU23grp9JEomxNXERAtzYAKCdWb4GWo9CO1m69V8Lid6qIscEbgCggOT8 5ZMWcX8TxhL5/AlFzCKHJJg= =e554 -----END PGP SIGNATURE----- ------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Opening dev/dsp takes very long 2004-03-13 20:01 Opening dev/dsp takes very long Lars Heineken 2004-03-13 20:24 ` Additional info: " Lars Heineken @ 2004-03-15 10:35 ` Takashi Iwai 2004-03-15 20:22 ` Lars Heineken 1 sibling, 1 reply; 17+ messages in thread From: Takashi Iwai @ 2004-03-15 10:35 UTC (permalink / raw) To: Lars Heineken; +Cc: alsa-devel At Sat, 13 Mar 2004 21:01:05 +0100, Lars Heineken wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi ! > > I switched from 2.4 to 2.6 a few days ago and noticed this strange > problem. Whatever program uses OSS-emulation takes 1-3 seconds to open > /dev/dsp and start playing sound. It seems that this has something to do > with the preemptive kernel option, because I experienced the same when I > tried a 2.4 kernel with the preemptive patch. > I thought that having a prememtive kernel would reduce delays in general > ~ and not increase them dramatically. > How can I be of help to find and locate this problem ? try strace with -r option and check which call takes too long time. Takashi ------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Opening dev/dsp takes very long 2004-03-15 10:35 ` Takashi Iwai @ 2004-03-15 20:22 ` Lars Heineken 2004-03-16 8:19 ` Clemens Ladisch 0 siblings, 1 reply; 17+ messages in thread From: Lars Heineken @ 2004-03-15 20:22 UTC (permalink / raw) To: alsa-devel -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Takashi Iwai wrote: | try strace with -r option and check which call takes too long time. I have tried to run the application with the longest delay (~5 seconds) using 'strace -r' wich is an X-application. Unfortunately, it spills out a lot of text (~2.8 MB). I guess you are not interested in that one. When I use the application 'play' the delay is only around one second, the strace output is attached below. Greetings, Lars. PS: The file I played is a wav-file containing _only a single sample_ to make sure playing of the file does not interfer with the time measurement. PPS: The longest time period is this line (~10 lines from the bottom up): 1.687172 rt_sigprocmask(SIG_SETMASK, [RTMIN], NULL, 8) = 0 When I monitor the sound while watching the strace output, I can see that line beeing written half way, than the delay, than the click of the soundcard, then the rest of the strace output. Attached strace output: [lars@lars-heineken CD-Recorder]$ strace -r play 01.wav ~ 0.000000 execve("/usr//bin/play", ["play", "01.wav"], [/* 52 vars */]) = 0 ~ 0.000676 uname({sys="Linux", node="lars-heineken.lan", ...}) = 0 ~ 0.000357 brk(0) = 0x80ea000 ~ 0.000233 old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40014000 ~ 0.000335 open("/etc/ld.so.preload", O_RDONLY) = -1 ENOENT (No such file or directory) ~ 0.000444 open("/etc/ld.so.cache", O_RDONLY) = 3 ~ 0.000295 fstat64(3, {st_mode=S_IFREG|0644, st_size=69759, ...}) = 0 ~ 0.000303 old_mmap(NULL, 69759, PROT_READ, MAP_PRIVATE, 3, 0) = 0x40015000 ~ 0.000279 close(3) = 0 ~ 0.000225 open("/lib/libtermcap.so.2", O_RDONLY) = 3 ~ 0.000338 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\260\r\0"..., 512) = 512 ~ 0.000353 fstat64(3, {st_mode=S_IFREG|0755, st_size=12112, ...}) = 0 ~ 0.000263 old_mmap(NULL, 15272, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x40027000 ~ 0.000275 old_mmap(0x4002a000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x2000) = 0x4002a000 ~ 0.000334 close(3) = 0 ~ 0.000245 open("/lib/libdl.so.2", O_RDONLY) = 3 ~ 0.000315 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\360\31"..., 512) = 512 ~ 0.000297 fstat64(3, {st_mode=S_IFREG|0755, st_size=9160, ...}) = 0 ~ 0.000275 old_mmap(NULL, 12008, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x4002b000 ~ 0.000272 old_mmap(0x4002d000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x1000) = 0x4002d000 ~ 0.000321 close(3) = 0 ~ 0.000220 open("/lib/i686/libc.so.6", O_RDONLY) = 3 ~ 0.000315 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\20]\1\000"..., 512) = 512 ~ 0.000291 fstat64(3, {st_mode=S_IFREG|0755, st_size=1237568, ...}) = 0 ~ 0.000263 old_mmap(NULL, 1242756, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x4002e000 ~ 0.000274 old_mmap(0x40158000, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x12a000) = 0x40158000 ~ 0.000352 old_mmap(0x4015b000, 9860, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x4015b000 ~ 0.000310 close(3) = 0 ~ 0.000254 old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x4015e000 ~ 0.001188 munmap(0x40015000, 69759) = 0 ~ 0.000772 rt_sigprocmask(SIG_BLOCK, NULL, [RTMIN], 8) = 0 ~ 0.000913 open("/dev/tty", O_RDWR|O_NONBLOCK|O_LARGEFILE) = 3 ~ 0.000488 close(3) = 0 ~ 0.000410 open("/usr/share/locale/locale-archive", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory) ~ 0.000526 brk(0) = 0x80ea000 ~ 0.000303 brk(0) = 0x80ea000 ~ 0.000269 brk(0x80eb000) = 0x80eb000 ~ 0.000317 brk(0) = 0x80eb000 ~ 0.000354 brk(0x80ec000) = 0x80ec000 ~ 0.000332 open("/usr/share/locale/locale.alias", O_RDONLY) = 3 ~ 0.000469 fstat64(3, {st_mode=S_IFREG|0644, st_size=2601, ...}) = 0 ~ 0.000341 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40015000 ~ 0.000334 read(3, "# Locale name alias data base.\n#"..., 4096) = 2601 ~ 0.000437 brk(0) = 0x80ec000 ~ 0.000274 brk(0x80ed000) = 0x80ed000 ~ 0.000324 brk(0) = 0x80ed000 ~ 0.000363 brk(0x80ee000) = 0x80ee000 ~ 0.000374 read(3, "", 4096) = 0 ~ 0.000294 close(3) = 0 ~ 0.000365 munmap(0x40015000, 4096) = 0 ~ 0.000362 open("/usr/share/locale/de_DE/LC_IDENTIFICATION", O_RDONLY) = 3 ~ 0.000456 fstat64(3, {st_mode=S_IFREG|0644, st_size=373, ...}) = 0 ~ 0.000330 mmap2(NULL, 373, PROT_READ, MAP_PRIVATE, 3, 0) = 0x40015000 ~ 0.000327 close(3) = 0 ~ 0.000323 open("/usr/share/locale/de_DE/LC_MEASUREMENT", O_RDONLY) = 3 ~ 0.000407 fstat64(3, {st_mode=S_IFREG|0644, st_size=29, ...}) = 0 ~ 0.000376 mmap2(NULL, 29, PROT_READ, MAP_PRIVATE, 3, 0) = 0x40016000 ~ 0.000343 close(3) = 0 ~ 0.000299 open("/usr/share/locale/de_DE/LC_TELEPHONE", O_RDONLY) = 3 ~ 0.000411 fstat64(3, {st_mode=S_IFREG|0644, st_size=62, ...}) = 0 ~ 0.000341 mmap2(NULL, 62, PROT_READ, MAP_PRIVATE, 3, 0) = 0x40017000 ~ 0.000308 close(3) = 0 ~ 0.000290 open("/usr/share/locale/de_DE/LC_ADDRESS", O_RDONLY) = 3 ~ 0.000418 fstat64(3, {st_mode=S_IFREG|0644, st_size=165, ...}) = 0 ~ 0.000321 mmap2(NULL, 165, PROT_READ, MAP_PRIVATE, 3, 0) = 0x40018000 ~ 0.000452 close(3) = 0 ~ 0.000313 open("/usr/share/locale/de_DE/LC_NAME", O_RDONLY) = 3 ~ 0.000424 fstat64(3, {st_mode=S_IFREG|0644, st_size=88, ...}) = 0 ~ 0.000346 mmap2(NULL, 88, PROT_READ, MAP_PRIVATE, 3, 0) = 0x40019000 ~ 0.000313 close(3) = 0 ~ 0.000292 open("/usr/share/locale/de_DE/LC_PAPER", O_RDONLY) = 3 ~ 0.000416 fstat64(3, {st_mode=S_IFREG|0644, st_size=40, ...}) = 0 ~ 0.000322 mmap2(NULL, 40, PROT_READ, MAP_PRIVATE, 3, 0) = 0x4001a000 ~ 0.000323 close(3) = 0 ~ 0.000310 open("/usr/share/locale/de_DE/LC_MESSAGES", O_RDONLY) = 3 ~ 0.000404 fstat64(3, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0 ~ 0.000319 close(3) = 0 ~ 0.000400 open("/usr/share/locale/de_DE/LC_MESSAGES/SYS_LC_MESSAGES", O_RDONLY) = 3 ~ 0.000418 fstat64(3, {st_mode=S_IFREG|0644, st_size=60, ...}) = 0 ~ 0.000338 mmap2(NULL, 60, PROT_READ, MAP_PRIVATE, 3, 0) = 0x4001b000 ~ 0.000314 close(3) = 0 ~ 0.000299 open("/usr/share/locale/de_DE/LC_MONETARY", O_RDONLY) = 3 ~ 0.000421 fstat64(3, {st_mode=S_IFREG|0644, st_size=292, ...}) = 0 ~ 0.000320 mmap2(NULL, 292, PROT_READ, MAP_PRIVATE, 3, 0) = 0x4001c000 ~ 0.000309 close(3) = 0 ~ 0.000309 open("/usr/share/locale/de_DE/LC_COLLATE", O_RDONLY) = 3 ~ 0.000437 fstat64(3, {st_mode=S_IFREG|0644, st_size=22592, ...}) = 0 ~ 0.000325 mmap2(NULL, 22592, PROT_READ, MAP_PRIVATE, 3, 0) = 0x4001d000 ~ 0.000402 close(3) = 0 ~ 0.000313 open("/usr/share/locale/de_DE/LC_TIME", O_RDONLY) = 3 ~ 0.000407 fstat64(3, {st_mode=S_IFREG|0644, st_size=2349, ...}) = 0 ~ 0.000343 mmap2(NULL, 2349, PROT_READ, MAP_PRIVATE, 3, 0) = 0x40023000 ~ 0.000314 close(3) = 0 ~ 0.000348 open("/usr/share/locale/de_DE/LC_NUMERIC", O_RDONLY) = 3 ~ 0.053354 fstat64(3, {st_mode=S_IFREG|0644, st_size=60, ...}) = 0 ~ 0.000619 mmap2(NULL, 60, PROT_READ, MAP_PRIVATE, 3, 0) = 0x40024000 ~ 0.000352 close(3) = 0 ~ 0.000329 open("/usr/share/locale/de_DE/LC_CTYPE", O_RDONLY) = 3 ~ 0.000485 fstat64(3, {st_mode=S_IFREG|0644, st_size=207996, ...}) = 0 ~ 0.000395 mmap2(NULL, 207996, PROT_READ, MAP_PRIVATE, 3, 0) = 0x4015f000 ~ 0.000329 close(3) = 0 ~ 0.000372 getuid32() = 501 ~ 0.000377 getgid32() = 501 ~ 0.000277 geteuid32() = 501 ~ 0.000281 getegid32() = 501 ~ 0.000285 rt_sigprocmask(SIG_BLOCK, NULL, [RTMIN], 8) = 0 ~ 0.000336 time(NULL) = 1079381623 ~ 0.000354 brk(0) = 0x80ee000 ~ 0.000284 brk(0x80ef000) = 0x80ef000 ~ 0.000399 open("/etc/mtab", O_RDONLY) = 3 ~ 0.000473 fstat64(3, {st_mode=S_IFREG|0644, st_size=1054, ...}) = 0 ~ 0.000334 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40192000 ~ 0.000336 read(3, "/dev/ide/host0/bus1/target0/lun0"..., 4096) = 1054 ~ 0.000447 close(3) = 0 ~ 0.000343 munmap(0x40192000, 4096) = 0 ~ 0.000295 open("/proc/meminfo", O_RDONLY) = 3 ~ 0.000477 fstat64(3, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0 ~ 0.000320 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40192000 ~ 0.000352 read(3, "MemTotal: 579664 kB\nMemFre"..., 1024) = 572 ~ 0.000423 close(3) = 0 ~ 0.000485 munmap(0x40192000, 4096) = 0 ~ 0.000301 brk(0) = 0x80ef000 ~ 0.000266 brk(0x80f0000) = 0x80f0000 ~ 0.000770 rt_sigaction(SIGCHLD, {SIG_DFL}, {SIG_DFL}, 8) = 0 ~ 0.000416 rt_sigaction(SIGCHLD, {SIG_DFL}, {SIG_DFL}, 8) = 0 ~ 0.000318 rt_sigaction(SIGINT, {SIG_DFL}, {SIG_DFL}, 8) = 0 ~ 0.000295 rt_sigaction(SIGINT, {SIG_DFL}, {SIG_DFL}, 8) = 0 ~ 0.000290 rt_sigaction(SIGQUIT, {SIG_DFL}, {SIG_DFL}, 8) = 0 ~ 0.000310 rt_sigaction(SIGQUIT, {SIG_DFL}, {SIG_DFL}, 8) = 0 ~ 0.000315 rt_sigprocmask(SIG_BLOCK, NULL, [RTMIN], 8) = 0 ~ 0.000382 rt_sigaction(SIGQUIT, {SIG_IGN}, {SIG_DFL}, 8) = 0 ~ 0.000491 uname({sys="Linux", node="lars-heineken.lan", ...}) = 0 ~ 0.000509 brk(0) = 0x80f0000 ~ 0.000304 brk(0x80f1000) = 0x80f1000 ~ 0.000314 brk(0) = 0x80f1000 ~ 0.000275 brk(0x80f2000) = 0x80f2000 ~ 0.000316 brk(0) = 0x80f2000 ~ 0.000291 brk(0x80f3000) = 0x80f3000 ~ 0.000316 stat64("/home/lars/win_e/CD-Recorder", {st_mode=S_IFDIR|0777, st_size=4096, ...}) = 0 ~ 0.000661 stat64(".", {st_mode=S_IFDIR|0777, st_size=4096, ...}) = 0 ~ 0.000452 getpid() = 7538 ~ 0.000339 getppid() = 7537 ~ 0.000398 brk(0) = 0x80f3000 ~ 0.000363 brk(0x80f4000) = 0x80f4000 ~ 0.000334 getpgrp() = 7537 ~ 0.000291 rt_sigaction(SIGCHLD, {0x80776a0, [], SA_RESTORER, 0x40056ca8}, {SIG_DFL}, 8) = 0 ~ 0.000389 rt_sigprocmask(SIG_BLOCK, NULL, [RTMIN], 8) = 0 ~ 0.000352 open("/usr//bin/play", O_RDONLY|O_LARGEFILE) = 3 ~ 0.000443 ioctl(3, SNDCTL_TMR_TIMEBASE, 0xbffff4d0) = -1 ENOTTY (Inappropriate ioctl for device) ~ 0.000394 _llseek(3, 0, [0], SEEK_CUR) = 0 ~ 0.000306 read(3, "#!/bin/sh\n# Shell script to play"..., 80) = 80 ~ 0.000329 _llseek(3, 0, [0], SEEK_SET) = 0 ~ 0.000281 getrlimit(RLIMIT_NOFILE, {rlim_cur=1024, rlim_max=1024}) = 0 ~ 0.000339 dup2(3, 255) = 255 ~ 0.000278 close(3) = 0 ~ 0.000360 fcntl64(255, F_SETFD, FD_CLOEXEC) = 0 ~ 0.000302 fcntl64(255, F_GETFL) = 0x8000 (flags O_RDONLY|O_LARGEFILE) ~ 0.000311 fstat64(255, {st_mode=S_IFREG|0755, st_size=5253, ...}) = 0 ~ 0.000326 _llseek(255, 0, [0], SEEK_CUR) = 0 ~ 0.000294 brk(0) = 0x80f4000 ~ 0.000266 brk(0x80f6000) = 0x80f6000 ~ 0.000310 brk(0) = 0x80f6000 ~ 0.000271 brk(0x80f7000) = 0x80f7000 ~ 0.000332 rt_sigprocmask(SIG_BLOCK, NULL, [RTMIN], 8) = 0 ~ 0.000334 read(255, "#!/bin/sh\n# Shell script to play"..., 5253) = 5253 ~ 0.000382 open("/usr/lib/gconv/gconv-modules.cache", O_RDONLY) = 3 ~ 0.000537 fstat64(3, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0 ~ 0.000328 close(3) = 0 ~ 0.000362 open("/usr/lib/gconv/gconv-modules", O_RDONLY) = 3 ~ 0.000395 fstat64(3, {st_mode=S_IFREG|0644, st_size=46058, ...}) = 0 ~ 0.000320 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40192000 ~ 0.000358 read(3, "# GNU libc iconv configuration.\n"..., 4096) = 4096 ~ 0.000501 brk(0) = 0x80f7000 ~ 0.000298 brk(0x80f8000) = 0x80f8000 ~ 0.000373 read(3, ".B1.002//\nalias\tJS//\t\t\tJUS_I.B1."..., 4096) = 4096 ~ 0.000356 brk(0) = 0x80f8000 ~ 0.000354 brk(0x80f9000) = 0x80f9000 ~ 0.000494 brk(0) = 0x80f9000 ~ 0.000285 brk(0x80fa000) = 0x80fa000 ~ 0.000406 brk(0) = 0x80fa000 ~ 0.000275 brk(0x80fb000) = 0x80fb000 ~ 0.000378 read(3, "859-3\t1\nmodule\tINTERNAL\t\tISO-885"..., 4096) = 4096 ~ 0.000401 brk(0) = 0x80fb000 ~ 0.000272 brk(0x80fc000) = 0x80fc000 ~ 0.000410 brk(0) = 0x80fc000 ~ 0.000280 brk(0x80fd000) = 0x80fd000 ~ 0.000394 brk(0) = 0x80fd000 ~ 0.000294 brk(0x80fe000) = 0x80fe000 ~ 0.000361 read(3, "9-14//\nalias\tLATIN8//\t\tISO-8859-"..., 4096) = 4096 ~ 0.000458 brk(0) = 0x80fe000 ~ 0.000301 brk(0x80ff000) = 0x80ff000 ~ 0.000412 brk(0) = 0x80ff000 ~ 0.000281 brk(0x8100000) = 0x8100000 ~ 0.000427 brk(0) = 0x8100000 ~ 0.000278 brk(0x8101000) = 0x8101000 ~ 0.000318 read(3, "ICESA//\t\tEBCDIC-ES-A//\nmodule\tEB"..., 4096) = 4096 ~ 0.000487 brk(0) = 0x8101000 ~ 0.000272 brk(0x8102000) = 0x8102000 ~ 0.000432 brk(0) = 0x8102000 ~ 0.000280 brk(0x8103000) = 0x8103000 ~ 0.000476 read(3, "dule\t\tcost\nalias\tCP285//\t\t\tIBM28"..., 4096) = 4096 ~ 0.000407 brk(0) = 0x8103000 ~ 0.000273 brk(0x8104000) = 0x8104000 ~ 0.000421 brk(0) = 0x8104000 ~ 0.000295 brk(0x8105000) = 0x8105000 ~ 0.040093 brk(0) = 0x8105000 ~ 0.000583 brk(0x8106000) = 0x8106000 ~ 0.000473 read(3, "5//\t\t\tIBM865//\nalias\tCSIBM865//\t"..., 4096) = 4096 ~ 0.000385 brk(0) = 0x8106000 ~ 0.000287 brk(0x8107000) = 0x8107000 ~ 0.000452 brk(0) = 0x8107000 ~ 0.000357 brk(0x8108000) = 0x8108000 ~ 0.000932 brk(0) = 0x8108000 ~ 0.000332 brk(0x8109000) = 0x8109000 ~ 0.000449 read(3, "IBM939\t\t1\nmodule\tINTERNAL\t\tIBM93"..., 4096) = 4096 ~ 0.000414 brk(0) = 0x8109000 ~ 0.000306 brk(0x810a000) = 0x810a000 ~ 0.000450 brk(0) = 0x810a000 ~ 0.000294 brk(0x810b000) = 0x810b000 ~ 0.000472 brk(0) = 0x810b000 ~ 0.000287 brk(0x810c000) = 0x810c000 ~ 0.000430 read(3, "s\tGB13000//\t\tGBK//\nalias\tCP936//"..., 4096) = 4096 ~ 0.000403 brk(0) = 0x810c000 ~ 0.000279 brk(0x810d000) = 0x810d000 ~ 0.000560 brk(0) = 0x810d000 ~ 0.000287 brk(0x810e000) = 0x810e000 ~ 0.000517 brk(0) = 0x810e000 ~ 0.000291 brk(0x810f000) = 0x810f000 ~ 0.000389 read(3, "//\tANSI_X3.110//\nalias\tISO-IR-99"..., 4096) = 4096 ~ 0.000492 brk(0) = 0x810f000 ~ 0.000275 brk(0x8110000) = 0x8110000 ~ 0.000502 brk(0) = 0x8110000 ~ 0.000286 brk(0x8111000) = 0x8111000 ~ 0.000533 read(3, "\t\tcost\nalias\tMS-MAC-CYRILLIC//\tC"..., 4096) = 4096 ~ 0.000377 brk(0) = 0x8111000 ~ 0.000267 brk(0x8112000) = 0x8112000 ~ 0.000595 brk(0) = 0x8112000 ~ 0.000300 brk(0x8113000) = 0x8113000 ~ 0.000536 brk(0) = 0x8113000 ~ 0.000285 brk(0x8114000) = 0x8114000 ~ 0.000455 read(3, "\tto\t\t\tmodule\t\tcost\nalias\tPT-CP15"..., 4096) = 1002 ~ 0.000487 brk(0) = 0x8114000 ~ 0.000280 brk(0x8115000) = 0x8115000 ~ 0.000353 read(3, "", 4096) = 0 ~ 0.000306 close(3) = 0 ~ 0.000350 munmap(0x40192000, 4096) = 0 ~ 0.000727 open("/usr/lib/gconv/ISO8859-15.so", O_RDONLY) = 3 ~ 0.000486 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\20\6\0"..., 512) = 512 ~ 0.000482 fstat64(3, {st_mode=S_IFREG|0755, st_size=6932, ...}) = 0 ~ 0.000339 brk(0) = 0x8115000 ~ 0.000268 brk(0x8116000) = 0x8116000 ~ 0.000319 old_mmap(NULL, 9868, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x40192000 ~ 0.000346 old_mmap(0x40194000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x1000) = 0x40194000 ~ 0.000388 close(3) = 0 ~ 0.000531 rt_sigprocmask(SIG_BLOCK, NULL, [RTMIN], 8) = 0 ~ 0.000401 rt_sigprocmask(SIG_BLOCK, NULL, [RTMIN], 8) = 0 ~ 0.000343 rt_sigprocmask(SIG_BLOCK, NULL, [RTMIN], 8) = 0 ~ 0.000301 rt_sigprocmask(SIG_BLOCK, NULL, [RTMIN], 8) = 0 ~ 0.000319 rt_sigprocmask(SIG_BLOCK, NULL, [RTMIN], 8) = 0 ~ 0.000315 rt_sigprocmask(SIG_BLOCK, NULL, [RTMIN], 8) = 0 ~ 0.000325 rt_sigprocmask(SIG_BLOCK, NULL, [RTMIN], 8) = 0 ~ 0.000385 rt_sigprocmask(SIG_BLOCK, NULL, [RTMIN], 8) = 0 ~ 0.002773 rt_sigprocmask(SIG_BLOCK, NULL, [RTMIN], 8) = 0 ~ 0.000345 rt_sigprocmask(SIG_BLOCK, NULL, [RTMIN], 8) = 0 ~ 0.000302 rt_sigprocmask(SIG_BLOCK, NULL, [RTMIN], 8) = 0 ~ 0.000321 rt_sigprocmask(SIG_BLOCK, NULL, [RTMIN], 8) = 0 ~ 0.000303 rt_sigprocmask(SIG_BLOCK, NULL, [RTMIN], 8) = 0 ~ 0.000316 rt_sigprocmask(SIG_BLOCK, NULL, [RTMIN], 8) = 0 ~ 0.000321 rt_sigprocmask(SIG_BLOCK, NULL, [RTMIN], 8) = 0 ~ 0.000303 rt_sigprocmask(SIG_BLOCK, NULL, [RTMIN], 8) = 0 ~ 0.000458 rt_sigprocmask(SIG_BLOCK, NULL, [RTMIN], 8) = 0 ~ 0.000368 rt_sigprocmask(SIG_BLOCK, NULL, [RTMIN], 8) = 0 ~ 0.000367 rt_sigprocmask(SIG_BLOCK, NULL, [RTMIN], 8) = 0 ~ 0.000394 rt_sigprocmask(SIG_BLOCK, NULL, [RTMIN], 8) = 0 ~ 0.000336 rt_sigprocmask(SIG_BLOCK, NULL, [RTMIN], 8) = 0 ~ 0.000398 rt_sigprocmask(SIG_BLOCK, NULL, [RTMIN], 8) = 0 ~ 0.000407 brk(0) = 0x8116000 ~ 0.000295 brk(0x8117000) = 0x8117000 ~ 0.000380 rt_sigprocmask(SIG_BLOCK, NULL, [RTMIN], 8) = 0 ~ 0.000325 rt_sigprocmask(SIG_BLOCK, NULL, [RTMIN], 8) = 0 ~ 0.000472 brk(0) = 0x8117000 ~ 0.000316 brk(0x8118000) = 0x8118000 ~ 0.000314 pipe([3, 4]) = 0 ~ 0.000406 rt_sigprocmask(SIG_BLOCK, [INT CHLD], [RTMIN], 8) = 0 ~ 0.000445 _llseek(255, -4555, [698], SEEK_CUR) = 0 ~ 0.000311 fork() = 7539 ~ 0.048333 rt_sigprocmask(SIG_SETMASK, [RTMIN], NULL, 8) = 0 ~ 0.000438 --- SIGCHLD (Child exited) @ 0 (0) --- ~ 0.000288 waitpid(-1, [WIFEXITED(s) && WEXITSTATUS(s) == 0], WNOHANG) = 7539 ~ 0.000644 waitpid(-1, 0xbfffef1c, WNOHANG) = -1 ECHILD (No child processes) ~ 0.000321 sigreturn() = ? (mask now [RTMIN]) ~ 0.000337 rt_sigaction(SIGCHLD, {0x80776a0, [], SA_RESTORER, 0x40056ca8}, {0x80776a0, [], SA_RESTORER, 0x40056ca8}, 8) = 0 ~ 0.000382 close(4) = 0 ~ 0.000332 read(3, "play\n", 128) = 5 ~ 0.000305 read(3, "", 128) = 0 ~ 0.000337 close(3) = 0 ~ 0.000766 rt_sigprocmask(SIG_BLOCK, [CHLD], [RTMIN], 8) = 0 ~ 0.000347 rt_sigaction(SIGINT, {0x8076710, [], SA_RESTORER, 0x40056ca8}, {SIG_DFL}, 8) = 0 ~ 0.000364 rt_sigprocmask(SIG_SETMASK, [RTMIN], NULL, 8) = 0 ~ 0.000293 rt_sigaction(SIGINT, {SIG_DFL}, {0x8076710, [], SA_RESTORER, 0x40056ca8}, 8) = 0 ~ 0.000414 rt_sigprocmask(SIG_BLOCK, NULL, [RTMIN], 8) = 0 ~ 0.000332 read(255, "program_version=\"2.0\"\n\nif [ -z \""..., 5253) = 4555 ~ 0.000453 rt_sigprocmask(SIG_BLOCK, NULL, [RTMIN], 8) = 0 ~ 0.000322 rt_sigprocmask(SIG_BLOCK, NULL, [RTMIN], 8) = 0 ~ 0.000505 rt_sigprocmask(SIG_BLOCK, NULL, [RTMIN], 8) = 0 ~ 0.000356 rt_sigprocmask(SIG_SETMASK, [RTMIN], NULL, 8) = 0 ~ 0.000606 rt_sigprocmask(SIG_BLOCK, NULL, [RTMIN], 8) = 0 ~ 0.000324 rt_sigprocmask(SIG_BLOCK, NULL, [RTMIN], 8) = 0 ~ 0.000420 rt_sigprocmask(SIG_BLOCK, NULL, [RTMIN], 8) = 0 ~ 0.000324 rt_sigprocmask(SIG_BLOCK, NULL, [RTMIN], 8) = 0 ~ 0.000419 brk(0) = 0x8118000 ~ 0.000300 brk(0x8119000) = 0x8119000 ~ 0.000606 brk(0) = 0x8119000 ~ 0.000287 brk(0x811a000) = 0x811a000 ~ 0.000473 brk(0) = 0x811a000 ~ 0.000286 brk(0x811b000) = 0x811b000 ~ 0.000321 rt_sigprocmask(SIG_BLOCK, NULL, [RTMIN], 8) = 0 ~ 0.000314 rt_sigprocmask(SIG_BLOCK, NULL, [RTMIN], 8) = 0 ~ 0.000366 rt_sigprocmask(SIG_BLOCK, NULL, [RTMIN], 8) = 0 ~ 0.000332 rt_sigprocmask(SIG_BLOCK, NULL, [RTMIN], 8) = 0 ~ 0.000962 brk(0) = 0x811b000 ~ 0.000286 brk(0x811c000) = 0x811c000 ~ 0.000768 rt_sigprocmask(SIG_BLOCK, NULL, [RTMIN], 8) = 0 ~ 0.000388 rt_sigprocmask(SIG_SETMASK, [RTMIN], NULL, 8) = 0 ~ 0.000497 brk(0) = 0x811c000 ~ 0.000295 brk(0x811d000) = 0x811d000 ~ 0.000311 rt_sigprocmask(SIG_BLOCK, NULL, [RTMIN], 8) = 0 ~ 0.000306 rt_sigprocmask(SIG_SETMASK, [RTMIN], NULL, 8) = 0 ~ 0.000388 rt_sigprocmask(SIG_BLOCK, NULL, [RTMIN], 8) = 0 ~ 0.000384 rt_sigprocmask(SIG_SETMASK, [RTMIN], NULL, 8) = 0 ~ 0.000394 rt_sigprocmask(SIG_BLOCK, NULL, [RTMIN], 8) = 0 ~ 0.000395 rt_sigprocmask(SIG_BLOCK, NULL, [RTMIN], 8) = 0 ~ 0.000353 pipe([3, 4]) = 0 ~ 0.000366 rt_sigprocmask(SIG_BLOCK, [INT CHLD], [RTMIN], 8) = 0 ~ 0.000316 _llseek(255, -1305, [3948], SEEK_CUR) = 0 ~ 0.000286 fork() = 7540 ~ 0.007544 rt_sigprocmask(SIG_SETMASK, [RTMIN], NULL, 8) = 0 ~ 0.000426 --- SIGCHLD (Child exited) @ 0 (0) --- ~ 0.000320 waitpid(-1, [WIFEXITED(s) && WEXITSTATUS(s) == 0], WNOHANG) = 7540 ~ 0.000609 waitpid(-1, 0xbfffef1c, WNOHANG) = -1 ECHILD (No child processes) ~ 0.000344 sigreturn() = ? (mask now [RTMIN]) ~ 0.000318 rt_sigaction(SIGCHLD, {0x80776a0, [], SA_RESTORER, 0x40056ca8}, {0x80776a0, [], SA_RESTORER, 0x40056ca8}, 8) = 0 ~ 0.000381 close(4) = 0 ~ 0.000351 read(3, "Linux\n", 128) = 6 ~ 0.000290 read(3, "", 128) = 0 ~ 0.000262 close(3) = 0 ~ 0.000454 rt_sigprocmask(SIG_BLOCK, [CHLD], [RTMIN], 8) = 0 ~ 0.000310 rt_sigaction(SIGINT, {0x8076710, [], SA_RESTORER, 0x40056ca8}, {SIG_DFL}, 8) = 0 ~ 0.000338 rt_sigprocmask(SIG_SETMASK, [RTMIN], NULL, 8) = 0 ~ 0.000351 rt_sigaction(SIGINT, {SIG_DFL}, {0x8076710, [], SA_RESTORER, 0x40056ca8}, 8) = 0 ~ 0.000423 rt_sigprocmask(SIG_BLOCK, NULL, [RTMIN], 8) = 0 ~ 0.000380 read(255, "case $arch in\n SunOS)\n case "..., 5253) = 1305 ~ 0.000864 rt_sigprocmask(SIG_BLOCK, NULL, [RTMIN], 8) = 0 ~ 0.000387 rt_sigprocmask(SIG_SETMASK, [RTMIN], NULL, 8) = 0 ~ 0.000346 rt_sigprocmask(SIG_BLOCK, NULL, [RTMIN], 8) = 0 ~ 0.000378 rt_sigprocmask(SIG_BLOCK, NULL, [RTMIN], 8) = 0 ~ 0.000448 rt_sigprocmask(SIG_BLOCK, NULL, [RTMIN], 8) = 0 ~ 0.000323 rt_sigprocmask(SIG_BLOCK, NULL, [RTMIN], 8) = 0 ~ 0.000418 rt_sigprocmask(SIG_BLOCK, NULL, [RTMIN], 8) = 0 ~ 0.000323 rt_sigprocmask(SIG_SETMASK, [RTMIN], NULL, 8) = 0 ~ 0.000312 rt_sigprocmask(SIG_BLOCK, NULL, [RTMIN], 8) = 0 ~ 0.000323 rt_sigprocmask(SIG_BLOCK, NULL, [RTMIN], 8) = 0 ~ 0.000326 rt_sigprocmask(SIG_BLOCK, NULL, [RTMIN], 8) = 0 ~ 0.000371 rt_sigprocmask(SIG_BLOCK, NULL, [RTMIN], 8) = 0 ~ 0.000621 rt_sigprocmask(SIG_BLOCK, NULL, [RTMIN], 8) = 0 ~ 0.000326 rt_sigprocmask(SIG_SETMASK, [RTMIN], NULL, 8) = 0 ~ 0.000436 stat64(".", {st_mode=S_IFDIR|0777, st_size=4096, ...}) = 0 ~ 0.000505 stat64("/usr/bin/sox", {st_mode=S_IFREG|0755, st_size=253368, ...}) = 0 ~ 0.035709 getgroups32(0x20, 0x811c188) = 2 ~ 0.000567 stat64("/usr/bin/sox", {st_mode=S_IFREG|0755, st_size=253368, ...}) = 0 ~ 0.000536 brk(0) = 0x811d000 ~ 0.000278 brk(0x811e000) = 0x811e000 ~ 0.000334 rt_sigprocmask(SIG_BLOCK, [INT CHLD], [RTMIN], 8) = 0 ~ 0.000334 fork() = 7541 ~ 0.003752 rt_sigprocmask(SIG_SETMASK, [RTMIN], NULL, 8) = 0 ~ 0.000464 rt_sigprocmask(SIG_BLOCK, [CHLD], [RTMIN], 8) = 0 ~ 0.000332 rt_sigprocmask(SIG_SETMASK, [RTMIN], NULL, 8) = 0 ~ 0.000316 rt_sigprocmask(SIG_BLOCK, [CHLD], [RTMIN], 8) = 0 ~ 0.000507 rt_sigaction(SIGINT, {0x8076710, [], SA_RESTORER, 0x40056ca8}, {SIG_DFL}, 8) = 0 ~ 0.000702 waitpid(-1, [WIFEXITED(s) && WEXITSTATUS(s) == 0], 0) = 7541 ~ 1.687172 rt_sigprocmask(SIG_SETMASK, [RTMIN], NULL, 8) = 0 ~ 0.000440 --- SIGCHLD (Child exited) @ 0 (0) --- ~ 0.000234 waitpid(-1, 0xbffff11c, WNOHANG) = -1 ECHILD (No child processes) ~ 0.000334 sigreturn() = ? (mask now [RTMIN]) ~ 0.000386 rt_sigaction(SIGINT, {SIG_DFL}, {0x8076710, [], SA_RESTORER, 0x40056ca8}, 8) = 0 ~ 0.000386 rt_sigprocmask(SIG_BLOCK, NULL, [RTMIN], 8) = 0 ~ 0.000332 read(255, "", 5253) = 0 ~ 0.000400 exit_group(0) = ? [lars@lars-heineken CD-Recorder]$ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFAVhCPrp9JEomxNXERAk1lAJ48JO5HUnAkdxNYXsTGDEcoFkj9IwCeNmXr v82UOI+TpB5Armu6bqFZgAs= =N37X -----END PGP SIGNATURE----- ------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Opening dev/dsp takes very long 2004-03-15 20:22 ` Lars Heineken @ 2004-03-16 8:19 ` Clemens Ladisch 2004-03-16 8:49 ` Lars Heineken 0 siblings, 1 reply; 17+ messages in thread From: Clemens Ladisch @ 2004-03-16 8:19 UTC (permalink / raw) To: Lars Heineken; +Cc: alsa-devel Lars Heineken wrote: > Takashi Iwai wrote: > > | try strace with -r option and check which call takes too long time. > > When I use the application 'play' the delay is only around one second, > the strace output is attached below. It seems play is a shell script that calls sox to play the file. Please try to strace sox. Regards, Clemens ------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Opening dev/dsp takes very long 2004-03-16 8:19 ` Clemens Ladisch @ 2004-03-16 8:49 ` Lars Heineken 2004-03-16 19:04 ` Lars Heineken 2004-03-19 12:29 ` Lars Heineken 0 siblings, 2 replies; 17+ messages in thread From: Lars Heineken @ 2004-03-16 8:49 UTC (permalink / raw) To: alsa-devel Clemens Ladisch wrote: >It seems play is a shell script that calls sox to play the file. >Please try to strace sox. > > Oh, you are right ! I guess that was the reason why there was so little alsa related stuff in the trace.. I'll figure out how the script works and make the trace when I get home. (~9 hours). ------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Opening dev/dsp takes very long 2004-03-16 8:49 ` Lars Heineken @ 2004-03-16 19:04 ` Lars Heineken 2004-03-19 12:29 ` Lars Heineken 1 sibling, 0 replies; 17+ messages in thread From: Lars Heineken @ 2004-03-16 19:04 UTC (permalink / raw) To: alsa-devel -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Lars Heineken wrote: | I'll figure out how the script works and make the trace when I get home. | (~9 hours). All set, here we go: The script calls this line: sox 01.wav -t ossdsp /dev/dsp After adding an "strace -r" to the beginning I got the following output: lars@lars-heineken CD-Recorder]$ strace -r sox 01.wav -t ossdsp /dev/dsp ~ 0.000000 execve("/usr//bin/sox", ["sox", "01.wav", "-t", "ossdsp", "/dev/dsp"], [/* 52 vars */]) = 0 ~ 0.000836 uname({sys="Linux", node="lars-heineken.lan", ...}) = 0 ~ 0.000339 brk(0) = 0x80a5000 ~ 0.000234 old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40014000 ~ 0.000336 open("/etc/ld.so.preload", O_RDONLY) = -1 ENOENT (No such file or directory) ~ 0.000445 open("/etc/ld.so.cache", O_RDONLY) = 3 ~ 0.000288 fstat64(3, {st_mode=S_IFREG|0644, st_size=69759, ...}) = 0 ~ 0.000301 old_mmap(NULL, 69759, PROT_READ, MAP_PRIVATE, 3, 0) = 0x40015000 ~ 0.000319 close(3) = 0 ~ 0.000227 open("/lib/i686/libm.so.6", O_RDONLY) = 3 ~ 0.000325 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\0005\0"..., 512) = 512 ~ 0.000367 fstat64(3, {st_mode=S_IFREG|0755, st_size=139748, ...}) = 0 ~ 0.000264 old_mmap(NULL, 142224, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x40027000 ~ 0.000275 old_mmap(0x40049000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x21000) = 0x40049000 ~ 0.000352 close(3) = 0 ~ 0.000229 open("/usr/lib/libogg.so.0", O_RDONLY) = 3 ~ 0.000324 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0000\20\0"..., 512) = 512 ~ 0.000301 fstat64(3, {st_mode=S_IFREG|0755, st_size=14856, ...}) = 0 ~ 0.000278 old_mmap(NULL, 13820, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x4004a000 ~ 0.000271 old_mmap(0x4004d000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x3000) = 0x4004d000 ~ 0.000321 close(3) = 0 ~ 0.000236 open("/usr/lib/libvorbis.so.0", O_RDONLY) = 3 ~ 0.000323 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\220*\0"..., 512) = 512 ~ 0.000295 fstat64(3, {st_mode=S_IFREG|0755, st_size=131624, ...}) = 0 ~ 0.000259 old_mmap(NULL, 134692, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x4004e000 ~ 0.000290 old_mmap(0x40068000, 28672, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x19000) = 0x40068000 ~ 0.000322 close(3) = 0 ~ 0.000220 open("/usr/lib/libvorbisfile.so.3", O_RDONLY) = 3 ~ 0.000340 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\200\26"..., 512) = 512 ~ 0.000294 fstat64(3, {st_mode=S_IFREG|0755, st_size=23020, ...}) = 0 ~ 0.000260 old_mmap(NULL, 26024, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x4006f000 ~ 0.000269 old_mmap(0x40075000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x5000) = 0x40075000 ~ 0.000337 close(3) = 0 ~ 0.000218 open("/usr/lib/libvorbisenc.so.2", O_RDONLY) = 3 ~ 0.000313 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0@\202\0"..., 512) = 512 ~ 0.000322 fstat64(3, {st_mode=S_IFREG|0755, st_size=935152, ...}) = 0 ~ 0.000256 old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40076000 ~ 0.000306 old_mmap(NULL, 949284, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x40077000 ~ 0.000273 old_mmap(0x40082000, 892928, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0xb000) = 0x40082000 ~ 0.000670 old_mmap(0x4015c000, 11300, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x4015c000 ~ 0.000312 close(3) = 0 ~ 0.000268 open("/usr/lib/libmad.so.0", O_RDONLY) = 3 ~ 0.000346 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\340\24"..., 512) = 512 ~ 0.000370 fstat64(3, {st_mode=S_IFREG|0755, st_size=88120, ...}) = 0 ~ 0.000285 old_mmap(NULL, 91180, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x4015f000 ~ 0.000275 old_mmap(0x40175000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x15000) = 0x40175000 ~ 0.000329 close(3) = 0 ~ 0.000249 open("/lib/i686/libc.so.6", O_RDONLY) = 3 ~ 0.000300 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\20]\1\000"..., 512) = 512 ~ 0.000289 fstat64(3, {st_mode=S_IFREG|0755, st_size=1237568, ...}) = 0 ~ 0.000260 old_mmap(NULL, 1242756, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x40176000 ~ 0.000287 old_mmap(0x402a0000, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x12a000) = 0x402a0000 ~ 0.000340 old_mmap(0x402a3000, 9860, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x402a3000 ~ 0.000308 close(3) = 0 ~ 0.001777 munmap(0x40015000, 69759) = 0 ~ 0.001005 brk(0) = 0x80a5000 ~ 0.000365 brk(0x80c6000) = 0x80c6000 ~ 0.000290 brk(0) = 0x80c6000 ~ 0.000384 open("01.wav", O_RDONLY) = 3 ~ 0.000466 fstat64(3, {st_mode=S_IFREG|0777, st_size=96, ...}) = 0 ~ 0.000382 fstat64(3, {st_mode=S_IFREG|0777, st_size=96, ...}) = 0 ~ 0.000321 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40015000 ~ 0.000356 read(3, "RIFFX\0\0\0WAVEfmt \20\0\0\0\1\0\2\0D\254\0\0\20\261\2"..., 4096) = 96 ~ 0.000395 _llseek(3, 0, [0], SEEK_SET) = 0 ~ 0.000287 read(3, "RIFFX\0\0\0WAVEfmt \20\0\0\0\1\0\2\0D\254\0\0\20\261\2"..., 4096) = 96 ~ 0.000406 _llseek(3, 96, [96], SEEK_SET) = 0 ~ 0.000302 _llseek(3, 96, [96], SEEK_SET) = 0 ~ 0.000272 read(3, "", 4096) = 0 ~ 0.000329 _llseek(3, 0, [0], SEEK_SET) = 0 ~ 0.000275 read(3, "RIFFX\0\0\0WAVEfmt \20\0\0\0\1\0\2\0D\254\0\0\20\261\2"..., 44) = 44 ~ 0.000339 open("/dev/dsp", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 4 ~ 0.000624 fstat64(4, {st_mode=S_IFCHR|0600, st_rdev=makedev(14, 3), ...}) = 0 ~ 0.000347 ioctl(4, SNDCTL_TMR_TIMEBASE, 0xbffff4b0) = -1 EINVAL (Invalid argument) ~ 0.000363 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40016000 ~ 0.000325 fstat64(4, {st_mode=S_IFCHR|0600, st_rdev=makedev(14, 3), ...}) = 0 ~ 0.000347 ioctl(4, SNDCTL_DSP_RESET, 0) = 0 ~ 0.000348 ioctl(4, SNDCTL_DSP_GETFMTS, 0xbffff648) = 0 ~ 0.516952 ioctl(4, SNDCTL_DSP_SETFMT, 0xbffff648) = 0 ~ 0.002426 ioctl(4, SNDCTL_DSP_STEREO, 0xbffff648) = 0 ~ 0.002577 ioctl(4, SOUND_PCM_READ_RATE, 0xbffff648) = 0 ~ 0.135400 ioctl(4, SNDCTL_DSP_GETBLKSIZE, 0x80a5824) = 0 ~ 0.000339 ioctl(4, SNDCTL_DSP_SYNC, 0) = 0 ~ 0.000302 munmap(0x40016000, 4096) = 0 ~ 0.000325 read(3, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 8192) = 52 ~ 0.000365 read(3, "", 4096) = 0 ~ 0.000323 close(3) = 0 ~ 0.000398 munmap(0x40015000, 4096) = 0 ~ 0.000602 write(4, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 52) = 52 ~ 0.000422 close(4) = 0 ~ 0.148631 exit_group(0) = ? It seems SNDCTL_DSP_SETFMT is to blame, but SNDCTL_DSP_GETBLKSIZE takes rather long, too. Does anyone have a clue what might have caused these delays to appear in alsa 1.00 ? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFAV0+7rp9JEomxNXERAp1eAKCTMtv/Xvr4IN5apJRwP+JHOOvaSQCffueJ 1MQD3uNnsHE1jQzb/xDjfv4= =Yb/b -----END PGP SIGNATURE----- ------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Opening dev/dsp takes very long 2004-03-16 8:49 ` Lars Heineken 2004-03-16 19:04 ` Lars Heineken @ 2004-03-19 12:29 ` Lars Heineken 2004-03-19 21:58 ` Lars Heineken 1 sibling, 1 reply; 17+ messages in thread From: Lars Heineken @ 2004-03-19 12:29 UTC (permalink / raw) To: alsa-devel I really want to resolve this bug, but there has been little help so far. I haven't got any response from Perex, too. He was asigned to this bug via alsa bug report... Please, someone needs to tell me wich modules are connected with the functions that took so long, so I can check revision of tthe modules to find the cause of the delay. Additionally, could someone tell me how to get debug-output from alsa (Kernel 2.6) ? Regards, Lars. ------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Opening dev/dsp takes very long 2004-03-19 12:29 ` Lars Heineken @ 2004-03-19 21:58 ` Lars Heineken 2004-03-19 23:56 ` James Courtier-Dutton 0 siblings, 1 reply; 17+ messages in thread From: Lars Heineken @ 2004-03-19 21:58 UTC (permalink / raw) To: alsa-devel I used the latest alsa-tarballs to upgrade alsa-lib, alsa-driver and alsa-oss. To make it short: The problem is even worse now ! This is the output from strace (relevant part): . . 0.000531 ioctl(4, SNDCTL_DSP_RESET, 0) = 0 0.000232 ioctl(4, SNDCTL_DSP_GETFMTS, 0xbffff668) = 0 0.510506 ioctl(4, SNDCTL_DSP_SETFMT, 0xbffff668) = 0 0.506515 ioctl(4, SNDCTL_DSP_STEREO, 0xbffff668) = 0 0.504940 ioctl(4, SOUND_PCM_READ_RATE, 0xbffff668) = 0 0.065604 ioctl(4, SNDCTL_DSP_GETBLKSIZE, 0x80a5824) = 0 0.000302 ioctl(4, SNDCTL_DSP_SYNC, 0) = 0 0.000250 munmap(0x40016000, 4096) = 0 . . ..now it's not just a single call that takes too long, but _three_ of them. There has to be someone who nows about the changes made from the alsa used in 2.6.4 and the current release, this way we could probably locate the source for the _additional_ delay introduced, maybe that'll lead us to a solution for the whole issue ? ------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Opening dev/dsp takes very long 2004-03-19 21:58 ` Lars Heineken @ 2004-03-19 23:56 ` James Courtier-Dutton 2004-03-20 8:20 ` Lars Heineken 0 siblings, 1 reply; 17+ messages in thread From: James Courtier-Dutton @ 2004-03-19 23:56 UTC (permalink / raw) To: Lars Heineken; +Cc: alsa-devel Lars Heineken wrote: > I used the latest alsa-tarballs to upgrade alsa-lib, alsa-driver and > alsa-oss. > To make it short: The problem is even worse now ! > > This is the output from strace (relevant part): > > . > . > 0.000531 ioctl(4, SNDCTL_DSP_RESET, 0) = 0 > 0.000232 ioctl(4, SNDCTL_DSP_GETFMTS, 0xbffff668) = 0 > 0.510506 ioctl(4, SNDCTL_DSP_SETFMT, 0xbffff668) = 0 > 0.506515 ioctl(4, SNDCTL_DSP_STEREO, 0xbffff668) = 0 > 0.504940 ioctl(4, SOUND_PCM_READ_RATE, 0xbffff668) = 0 > 0.065604 ioctl(4, SNDCTL_DSP_GETBLKSIZE, 0x80a5824) = 0 > 0.000302 ioctl(4, SNDCTL_DSP_SYNC, 0) = 0 > 0.000250 munmap(0x40016000, 4096) = 0 > . > . > > > ..now it's not just a single call that takes too long, but _three_ of them. > > There has to be someone who nows about the changes made from the alsa > used in 2.6.4 and the current release, this way we could probably locate > the source for the _additional_ delay introduced, maybe that'll lead us > to a solution for the whole issue ? > > Can you create a small program, which makes these calls, and reproduces the problem. Then email the program as an attachment to the list. James ------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Opening dev/dsp takes very long 2004-03-19 23:56 ` James Courtier-Dutton @ 2004-03-20 8:20 ` Lars Heineken 2004-03-20 13:24 ` Jaroslav Kysela 0 siblings, 1 reply; 17+ messages in thread From: Lars Heineken @ 2004-03-20 8:20 UTC (permalink / raw) To: alsa-devel [-- Attachment #1: Type: text/plain, Size: 725 bytes --] > 0.000531 ioctl(4, SNDCTL_DSP_RESET, 0) = 0 > 0.000232 ioctl(4, SNDCTL_DSP_GETFMTS, 0xbffff668) = 0 > 0.510506 ioctl(4, SNDCTL_DSP_SETFMT, 0xbffff668) = 0 > 0.506515 ioctl(4, SNDCTL_DSP_STEREO, 0xbffff668) = 0 > 0.504940 ioctl(4, SOUND_PCM_READ_RATE, 0xbffff668) = 0 > 0.065604 ioctl(4, SNDCTL_DSP_GETBLKSIZE, 0x80a5824) = 0 > 0.000302 ioctl(4, SNDCTL_DSP_SYNC, 0) = 0 > 0.000250 munmap(0x40016000, 4096) = 0 The output is from executing this line: strace -r sox 01.wav -t ossdsp /dev/dsp As each and every oss-program on my machine suffers from this unusual delay I think it doesn't make much sense to write a sample program, but anyway, it's attached. Regards, Lars. [-- Attachment #2: delay.c --] [-- Type: text/plain, Size: 525 bytes --] #include "stdio.h" #include <sys/soundcard.h> #include <unistd.h> #include <fcntl.h> main() { int file; file = open("/dev/dsp", O_RDWR, 0); ioctl(file, SNDCTL_DSP_RESET, 0); ioctl(file, SNDCTL_TMR_TIMEBASE, 0xbffff4d0); ioctl(file, SNDCTL_DSP_GETFMTS, 0xbffff668); ioctl(file, SNDCTL_DSP_SETFMT, 0xbffff668); ioctl(file, SNDCTL_DSP_STEREO, 0xbffff668); ioctl(file, SOUND_PCM_READ_RATE, 0xbffff668); ioctl(file, SNDCTL_DSP_GETBLKSIZE, 0x80a5824); ioctl(file, SNDCTL_DSP_SYNC, 0); close(file); } ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Opening dev/dsp takes very long 2004-03-20 8:20 ` Lars Heineken @ 2004-03-20 13:24 ` Jaroslav Kysela 2004-03-20 16:09 ` Lars Heineken 2004-03-20 17:13 ` Tommi Sakari Uimonen 0 siblings, 2 replies; 17+ messages in thread From: Jaroslav Kysela @ 2004-03-20 13:24 UTC (permalink / raw) To: Lars Heineken; +Cc: alsa-devel On Sat, 20 Mar 2004, Lars Heineken wrote: > As each and every oss-program on my machine suffers from this unusual > delay I think it doesn't make much sense to write a sample program, but > anyway, it's attached. It's related to the snd-ice1712 driver and hardware which has the cs8427 transciever. I've added cs8427_timeout module option, so you can lower the reset timeout value for this chip. I left the safe value 50 (0.5 sec) as default. If you set this timeout to very small value, then the S/PDIF output might be broken due to bug in some revisions of this chip. Jaroslav ----- Jaroslav Kysela <perex@suse.cz> Linux Kernel Sound Maintainer ALSA Project, SuSE Labs ------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Opening dev/dsp takes very long 2004-03-20 13:24 ` Jaroslav Kysela @ 2004-03-20 16:09 ` Lars Heineken 2004-03-20 16:11 ` Jaroslav Kysela 2004-03-20 17:13 ` Tommi Sakari Uimonen 1 sibling, 1 reply; 17+ messages in thread From: Lars Heineken @ 2004-03-20 16:09 UTC (permalink / raw) To: alsa-devel > It's related to the snd-ice1712 driver and hardware which has the cs8427 > transciever. I've added cs8427_timeout module option, so you can > lower the reset timeout value for this chip. I left the safe value 50 (0.5 > sec) as default. If you set this timeout to very small value, then > the S/PDIF output might be broken due to bug in some revisions of this > chip. ..but why doesn't it affect alsa, just it's OSS emulation ? Greetings, Lars. ------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Opening dev/dsp takes very long 2004-03-20 16:09 ` Lars Heineken @ 2004-03-20 16:11 ` Jaroslav Kysela 2004-03-20 16:59 ` Lars Heineken 0 siblings, 1 reply; 17+ messages in thread From: Jaroslav Kysela @ 2004-03-20 16:11 UTC (permalink / raw) To: Lars Heineken; +Cc: alsa-devel On Sat, 20 Mar 2004, Lars Heineken wrote: > > > It's related to the snd-ice1712 driver and hardware which has the cs8427 > > transciever. I've added cs8427_timeout module option, so you can > > lower the reset timeout value for this chip. I left the safe value 50 (0.5 > > sec) as default. If you set this timeout to very small value, then > > the S/PDIF output might be broken due to bug in some revisions of this > > chip. > > ..but why doesn't it affect alsa, just it's OSS emulation ? It affects both, but ALSA API does the setup of stream parameters once, but OSS API does this multiple times because there is no way to distict the configuration phase and the working phase, thus we must reconfigure after settings of all parameters. If you strace aplay then you'll see that one ALSA ioctl has exactly same 0.5 sec peek. Jaroslav ----- Jaroslav Kysela <perex@suse.cz> Linux Kernel Sound Maintainer ALSA Project, SuSE Labs ------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Opening dev/dsp takes very long 2004-03-20 16:11 ` Jaroslav Kysela @ 2004-03-20 16:59 ` Lars Heineken 0 siblings, 0 replies; 17+ messages in thread From: Lars Heineken @ 2004-03-20 16:59 UTC (permalink / raw) To: alsa-devel > It affects both, but ALSA API does the setup of stream parameters once, > but OSS API does this multiple times because there is no way to distict > the configuration phase and the working phase, thus we must reconfigure > after settings of all parameters. > > If you strace aplay then you'll see that one ALSA ioctl has exactly same > 0.5 sec peek. Thanks a lot for your help, I would have never found that by myself. To test it, i modified these lines (an ugly hack, for sure) snd_cs8427_reg_write(cs8427, CS8427_REG_CLOCKSOURCE, chip->regmap[CS8427_REG_CLOCKSOURCE]); //udelay(200); chip->regmap[CS8427_REG_CLOCKSOURCE] |= CS8427_RUN | CS8427_RXDILRCK; snd_cs8427_reg_write(cs8427, CS8427_REG_CLOCKSOURCE, chip->regmap[CS8427_REG_CLOCKSOURCE]); //udelay(200); snd_i2c_unlock(cs8427->bus); end_time = 0; //jiffies + HZ / 2; ..and it works like a charm on my Terratec EWX24/96. After the next release I'll test the module option. Thanks again, Lars. ------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Opening dev/dsp takes very long 2004-03-20 13:24 ` Jaroslav Kysela 2004-03-20 16:09 ` Lars Heineken @ 2004-03-20 17:13 ` Tommi Sakari Uimonen 2004-03-20 17:12 ` Jaroslav Kysela 1 sibling, 1 reply; 17+ messages in thread From: Tommi Sakari Uimonen @ 2004-03-20 17:13 UTC (permalink / raw) Cc: alsa-devel > It's related to the snd-ice1712 driver and hardware which has the cs8427 > transciever. I've added cs8427_timeout module option, so you can I have M-Audio Audiophile and suffer from this also, but I'm not sure if it has cs8427. 2.4.24 with ll+pe alsa 0.9.8 If I'm not totally wrong, the earlier 0.9 series didn't suffer from this, but it's long time ago so can't remember. Tommi ------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Opening dev/dsp takes very long 2004-03-20 17:13 ` Tommi Sakari Uimonen @ 2004-03-20 17:12 ` Jaroslav Kysela 0 siblings, 0 replies; 17+ messages in thread From: Jaroslav Kysela @ 2004-03-20 17:12 UTC (permalink / raw) To: Tommi Sakari Uimonen; +Cc: alsa-devel On Sat, 20 Mar 2004, Tommi Sakari Uimonen wrote: > > It's related to the snd-ice1712 driver and hardware which has the cs8427 > > transciever. I've added cs8427_timeout module option, so you can > > I have M-Audio Audiophile and suffer from this also, but I'm not sure if > it has cs8427. It has this chip, too. > If I'm not totally wrong, the earlier 0.9 series didn't suffer from this, > but it's long time ago so can't remember. Yes, I added the workaround which causes this behaviour for the transmitter bug in those days. Jaroslav ----- Jaroslav Kysela <perex@suse.cz> Linux Kernel Sound Maintainer ALSA Project, SuSE Labs ------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click ^ permalink raw reply [flat|nested] 17+ messages in thread
end of thread, other threads:[~2004-03-20 17:13 UTC | newest] Thread overview: 17+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2004-03-13 20:01 Opening dev/dsp takes very long Lars Heineken 2004-03-13 20:24 ` Additional info: " Lars Heineken 2004-03-15 10:35 ` Takashi Iwai 2004-03-15 20:22 ` Lars Heineken 2004-03-16 8:19 ` Clemens Ladisch 2004-03-16 8:49 ` Lars Heineken 2004-03-16 19:04 ` Lars Heineken 2004-03-19 12:29 ` Lars Heineken 2004-03-19 21:58 ` Lars Heineken 2004-03-19 23:56 ` James Courtier-Dutton 2004-03-20 8:20 ` Lars Heineken 2004-03-20 13:24 ` Jaroslav Kysela 2004-03-20 16:09 ` Lars Heineken 2004-03-20 16:11 ` Jaroslav Kysela 2004-03-20 16:59 ` Lars Heineken 2004-03-20 17:13 ` Tommi Sakari Uimonen 2004-03-20 17:12 ` Jaroslav Kysela
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.