8 Apr
2007
8 Apr
'07
12:03 a.m.
Paul Davis wrote:
On Thu, 2007-04-05 at 02:00 -0400, Spencer Russell
wrote:
>
> What could cause clicks without xruns? I'm baffled.
PCI bus hogging, for one thing. consider running a
script like this
during system startup (mine is in /etc/rc.d/init.d/pcilatency). yours
would need adjusting to reflect the PCI IDs of the actual interfaces you
have installed.
#!/bin/sh
case $1 in
start)
# "open up" the PCI bus by allowing fairly long bursts for
all devices, increasing performance
setpci -v -s "*:*.*" latency_timer=b0
# maximise latency for RME Hammerfall, thus
allowing
# more data per PCI transfer and minimizing xfuns
setpci -v -s 01:04.0 latency_timer=ff
# ditto for the onboard AC97 audio interface
setpci -v -s 00:07.5 latency_timer=ff
esac
Here one that works automatically for all multimedia devices:
# find multimedia devices
pcis=$(lspci -v | grep Multimedia | awk '{ print $1; }')
if test -z "$pcis"; then
echo WARNING: no multimedia devices found on pci bus
else
for p in $pcis; do
echo set maximum latency timer for $p
setpci -s $p latency_timer=ff
done
fi
HTH
8 Apr
8 Apr
9:38 a.m.
New subject: Pops and clicks but no xruns
Andrew Burgess <aab(a)cichlid.com>om>:
Paul Davis wrote:
>> What could cause clicks without xruns? I'm baffled.
>PCI bus hogging, for one thing. consider running a script like this
...
Here one that works automatically for all multimedia
devices:
# find multimedia devices
pcis=$(lspci -v | grep Multimedia | awk '{ print $1; }')
if test -z "$pcis"; then
echo WARNING: no multimedia devices found on pci bus
else
for p in $pcis; do
echo set maximum latency timer for $p
setpci -s $p latency_timer=ff
done
fi
It does not work for me:
$ lspci | grep Multi | head -1 | cut -b-75
0000:00:05.0 Multimedia audio controller: nVidia Corporation nForce MultiMe
$ setpci -s 0000:00:05.0 latency_timer
lspci: -s: Invalid slot number
$ setpci -s 00:05.0 latency_timer
00
I have to remove the first 0000: from lspci, as in:
$ cat /usr/local/sbin/pci.set.audio
#!/bin/sh
val=${1:-ff}
# find multimedia devices
pcis=$( lspci -n | grep ' 0401: ' | cut -f1 -d\ | cut -f2- -d: )
if test -z "$pcis"; then
echo WARNING: no multimedia devices found on pci bus
else
for p in $pcis; do
lspci -s $p
echo -en \\tmaximum latency timer:\
setpci -s $p latency_timer | tr -s ' \n' ' '
setpci -s $p latency_timer=$val > /dev/null
echo -n '-> '
setpci -s $p latency_timer
done
fi
$
Though all devices does not change:
# pci.set.audio | cut -b-68
0000:00:05.0 Multimedia audio controller: nVidia Corporation nForce
maximum latency timer: 00 -> 00
0000:00:06.0 Multimedia audio controller: nVidia Corporation nForce2
maximum latency timer: 00 -> 00
0000:01:09.0 Multimedia audio controller: VIA Technologies Inc. ICE1
maximum latency timer: 00 -> f8
#
Regards,
/Karl
-----------------------------------------------------------------------
Karl Hammar Aspö Data karl(a)aspodata.se
Lilla Aspö 2340 Networks
S-742 94 Östhammar +46 173 140 57 Computers
Sweden +46 70 511 97 84 Consulting
-----------------------------------------------------------------------
2:51 p.m.
New subject: Pops and clicks but no xruns
On Sun, Apr 08, 2007 at 01:38:34PM +0200, Karl Hammar wrote:
Andrew Burgess <aab(a)cichlid.com>om>:
I am slightly confused. Is it necessary to increase the latency
timer for a pci sound card? This seems slightly
counter-intuitive. Wouldn't this reduce the performance of the
sound system through that card?
The only thing the above script changes on my system is the
latency of the SB Live.
James
Paul Davis wrote:
>> What could cause clicks without xruns? I'm baffled.
>PCI bus hogging, for one thing. consider running a script like this
...
Here one that works automatically for all
multimedia devices:
# find multimedia devices
pcis=$(lspci -v | grep Multimedia | awk '{ print $1; }')
if test -z "$pcis"; then
echo WARNING: no multimedia devices found on pci bus
else
for p in $pcis; do
echo set maximum latency timer for $p
setpci -s $p latency_timer=ff
done
fi
It does not work for me:
$ lspci | grep Multi | head -1 | cut -b-75
0000:00:05.0 Multimedia audio controller: nVidia Corporation nForce MultiMe
$ setpci -s 0000:00:05.0 latency_timer
lspci: -s: Invalid slot number
$ setpci -s 00:05.0 latency_timer
00
I have to remove the first 0000: from lspci, as in:
$ cat /usr/local/sbin/pci.set.audio
#!/bin/sh
val=${1:-ff}
# find multimedia devices
pcis=$( lspci -n | grep ' 0401: ' | cut -f1 -d\ | cut -f2- -d: )
if test -z "$pcis"; then
echo WARNING: no multimedia devices found on pci bus
else
for p in $pcis; do
lspci -s $p
echo -en \\tmaximum latency timer:\
setpci -s $p latency_timer | tr -s ' \n' ' '
setpci -s $p latency_timer=$val > /dev/null
echo -n '-> '
setpci -s $p latency_timer
done
fi
$
7:40 p.m.
New subject: Pops and clicks but no xruns
James Stone <jamesmstone(a)gmail.com>om>:
On Sun, Apr 08, 2007 at 01:38:34PM +0200, Karl Hammar
wrote:
> Andrew Burgess <aab(a)cichlid.com>om>:
> > Paul Davis wrote:
> > >> What could cause clicks without xruns? I'm baffled.
> > >PCI bus hogging, for one thing. consider running a script like this
> ...
> > setpci -s $p latency_timer=ff
...
I am slightly confused. Is it necessary to increase
the latency
timer for a pci sound card? This seems slightly
counter-intuitive. Wouldn't this reduce the performance of the
sound system through that card?
Performance and latency is different things. In audio we accept all
latencies below 30ms (I think), less than that does not gain anything.
But we can gain bandwith by using longer bursts, thus a higher latency
(within bounds) gives us greater performance.
The only thing the above script changes on my system
is the
latency of the SB Live.
Yes, I missed the general setting seen below.
Paul Davis in the message that started this thread:
#!/bin/sh
case $1 in
start)
# "open up" the PCI bus by allowing fairly long bursts for
all devices, increasing performance
setpci -v -s "*:*.*" latency_timer=b0
# maximise latency for RME Hammerfall, thus allowing
# more data per PCI transfer and minimizing xfuns
setpci -v -s 01:04.0 latency_timer=ff
# ditto for the onboard AC97 audio interface
setpci -v -s 00:07.5 latency_timer=ff
esac
Regards,
/Karl
-----------------------------------------------------------------------
Karl Hammar Aspö Data karl(a)aspodata.se
Lilla Aspö 2340 Networks
S-742 94 Östhammar +46 173 140 57 Computers
Sweden +46 70 511 97 84 Consulting
-----------------------------------------------------------------------
8:35 p.m.
New subject: Pops and clicks but no xruns
On Sun, 2007-04-08 at 23:39 +0200, Karl Hammar wrote:
James Stone <jamesmstone(a)gmail.com>om>:
no, this is not really accurate.
the PCI latency timer determines how long a device may own the PCI bus
for, it has nothing to do with audio latency. therefore, if your system
allowed the video interface to hog the PCI bus for a relatively long
time, but limited the audio interface to only short periods of bus
ownership, then audio performance will suffer.
the script i posted first resets *all* devices to an acceptable
middle-of-the-road timer setting, then specifically allows the audio
interfaces to own the bus for even longer.
On Sun, Apr 08, 2007 at 01:38:34PM +0200, Karl
Hammar wrote:
> Andrew Burgess <aab(a)cichlid.com>om>:
> > Paul Davis wrote:
> > >> What could cause clicks without xruns? I'm baffled.
> > >PCI bus hogging, for one thing. consider running a script like this
> ...
> > setpci -s $p latency_timer=ff
...
I am slightly confused. Is it necessary to
increase the latency
timer for a pci sound card? This seems slightly
counter-intuitive. Wouldn't this reduce the performance of the
sound system through that card?
Performance and latency is different things. In audio we accept all
latencies below 30ms (I think), less than that does not gain anything.
But we can gain bandwith by using longer bursts, thus a higher latency
(within bounds) gives us greater performance.
9:05 p.m.
New subject: Pops and clicks but no xruns
Performance and latency is different things. In audio we accept all
latencies below 30ms (I think), less than that does not gain anything.
But we can gain bandwith by using longer bursts, thus a higher latency
(within bounds) gives us greater performance.
no, this is not really accurate.
the PCI latency timer determines how long a device may own the PCI bus
for, it has nothing to do with audio latency. therefore, if your system
allowed the video interface to hog the PCI bus for a relatively long
time, but limited the audio interface to only short periods of bus
ownership, then audio performance will suffer.
the script i posted first resets *all* devices to an acceptable
middle-of-the-road timer setting, then specifically allows the audio
interfaces to own the bus for even longer.
9:29 p.m.
New subject: Pops and clicks but no xruns
On 4/8/07, Paul Davis <paul(a)linuxaudiosystems.com> wrote:
the PCI latency timer determines how long a device may own the PCI bus
for, it has nothing to do with audio latency. therefore, if your system
allowed the video interface to hog the PCI bus for a relatively long
time, but limited the audio interface to only short periods of bus
ownership, then audio performance will suffer.
the script i posted first resets *all* devices to an acceptable
middle-of-the-road timer setting, then specifically allows the audio
interfaces to own the bus for even longer.
How critical is tuning the PCI latency? In my reading about getting
low latency set up, I've never heard of this part of it before. Thanks
for the great info, Paul!
-spencer
6468
days inactive
6469
days old
linux-audio-user@lists.linuxaudio.org
6 comments
5 participants
participants (5)
-
Andrew Burgess -
James Stone -
karl＠aspodata.se -
Paul Davis -
Spencer Russell