Takashi Iwai [EMAIL PROTECTED] writes:
If the preempt option doesn't solve the problem, I'd recommend you to
consult on LKML.
This is weird. With the preempt kernel, I get an xrun every time I
start reading the ac3 stream on sata disk. Not other I/O on the sata
device:
Sep 24 20:50:10 gandalf
Takashi Iwai [EMAIL PROTECTED] writes:
Well, you've seen the xrun detection there, so it's basically the
problem of other parts, such as disk contoller driver. That is,
something else takes too long time, and the irq for sound can't be
handled at the right time.
ok. But then, why is the
Lee Revell [EMAIL PROTECTED] writes:
Does this help?
# echo 64 /sys/block/hdc/queue/max_sectors_kb
Replace hdc with sda or whatever the kernel calls your disk and repeat
for all disks.
No change.
It's still a bug IMHO if this is needed, but might make your system
usable until the
At Wed, 20 Sep 2006 16:35:35 +0200,
Dominique Dumont wrote:
Takashi Iwai [EMAIL PROTECTED] writes:
Well, you've seen the xrun detection there, so it's basically the
problem of other parts, such as disk contoller driver. That is,
something else takes too long time, and the irq for sound
At Sun, 10 Sep 2006 20:30:30 +0200,
Dominique Dumont wrote:
Lee Revell [EMAIL PROTECTED] writes:
I see your kernel uses the ACPI PM timer for timing. Is it a dual
core AMD by any chance?
No, it's a 32 bits monocore (Barton XP3200)
If you use an SMP kernel, do you get different
On Tue, 2006-09-19 at 18:13 +0200, Takashi Iwai wrote:
Well, you've seen the xrun detection there, so it's basically the
problem of other parts, such as disk contoller driver. That is,
something else takes too long time, and the irq for sound can't be
handled at the right time.
If the
Takashi Iwai [EMAIL PROTECTED] writes:
Then check whether XRUN occurs at next. Make sure that you compiled
the driver with debug option (--with-debug=full configure option),
then do the following as root:
# echo 2 /proc/asound/card0/pcm2p/xrun_debug
then play the ac3 file. You'll
On Sun, 2006-09-10 at 14:24 +0200, Dominique Dumont wrote:
Takashi Iwai [EMAIL PROTECTED] writes:
Then check whether XRUN occurs at next. Make sure that you compiled
the driver with debug option (--with-debug=full configure option),
then do the following as root:
# echo 2
Lee Revell [EMAIL PROTECTED] writes:
I see your kernel uses the ACPI PM timer for timing. Is it a dual
core AMD by any chance?
No, it's a 32 bits monocore (Barton XP3200)
If you use an SMP kernel, do you get different results with a UP
kernel?
I use the kernel provided by Debian which is
Andrew Lyon [EMAIL PROTECTED] writes:
hmm, which one is your sata ?
sata_sil depends on libata. So the libata counter is the one you're
looking for.
while reading from the drive and playing audio repeat the command 10
seconds later and show what the interrupt counters have changed to.
Here
Dominique Dumont [EMAIL PROTECTED] writes:
So far, I've noticed that:
- Playing ac3 while loading PATA drive (same commands) works perfectly
- Playing PCM (with mplayer) on spdif while loading SATA leads to high
frequency noises (like a constinuous scritch-scritch)
I've just tried the
At Wed, 06 Sep 2006 15:17:20 +0200,
Dominique Dumont wrote:
Dominique Dumont [EMAIL PROTECTED] writes:
So far, I've noticed that:
- Playing ac3 while loading PATA drive (same commands) works perfectly
- Playing PCM (with mplayer) on spdif while loading SATA leads to high
frequency
Takashi Iwai [EMAIL PROTECTED] writes:
Does the patch below have any influence?
The patch was necessary to run a52 plugin on emu10k1 on my test
system.
No, sorry. AC3 output is still practically cut off when I run md5sum.
Cheers
At Wed, 06 Sep 2006 18:56:17 +0200,
Dominique Dumont wrote:
Takashi Iwai [EMAIL PROTECTED] writes:
Does the patch below have any influence?
The patch was necessary to run a52 plugin on emu10k1 on my test
system.
No, sorry. AC3 output is still practically cut off when I run md5sum.
Takashi Iwai [EMAIL PROTECTED] writes:
Then check the buffer and period sizes of the PCM stream by checking
/proc/asound/card0/pcm2p/sub0/hw_params.
Here we go:
$ sudo cat /proc/asound/card0/pcm2p/sub0/hw_params
access: RW_INTERLEAVED
format: S16_LE
subformat: STD
channels: 2
rate: 48000
At Wed, 06 Sep 2006 20:29:39 +0200,
Dominique Dumont wrote:
Takashi Iwai [EMAIL PROTECTED] writes:
Then check the buffer and period sizes of the PCM stream by checking
/proc/asound/card0/pcm2p/sub0/hw_params.
Here we go:
$ sudo cat /proc/asound/card0/pcm2p/sub0/hw_params
access:
Andrew Lyon [EMAIL PROTECTED] writes:
as root cat /proc/interrupts , are your onboard sata and spdif sharing
interrupt? if so try changing bios settings or moving it into another
slot to change the interrupt.
No. they do not share the same interrupt. sata/libata is on irq
201. The SB
Andrew Lyon [EMAIL PROTECTED] writes:
You are using APIC, the only thing i can suggest is to try without apic.
No change at all. The ac3 stream still has so many drop-out it's quasi
mute.
Here's the command (with output) that I used:
$ ac3dec -C en.ac3
Using PCM device
Hello
While watching hi-definitions video, I've noticed a lots of audio
drop-outs when watching movies with raw ac3 on spdif output (ac3
decoding is done by my Yamaha amplifier).
Long story short, I've been able to reproduce the problem when playing
a raw ac3 stream with ac3dec while
Andrew Lyon [EMAIL PROTECTED] writes:
as root cat /proc/interrupts , are your onboard sata and spdif sharing
interrupt? if so try changing bios settings or moving it into another
slot to change the interrupt.
No. they do not share the same interrupt. sata/libata is on irq
201. The SB sound
Hello
While watching hi-definitions video, I've noticed a lots of audio
drop-outs when watching movies with raw ac3 on spdif output (ac3
decoding is done by my Yamaha amplifier).
Long story short, I've been able to reproduce the problem when playing
a raw ac3 stream with ac3dec while loading
21 matches
Mail list logo
