On Sat, 20 Mar 2004, Lars Heineken wrote:
>
> > It's related to the snd-ice1712 driver and hardware which has the cs8427
> > transciever. I've added cs8427_timeout module option, so you can
> > lower the reset timeout value for this chip. I left the safe value 50 (0.5
> > sec) as default. If yo
It affects both, but ALSA API does the setup of stream parameters once,
but OSS API does this multiple times because there is no way to distict
the configuration phase and the working phase, thus we must reconfigure
after settings of all parameters.
If you strace aplay then you'll see that one A
> It's related to the snd-ice1712 driver and hardware which has the cs8427
> transciever. I've added cs8427_timeout module option, so you can
I have M-Audio Audiophile and suffer from this also, but I'm not sure if
it has cs8427.
2.4.24 with ll+pe
alsa 0.9.8
If I'm not totally wrong, the earlie
On Sat, 20 Mar 2004, Tommi Sakari Uimonen wrote:
> > It's related to the snd-ice1712 driver and hardware which has the cs8427
> > transciever. I've added cs8427_timeout module option, so you can
>
> I have M-Audio Audiophile and suffer from this also, but I'm not sure if
> it has cs8427.
It has
It's related to the snd-ice1712 driver and hardware which has the cs8427
transciever. I've added cs8427_timeout module option, so you can
lower the reset timeout value for this chip. I left the safe value 50 (0.5
sec) as default. If you set this timeout to very small value, then
the S/PDIF outpu
On Sat, 20 Mar 2004, Lars Heineken wrote:
> As each and every oss-program on my machine suffers from this unusual
> delay I think it doesn't make much sense to write a sample program, but
> anyway, it's attached.
It's related to the snd-ice1712 driver and hardware which has the cs8427
transcie
0.000531 ioctl(4, SNDCTL_DSP_RESET, 0) = 0
0.000232 ioctl(4, SNDCTL_DSP_GETFMTS, 0xb668) = 0
0.510506 ioctl(4, SNDCTL_DSP_SETFMT, 0xb668) = 0
0.506515 ioctl(4, SNDCTL_DSP_STEREO, 0xb668) = 0
0.504940 ioctl(4, SOUND_PCM_READ_RATE, 0xb668) = 0
0.065604 io
Lars Heineken wrote:
I used the latest alsa-tarballs to upgrade alsa-lib, alsa-driver and
alsa-oss.
To make it short: The problem is even worse now !
This is the output from strace (relevant part):
.
.
0.000531 ioctl(4, SNDCTL_DSP_RESET, 0) = 0
0.000232 ioctl(4, SNDCTL_DSP_GE
I used the latest alsa-tarballs to upgrade alsa-lib, alsa-driver and
alsa-oss.
To make it short: The problem is even worse now !
This is the output from strace (relevant part):
.
.
0.000531 ioctl(4, SNDCTL_DSP_RESET, 0) = 0
0.000232 ioctl(4, SNDCTL_DSP_GETFMTS, 0xb668) =
I really want to resolve this bug, but there has been little help so
far. I haven't got any response from Perex, too. He was asigned to this
bug via alsa bug report...
Please, someone needs to tell me wich modules are connected with the
functions that took so long, so I can check revision of tt
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Lars Heineken wrote:
| I'll figure out how the script works and make the trace when I get home.
| (~9 hours).
All set, here we go:
The script calls this line:
sox 01.wav -t ossdsp /dev/dsp
After adding an "strace -r" to the beginning I got the follo
Lars Heineken wrote:
> Takashi Iwai wrote:
>
> | try strace with -r option and check which call takes too long time.
>
> When I use the application 'play' the delay is only around one second,
> the strace output is attached below.
It seems play is a shell script that calls sox to play the file.
Pl
Clemens Ladisch wrote:
It seems play is a shell script that calls sox to play the file.
Please try to strace sox.
Oh, you are right ! I guess that was the reason why there was so little
alsa related stuff in the trace..
I'll figure out how the script works and make the trace when I get home.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Takashi Iwai wrote:
| try strace with -r option and check which call takes too long time.
I have tried to run the application with the longest delay (~5 seconds)
using 'strace -r' wich is an X-application. Unfortunately, it spills out
a lot of text (~
At Sat, 13 Mar 2004 21:01:05 +0100,
Lars Heineken wrote:
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Hi !
>
> I switched from 2.4 to 2.6 a few days ago and noticed this strange
> problem. Whatever program uses OSS-emulation takes 1-3 seconds to open
> /dev/dsp and start playing sound
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi !
I switched from 2.4 to 2.6 a few days ago and noticed this strange
problem. Whatever program uses OSS-emulation takes 1-3 seconds to open
/dev/dsp and start playing sound. It seems that this has something to do
with the preemptive kernel option, b
16 matches
Mail list logo
