Pb with simultaneous SATA and ALSA I/O

Pb with simultaneous SATA and ALSA I/O

[Dominique Dumont]

Hello

I have some problem using the SPDIF output of my SB Live card while
performing I/O on my SATA drive. (See [1] for the whole story on the
ALSA mailing list)

My Yamaha amplifier does not recognize the AC3 (Dolby digital) stream
from the sdpif plug while performing I/O on my SATA drive.

If I have a lot of I/O (e.g. running md5sum on a 4Gb file), the AC3
stream is completely broken.

If I have some I/O (e.g. reading a Hi-def movie), I get some AC3
drop-out even if the CPU is about 50%.

I have the same result with DTS output.

With PCM output, I've noticed a hi-frequency distortion, which means
that the interaction between SATA and snd module occurs several
thousands time per second.

My set up is:
- Debian Linux kernel 2.6.17
- Sound blaster SB Live 5.1 (snd_emu10k1 module)
- SATA drive (sata_sil and libata module)
- A7n8x deluxe mobo
- AMD XP 3200 

So far I verified that:
- AC3 output works fine when SATA drive is left alone
- AC3 output works fine when running md5sum on a PATA drive
- DTS output works fine on the mobo SPDIF output (snd_intel8x0 module)
  even when running md5sum on the SATA drive. (cannot try AC3 stream
  because of Soundstorm chip :-( )
- Preemp kernel option does not fix the problem
- when running md5sum on SATA drive, alsa driver report a starvation
  (xrun) every few seconds, not thousands of time per second.

Could someone shed some light on this problem ?

What can I do to help debug this problem ?

Thanks


[1] http://www.mail-archive.com/alsa-user@lists.sourceforge.net/msg17399.html

Re: [Alsa-user] Pb with simultaneous SATA and ALSA I/O

[Francesco Peeters]

On Mon, September 25, 2006 13:55, Dominique Dumont wrote:
>
> Hello
>
> I have some problem using the SPDIF output of my SB Live card while
> performing I/O on my SATA drive. (See [1] for the whole story on the
> ALSA mailing list)
>
> My Yamaha amplifier does not recognize the AC3 (Dolby digital) stream
> from the sdpif plug while performing I/O on my SATA drive.
>
> If I have a lot of I/O (e.g. running md5sum on a 4Gb file), the AC3
> stream is completely broken.
>
> If I have some I/O (e.g. reading a Hi-def movie), I get some AC3
> drop-out even if the CPU is about 50%.
>
> I have the same result with DTS output.
>
> With PCM output, I've noticed a hi-frequency distortion, which means
> that the interaction between SATA and snd module occurs several
> thousands time per second.
>
> My set up is:
> - Debian Linux kernel 2.6.17
> - Sound blaster SB Live 5.1 (snd_emu10k1 module)
> - SATA drive (sata_sil and libata module)
> - A7n8x deluxe mobo
> - AMD XP 3200
>
> So far I verified that:
> - AC3 output works fine when SATA drive is left alone
> - AC3 output works fine when running md5sum on a PATA drive
> - DTS output works fine on the mobo SPDIF output (snd_intel8x0 module)
>   even when running md5sum on the SATA drive. (cannot try AC3 stream
>   because of Soundstorm chip :-( )
> - Preemp kernel option does not fix the problem
> - when running md5sum on SATA drive, alsa driver report a starvation
>   (xrun) every few seconds, not thousands of time per second.
>
> Could someone shed some light on this problem ?
>
> What can I do to help debug this problem ?
>
> Thanks
>
>

Have you tried using a different slot for the SB Live?

-- 
Francesco Peeters
----
GPG Key = AA69 E7C6 1D8A F148 160C  D5C4 9943 6E38 D5E3 7704
If your program doesn't recognize my signature, please visit
http://www.CAcert.org/index.php?id=3 to retrieve the Root CA certificate.

Re: [Alsa-user] Pb with simultaneous SATA and ALSA I/O

[Dominique Dumont]

"Francesco Peeters" <Francesco@FamPeeters.com> writes:

> Have you tried using a different slot for the SB Live?

Yes. No change at all. (Sorry for the delay).

Cheers

Re: [Alsa-user] Pb with simultaneous SATA and ALSA I/O

[Lee Revell]

On Thu, 2006-10-05 at 22:42 +0200, Dominique Dumont wrote:
> "Francesco Peeters" <Francesco@FamPeeters.com> writes:
> 
> > Have you tried using a different slot for the SB Live?
> 
> Yes. No change at all. (Sorry for the delay).

This is going to be a problem with the SATA driver not ALSA.  I've heard
that some motherboards do evil stuff like implementing legacy drive
access modes using SMM which would cause dropouts without xruns
reported.

Please report it on LKML.

Lee

Re: [Alsa-user] Pb with simultaneous SATA and ALSA I/O

[Dominique Dumont]

Lee Revell <rlrevell@joe-job.com> writes:

> This is going to be a problem with the SATA driver not ALSA.  I've heard
> that some motherboards do evil stuff like implementing legacy drive
> access modes using SMM which would cause dropouts without xruns
> reported.

Why do I hear distortion with PCM on SPDIF output and no distortion at
all on analog front output ? (both with the SB Live card)

> Please report it on LKML.

Will do. (although your mail and this mail are cc'ed to LKLM)

Thanks

Re: [Alsa-user] Pb with simultaneous SATA and ALSA I/O

[Lee Revell]

On Thu, 2006-10-05 at 23:01 +0200, Dominique Dumont wrote:
> Lee Revell <rlrevell@joe-job.com> writes:
> 
> > This is going to be a problem with the SATA driver not ALSA.  I've heard
> > that some motherboards do evil stuff like implementing legacy drive
> > access modes using SMM which would cause dropouts without xruns
> > reported.
> 
> Why do I hear distortion with PCM on SPDIF output and no distortion at
> all on analog front output ? (both with the SB Live card)

No idea.  Maybe SPDIF playback is more sensitive to timing glitches.
But the problem must be in the SATA driver not the emu10k1 driver.

Lee

Re: [Alsa-user] Pb with simultaneous SATA and ALSA I/O

[Alan Cox]

Ar Iau, 2006-10-05 am 17:12 -0400, ysgrifennodd Lee Revell:
> > Why do I hear distortion with PCM on SPDIF output and no distortion at
> > all on analog front output ? (both with the SB Live card)
> 
> No idea.  Maybe SPDIF playback is more sensitive to timing glitches.
> But the problem must be in the SATA driver not the emu10k1 driver.

Nothing to do with the SATA drivers, remember the S/PDIF and PCM bits
come off the same codec so the bits hitting the codec are the same and
thats way way outside the realm sata can affect.

If it's electrical noise though then power fluctuations or similar could
be to blame ?

PCM distorsion snapshots from SATA/ALSA conflict (was: [Alsa-user] Pb with simultaneous SATA and ALSA I/O)

[Dominique Dumont]

[-- Attachment #1: Type: text/plain, Size: 1359 bytes --]

Alan Cox <alan@lxorguk.ukuu.org.uk> writes:

> If it's electrical noise though then power fluctuations or similar
> could be to blame ?

To check this, I've dusted off my old oscilloscope.

I've used speaker-test program to generate a 500, 900 and 1000 Hz sine
wave that I've sent on the spdif line (as PCM) and had them decoded by
my Yamaha DSP-A1 amplifier.

I've enclosed only the snapshots to this mail, I hope it'll get
through vger's majordomo. 

Anyway, the oscilloscope shows that:
- a spike occurs every 330 useconds (about 3kHz)
  (note: 330us is 15.85 times the period of the 48KHz spdif stream) 
- the spike level roughly matches the level of the sine waves 330
  useconds sooner

I may be wrong, but it looks like that, somewhere in the audio data
stream, a buffer is read downstream before the correct value is
written by upstream (delayed by SATA I/O ??). OTOH, 16 samples is a
very short buffer...

If needed I can try other things like:
- loop back the spdif output to my mobo's input to get the actual
  values of the PCM stream sent to the Yamaha.
- try the oscilloscope on the analog output of the SB live card ( I
  couldn't hear any distorsion on the analog line, but it does mean
  there no problem on this side as the D/A converter may filter out
  these kind of short duration spikes)
- try another signal shape 

Any thought ?

HTH


[-- Attachment #2: c2_500Hz.jpg --]
[-- Type: image/jpeg, Size: 15821 bytes --]

[-- Attachment #3: c2_900Hz.jpg --]
[-- Type: image/jpeg, Size: 16690 bytes --]

[-- Attachment #4: c2_1000Hz.jpg --]
[-- Type: image/jpeg, Size: 22708 bytes --]

Re: PCM distorsion snapshots from SATA/ALSA conflict (was: [Alsa-user] Pb with simultaneous SATA and ALSA I/O)

[Lee Revell]

(it's probably a bad idea to attach .jpgs to a LKML post - please post
them on the web and send a URL)

On Sun, 2006-10-08 at 12:38 +0200, Dominique Dumont wrote:
> Anyway, the oscilloscope shows that:
> - a spike occurs every 330 useconds (about 3kHz)
>   (note: 330us is 15.85 times the period of the 48KHz spdif stream) 
> - the spike level roughly matches the level of the sine waves 330
>   useconds sooner
> 

You seem to be using a period size of 256 samples - any change if you
use a larger period size?

Any change if you use setpci to increase LATENCY_TIMER for the SBLive!
card?

Lee

Re: [Alsa-user] PCM distorsion snapshots from SATA/ALSA conflict

[Dominique Dumont]

Lee Revell <rlrevell@joe-job.com> writes:

> (it's probably a bad idea to attach .jpgs to a LKML post - please post
> them on the web and send a URL)

(ok. But is there a site that will guarantee the availability of the
jpg attachments when people are searching the lklm or alsa archives ?
)

> You seem to be using a period size of 256 samples - any change if you
> use a larger period size?

Unless I'm wrong, you want me to test the PCM output while modifying
the --period option of speaker-test.

So I've tested this command:
  speaker-test -D iec958 -c 2 -f 1000 -p 4096 -t sine -s 2

No change: I still have a lot of spikes in the sine wave.

> Any change if you use setpci to increase LATENCY_TIMER for the SBLive!
> card?

To be sure I've done the correct tests, here are the commands are used:

$ lspci
[...]
01:07.0 Multimedia audio controller: Creative Labs SB Live! EMU10k1 (rev 0a)
01:07.1 Input device controller: Creative Labs SB Live! Game Port (rev 0a)
[...]
01:0b.0 RAID bus controller: Silicon Image, Inc. SiI 3112 [SATALink/SATARaid] Serial ATA Controller (rev 02)

$ sudo setpci -s 01:07.0 latency_timer=80
$ sudo setpci -s 01:07.0 latency_timer=f8
$ sudo setpci -s 01:0b.0 latency_timer=10

No change at all :-(

Cheers

Re: [Alsa-user] Pb with simultaneous SATA and ALSA I/O

[Lee Revell]

On Thu, 2006-10-05 at 23:01 +0200, Dominique Dumont wrote:
> Lee Revell <rlrevell@joe-job.com> writes:
> 
> > This is going to be a problem with the SATA driver not ALSA.  I've heard
> > that some motherboards do evil stuff like implementing legacy drive
> > access modes using SMM which would cause dropouts without xruns
> > reported.
> 
> Why do I hear distortion with PCM on SPDIF output and no distortion at
> all on analog front output ? (both with the SB Live card)
> 
> > Please report it on LKML.
> 
> Will do. (although your mail and this mail are cc'ed to LKLM)

Did you ever try the latency tracer?  (See LKML archives for
instructions)

Lee

Re: [Alsa-user] Pb with simultaneous SATA and ALSA I/O

[Dominique Dumont]

Lee Revell <rlrevell@joe-job.com> writes:

> Did you ever try the latency tracer?  (See LKML archives for
> instructions)

Yes I did (this time better than 2 or 3 days ago :-/ ).

- I compiled and booted 2.6.28-rt5 with latency tracer enabled
- I verified that I got latency trace enabled (seen trace in kern.log)

I only got some traces after running this (detail added for the sake
of other newbies like me) :

   gandalf:/proc/sys/kernel# echo 0 > preempt_max_latency

Here's the max latency trace I got (note that I got a similar trace
*before* running the test, so I'd say it's unrelated to the AC3
drop-out problem.):

preemption latency trace v1.1.5 on 2.6.18-rt5
--------------------------------------------------------------------
 latency: 19 us, #58/58, CPU#0 | (M:rt VP:0, KP:0, SP:1 HP:1)
    -----------------
    | task: posix_cpu_timer-2 (uid:0 nice:0 policy:1 rt_prio:99)
    -----------------

                 _------=> CPU#            
                / _-----=> irqs-off        
               | / _----=> need-resched    
               || / _---=> hardirq/softirq 
               ||| / _--=> preempt-depth   
               |||| /                      
               |||||     delay             
   cmd     pid ||||| time  |   caller      
      \   /    |||||   \   |   /           
  <idle>-0     0Dnh2    0us : __trace_start_sched_wakeup (try_to_wake_up)
  <idle>-0     0Dnh2    0us : __trace_start_sched_wakeup <<...>-2> (0 0)
  <idle>-0     0Dnh2    0us : try_to_wake_up <<...>-2> (199 20)
  <idle>-0     0Dnh1    0us : preempt_schedule (try_to_wake_up)
  <idle>-0     0Dnh1    0us : wake_up_process (run_posix_cpu_timers)
  <idle>-0     0Dnh1    0us : note_interrupt (handle_level_irq)
  <idle>-0     0Dnh2    0us : enable_8259A_irq (handle_level_irq)
  <idle>-0     0Dnh2    1us : preempt_schedule (enable_8259A_irq)
  <idle>-0     0Dnh1    1us : preempt_schedule (handle_level_irq)
  <idle>-0     0Dnh1    2us : irq_exit (do_IRQ)
  <idle>-0     0Dnh1    3us : do_IRQ (b0101ade b 0)
  <idle>-0     0Dnh1    3us : handle_level_irq (do_IRQ)
  <idle>-0     0Dnh2    3us+: mask_and_ack_8259A (handle_level_irq)
  <idle>-0     0Dnh2    8us : preempt_schedule (mask_and_ack_8259A)
  <idle>-0     0Dnh2    8us : redirect_hardirq (handle_level_irq)
  <idle>-0     0Dnh2    9us : wake_up_process (redirect_hardirq)
  <idle>-0     0Dnh2    9us : try_to_wake_up (wake_up_process)
  <idle>-0     0Dnh2    9us : task_rq_lock (try_to_wake_up)
  <idle>-0     0Dnh3    9us : activate_task (try_to_wake_up)
  <idle>-0     0Dnh3    9us : sched_clock (activate_task)
  <idle>-0     0Dnh3    9us : __activate_task (activate_task)
  <idle>-0     0Dnh3    9us : __activate_task <<...>-2006> (59 1)
  <idle>-0     0Dnh3    9us : enqueue_task (__activate_task)
  <idle>-0     0Dnh3    9us : __trace_start_sched_wakeup (try_to_wake_up)
  <idle>-0     0Dnh3    9us : try_to_wake_up <<...>-2006> (140 20)
  <idle>-0     0Dnh2    9us : preempt_schedule (try_to_wake_up)
  <idle>-0     0Dnh2    9us : wake_up_process (redirect_hardirq)
  <idle>-0     0Dnh1   10us : preempt_schedule (handle_level_irq)
  <idle>-0     0Dnh1   10us : irq_exit (do_IRQ)
  <idle>-0     0Dnh1   11us : do_IRQ (b0101ade e 0)
  <idle>-0     0Dnh1   11us : handle_level_irq (do_IRQ)
  <idle>-0     0Dnh2   11us+: mask_and_ack_8259A (handle_level_irq)
  <idle>-0     0Dnh2   16us : preempt_schedule (mask_and_ack_8259A)
  <idle>-0     0Dnh2   16us : redirect_hardirq (handle_level_irq)
  <idle>-0     0Dnh2   16us : wake_up_process (redirect_hardirq)
  <idle>-0     0Dnh2   16us : try_to_wake_up (wake_up_process)
  <idle>-0     0Dnh2   16us : task_rq_lock (try_to_wake_up)
  <idle>-0     0Dnh3   17us : activate_task (try_to_wake_up)
  <idle>-0     0Dnh3   17us : sched_clock (activate_task)
  <idle>-0     0Dnh3   17us : __activate_task (activate_task)
  <idle>-0     0Dnh3   17us : __activate_task <<...>-861> (53 2)
  <idle>-0     0Dnh3   17us : enqueue_task (__activate_task)
  <idle>-0     0Dnh3   17us : __trace_start_sched_wakeup (try_to_wake_up)
  <idle>-0     0Dnh3   17us : try_to_wake_up <<...>-861> (146 20)
  <idle>-0     0Dnh2   17us : preempt_schedule (try_to_wake_up)
  <idle>-0     0Dnh2   17us : wake_up_process (redirect_hardirq)
  <idle>-0     0Dnh1   17us : preempt_schedule (handle_level_irq)
  <idle>-0     0Dnh1   17us : irq_exit (do_IRQ)
  <idle>-0     0Dn..   17us : __schedule (cpu_idle)
  <idle>-0     0Dn..   17us : profile_hit (__schedule)
  <idle>-0     0Dn.1   18us : sched_clock (__schedule)
   <...>-2     0D..2   18us : __switch_to (__schedule)
   <...>-2     0D..2   18us : __schedule <<idle>-0> (20 199)
   <...>-2     0...1   18us : trace_stop_sched_switched (__schedule)
   <...>-2     0D..1   18us : trace_stop_sched_switched <<...>-2> (0 0)
   <...>-2     0D..2   18us : __schedule (__schedule)


vim:ft=help



Cheers

Re: [Alsa-user] Pb with simultaneous SATA and ALSA I/O

[Lee Revell]

On Sat, 2006-10-07 at 14:03 +0200, Dominique Dumont wrote:
> Lee Revell <rlrevell@joe-job.com> writes:
> 
> > Did you ever try the latency tracer?  (See LKML archives for
> > instructions)
> 
> Yes I did (this time better than 2 or 3 days ago :-/ ).
> 
> - I compiled and booted 2.6.28-rt5 with latency tracer enabled
> - I verified that I got latency trace enabled (seen trace in kern.log)
> 
> I only got some traces after running this (detail added for the sake
> of other newbies like me) :
> 
>    gandalf:/proc/sys/kernel# echo 0 > preempt_max_latency
> 
> Here's the max latency trace I got (note that I got a similar trace
> *before* running the test, so I'd say it's unrelated to the AC3
> drop-out problem.):

I think it must be an electrical noise issue.

Lee

Re: [Alsa-user] Pb with simultaneous SATA and ALSA I/O

[Alan Cox]

Ar Iau, 2006-10-05 am 16:45 -0400, ysgrifennodd Lee Revell:
> I've heard that some motherboards do evil stuff like implementing legacy drive
> access modes using SMM which would cause dropouts without xruns
> reported.

They don't. SATA causes audio dropouts on some systems because its fast
enough to starve the audio device of regular enough access to the PCI
bus. If that is a problem the audio device should be tuning PCI
latencies

Re: [Alsa-user] Pb with simultaneous SATA and ALSA I/O

[Lee Revell]

On Thu, 2006-10-05 at 22:52 +0100, Alan Cox wrote:
> Ar Iau, 2006-10-05 am 16:45 -0400, ysgrifennodd Lee Revell:
> > I've heard that some motherboards do evil stuff like implementing legacy drive
> > access modes using SMM which would cause dropouts without xruns
> > reported.
> 
> They don't. SATA causes audio dropouts on some systems because its fast
> enough to starve the audio device of regular enough access to the PCI
> bus. If that is a problem the audio device should be tuning PCI
> latencies
> 

OK.  In fact the Windows driver and IIRC the OSS driver do tune PCI
latencies.  But that can't be the problem here if analog playback is
unaffected.  Sounds like electrical noise could be the issue...

Lee

Re: Pb with simultaneous SATA and ALSA I/O

[Lennart Sorensen]

On Mon, Sep 25, 2006 at 01:55:17PM +0200, Dominique Dumont wrote:
> I have some problem using the SPDIF output of my SB Live card while
> performing I/O on my SATA drive. (See [1] for the whole story on the
> ALSA mailing list)
> 
> My Yamaha amplifier does not recognize the AC3 (Dolby digital) stream
> from the sdpif plug while performing I/O on my SATA drive.
> 
> If I have a lot of I/O (e.g. running md5sum on a 4Gb file), the AC3
> stream is completely broken.
> 
> If I have some I/O (e.g. reading a Hi-def movie), I get some AC3
> drop-out even if the CPU is about 50%.
> 
> I have the same result with DTS output.
> 
> With PCM output, I've noticed a hi-frequency distortion, which means
> that the interaction between SATA and snd module occurs several
> thousands time per second.
> 
> My set up is:
> - Debian Linux kernel 2.6.17
> - Sound blaster SB Live 5.1 (snd_emu10k1 module)
> - SATA drive (sata_sil and libata module)
> - A7n8x deluxe mobo
> - AMD XP 3200 
> 
> So far I verified that:
> - AC3 output works fine when SATA drive is left alone
> - AC3 output works fine when running md5sum on a PATA drive
> - DTS output works fine on the mobo SPDIF output (snd_intel8x0 module)
>   even when running md5sum on the SATA drive. (cannot try AC3 stream
>   because of Soundstorm chip :-( )
> - Preemp kernel option does not fix the problem
> - when running md5sum on SATA drive, alsa driver report a starvation
>   (xrun) every few seconds, not thousands of time per second.
> 
> Could someone shed some light on this problem ?
> 
> What can I do to help debug this problem ?

Well i agree with the suggestion of trying a different PCI slot for the
sb live.  There is so much onboard stuff sharing interrupts on those
boards that you might have problems because of that.  Creative cards are
not very good at dealing with anything other than ideal conditions from
what I have gathered over the years.  The manual for the board will tell
you which IRQ goes to which slot, and I guess you want to avoid using a
slot that shares with the SATA controller.

--
Len Sorensen

Re: Pb with simultaneous SATA and ALSA I/O

[Lee Revell]

On Mon, 2006-09-25 at 10:38 -0400, Lennart Sorensen wrote:
> Well i agree with the suggestion of trying a different PCI slot for
> the sb live.  There is so much onboard stuff sharing interrupts on
> those boards that you might have problems because of that.  Creative
> cards are not very good at dealing with anything other than ideal
> conditions from what I have gathered over the years.  The manual for
> the board will tell you which IRQ goes to which slot, and I guess you
> want to avoid using a slot that shares with the SATA controller. 

It might not be interrupt related, it could be DMA starvation.  This has
been observed with some SATA controllers while testing the -rt patches.
The symptom is that the latency traces show the machine going in "slow
motion".

Dominique: try the -rt kernel, enable latency tracing and post the
output.

Lee

Re: Pb with simultaneous SATA and ALSA I/O

[Thierry Vignaud]

Lee Revell <rlrevell@joe-job.com> writes:

> > Well i agree with the suggestion of trying a different PCI slot
> > for the sb live.  There is so much onboard stuff sharing
> > interrupts on those boards that you might have problems because of
> > that.  Creative cards are not very good at dealing with anything
> > other than ideal conditions from what I have gathered over the
> > years.  The manual for the board will tell you which IRQ goes to
> > which slot, and I guess you want to avoid using a slot that shares
> > with the SATA controller.
> 
> It might not be interrupt related, it could be DMA starvation.  This
> has been observed with some SATA controllers while testing the -rt
> patches.  The symptom is that the latency traces show the machine
> going in "slow motion".

with the -rt patch, high resolution timer + dyn helps too in going in
deep slow mode.

Re: Pb with simultaneous SATA and ALSA I/O

[Dominique Dumont]

Lee Revell <rlrevell@joe-job.com> writes:

> Dominique: try the -rt kernel, enable latency tracing and post the
> output.

Should I use 2.6.17 + rt to stay closer to my current setup or should I get 2.6.18 + rt ?

Thanks

Re: Pb with simultaneous SATA and ALSA I/O

[Lee Revell]

On Tue, 2006-09-26 at 16:37 +0200, Dominique Dumont wrote:
> Lee Revell <rlrevell@joe-job.com> writes:
> 
> > Dominique: try the -rt kernel, enable latency tracing and post the
> > output.
> 
> Should I use 2.6.17 + rt to stay closer to my current setup or should I get 2.6.18 + rt ?
> 

I would say 2.6.18 + -rt - it's not as if 2.6.17 could be fixed at this
point.

Lee

Re: [Alsa-user] Pb with simultaneous SATA and ALSA I/O

[Dominique Dumont]

Lee Revell <rlrevell@joe-job.com> writes:

> It might not be interrupt related, it could be DMA starvation.  This has
> been observed with some SATA controllers while testing the -rt patches.
> The symptom is that the latency traces show the machine going in "slow
> motion".
>
> Dominique: try the -rt kernel, enable latency tracing and post the
> output.

Done. I've tried with 2.6.18-rt5. CONFIG_LATENCY_TRACE is enabled.

Here are the results (still with running "ac3dec -C " and "md5sum *"
on a SATA drive): 
- I get no more ALSA xrun.
- /proc/latency_trace is empty
- dolby digital output is still considerably chopped.

Note that the dolby digital output works fine when:
- No I/O is done 
- heavy I/O on pata HDD (md5sum *)
- heavy I/O on DVD reader (md5sum *)

Did I miss something with the latency_trace ?

Cheers