lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20070723120233.GA28222@elte.hu>
Date:	Mon, 23 Jul 2007 14:02:33 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	"Ni@m" <niam.niam@...il.com>
Cc:	Michal Piotrowski <michal.k.k.piotrowski@...il.com>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: sound is interrupting with new kernels


* Ni@m <niam.niam@...il.com> wrote:

> >Please run this script while using mplayer or audacious
> >http://people.redhat.com/mingo/cfs-scheduler/tools/cfs-debug-info.sh
> >and send results
> >
> I did it anyway ... see the attachment. The script has been running
> while mplayer has been running and sound has been interrupting.

firstly, could you check whether the ogg123/mpg321 console apps work 
without any audio skipping? If they work fine, does Amarok work fine? 
(Amarok is an X apps that has a high-quality latency design - most other 
X based players are affected by X communication latencies.)

Can you see any ALSA xruns related to any of the apps that skips sound? 
For that, first enable CONFIG_SND_DEBUG and CONFIG_SND_PCM_XRUN_DEBUG 
and reboot into such an xrun-debug enabled kernel. Once you have booted 
into it, you should see the xrun_debug flag of your audio driver, under 
/proc/asound/card*/pcm*/xrun_debug. Do something like this:

   echo 1 > /proc/asound/card0/pcm0p/xrun_debug

can you see any ALSA xruns reported to the syslog at the same time the 
audio apps are skipping?

Plus if any of the above apps causes audio skipping then to further 
debug this, could you try the latency tracer:

 http://redhat.com/~mingo/latency-tracing-patches/latency-tracing-v2.6.23-rc1-combo.patch

apply the combo patch to v2.6.23-rc1, enable CONFIG_WAKEUP_TIMING and 
CONFIG_FUNCTION_TRACING, boot into the new kernel and do this to start 
the latency tracer:

  echo 0 > /proc/sys/kernel/preempt_max_latency

you should start seeing such messages in the syslog:

 (            sshd-2254 |#1): new 2 us maximum-latency wakeup.
 (           sleep-2310 |#0): new 4 us maximum-latency wakeup.
 (          auditd-1856 |#1): new 6 us maximum-latency wakeup.
 (          auditd-1857 |#0): new 9 us maximum-latency wakeup.
 (       kjournald-1455 |#1): new 10 us maximum-latency wakeup.
 (              ls-2318 |#1): new 11 us maximum-latency wakeup.
 (       kjournald-623  |#1): new 15 us maximum-latency wakeup.
 (            bash-2324 |#1): new 15 us maximum-latency wakeup.
 (       kjournald-623  |#1): new 50 us maximum-latency wakeup.
 (        events/0-9    |#0): new 262 us maximum-latency wakeup.

it will increase monotonically - always showing the worst-case latency 
it detected. What kind of numbers do you get, while the sound is 
skipping? If it's in the milliseconds, then wakeup latencies could be 
the cause of your sound skipping. Send the contents of the 
/proc/latency_trace file in that case.

( if the reported latencies are low, but sound is skipping too and ALSA 
  reports xrun, then we can use the tracer to debug audio latencies 
  directly as well, but that will need an extra patch. )

	Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ