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/[email protected]/msg17399.html
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.
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
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
Lee Revell <[email protected]> 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.
Lee Revell <[email protected]> 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
On Tue, 2006-09-26 at 16:37 +0200, Dominique Dumont wrote:
> Lee Revell <[email protected]> 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
Lee Revell <[email protected]> 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
"Francesco Peeters" <[email protected]> writes:
> Have you tried using a different slot for the SB Live?
Yes. No change at all. (Sorry for the delay).
Cheers
On Thu, 2006-10-05 at 22:42 +0200, Dominique Dumont wrote:
> "Francesco Peeters" <[email protected]> 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
Lee Revell <[email protected]> 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
On Thu, 2006-10-05 at 23:01 +0200, Dominique Dumont wrote:
> Lee Revell <[email protected]> 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
On Thu, 2006-10-05 at 23:01 +0200, Dominique Dumont wrote:
> Lee Revell <[email protected]> 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
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 ?
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
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
(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
Lee Revell <[email protected]> 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