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...@lists.sourceforge.net/msg17399.html
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Francesco Peeters
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.
Lennart Sorensen
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
Lee Revell
> 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
Thierry Vignaud
> > 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.
Dominique Dumont
> 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
Lee Revell
> Lee Revell <rlre...@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
Dominique Dumont
> 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
Dominique Dumont
> Have you tried using a different slot for the SB Live?
Yes. No change at all. (Sorry for the delay).
Cheers
Lee Revell
> "Francesco Peeters" <Fran...@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
Dominique Dumont
> 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
Lee Revell
> Lee Revell <rlre...@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
Lee Revell
>
> > 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
Alan Cox
> > 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 ?
Alan Cox
> 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
Lee Revell
> 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
Dominique Dumont
> 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
Lee Revell
> Lee Revell <rlre...@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
Lee Revell
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
Dominique Dumont
> (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