HDA irq understanding

HDA irq understanding

[Raffaele Recalcati]

Hi,
I know my question is quite easy for this ml, but I hope to get a little help.
I'm an embedded developer and I'm not so good with x86.
I'm trying to load the system and hear mp3 decoding getting worst, but
no way on my "Intel(R) Core(TM)2 Duo CPU P8400  @ 2.26GHz"
very basic system.
I'm trying to understand why I can't.
Using trace (the complete one is here
www.opensurf.it/trace12-02-04-19-14-48.txt_orig.lzma ) I get:

grep HDA trace12-02-04-19-14-48.txt
..
      cpu-100.sh-26486 [000]  9490.976257: irq_handler_entry: irq=21
handler=HDA Intel
      cpu-100.sh-26474 [000]  9490.984236: irq_handler_entry: irq=21
handler=HDA Intel
      cpu-100.sh-26467 [000]  9490.992220: irq_handler_entry: irq=21
handler=HDA Intel
      cpu-100.sh-26502 [000]  9491.088042: irq_handler_entry: irq=21
handler=HDA Intel
..
almost every 10msec
pulseaudio reads from /dev/snd/pcmC0D0p,
mplayer reads from pulseaudio.

How can I create context switch problem in this situation and trace is well ?
Thanks,
Raffaele

---------------------
Loading the system
---------------------
where I have lauched cpu-100.sh 20 times
$ cat cpu-100.sh
#!/bin/bash
while : ; do
true
done

I have also launched
root $ ping -l 100000 -q -s 10 -f localhost &
once

---
www.opensurf.it

Re: HDA irq understanding

[David Henningsson]

On 02/06/2012 08:06 AM, Raffaele Recalcati wrote:
> Hi,
> I know my question is quite easy for this ml, but I hope to get a little help.
> I'm an embedded developer and I'm not so good with x86.
> I'm trying to load the system and hear mp3 decoding getting worst, but
> no way on my "Intel(R) Core(TM)2 Duo CPU P8400  @ 2.26GHz"
> very basic system.
> I'm trying to understand why I can't.
> Using trace (the complete one is here
> www.opensurf.it/trace12-02-04-19-14-48.txt_orig.lzma ) I get:
>
> grep HDA trace12-02-04-19-14-48.txt
> ..
>        cpu-100.sh-26486 [000]  9490.976257: irq_handler_entry: irq=21
> handler=HDA Intel
>        cpu-100.sh-26474 [000]  9490.984236: irq_handler_entry: irq=21
> handler=HDA Intel
>        cpu-100.sh-26467 [000]  9490.992220: irq_handler_entry: irq=21
> handler=HDA Intel
>        cpu-100.sh-26502 [000]  9491.088042: irq_handler_entry: irq=21
> handler=HDA Intel
> ..
> almost every 10msec
> pulseaudio reads from /dev/snd/pcmC0D0p,
> mplayer reads from pulseaudio.
>
> How can I create context switch problem in this situation and trace is well ?
> Thanks,
> Raffaele

Sorry, is your problem that you *do* get broken audio when you load the 
system, or that you *don't* get broken audio when you load the system?

Either way, PulseAudio uses RT prio to get higher priority than your 
load scripts, so this is used in PulseAudio <=> ALSA communication, but 
not in mplayer <=> PulseAudio communication.

For the 10 msec frequency, it looks like timer-based scheduling is 
turned off (or possibly mplayer is using very small buffer sizes?). You 
might get help with this in the pulseaudio-discuss mailinglist.

-- 
David Henningsson, Canonical Ltd.
http://launchpad.net/~diwic

Re: HDA irq understanding

[Raffaele Recalcati]

Hi,

> Sorry, is your problem that you *do* get broken audio when you load the
> system, or that you *don't* get broken audio when you load the system?

I don't

> Either way, PulseAudio uses RT prio to get higher priority than your load
> scripts, so this is used in PulseAudio <=> ALSA communication, but not in
> mplayer <=> PulseAudio communication.

In fact the first problems appears in gnome interface
I'll do some SCHED_RR cpu loads applications.

> For the 10 msec frequency, it looks like timer-based scheduling is turned
> off (or possibly mplayer is using very small buffer sizes?). You might get
> help with this in the pulseaudio-discuss mailinglist.
>
> --
> David Henningsson, Canonical Ltd.
> http://launchpad.net/~diwic

I'll do some test changing mplayer buffer.

Thx,
-- 
Raffaele
www.opensurf.it