30 Nov
2010
30 Nov
'10
9:59 a.m.
Hi all,
I don't know if this is a known issue or something fixed in recent
kernels, but I recently found a fix for a problem I was having with my
harddisk spinning down in live performances, and then loading samples
from disk:
http://www.pawfal.org/dave/blog/2010/11/jackd-performances-and-harddisks/
Also, while I'm here, this was the performance in which I tested the fix
(slub livecoding at Piksel a couple of weeks ago):
http://giss.tv/dmmdb//player.php?ID=1450&mode_clip&autoplay=no&…
cheers,
dave
30 Nov
30 Nov
1:57 p.m.
On Tue, Nov 30, 2010 at 4:59 AM, David Griffiths <dave(a)pawfal.org> wrote:
Hi all,
I don't know if this is a known issue or something fixed in recent
kernels, but I recently found a fix for a problem I was having with my
harddisk spinning down in live performances, and then loading samples
from disk:
http://www.pawfal.org/dave/blog/2010/11/jackd-performances-and-harddisks/
lets not forget the other issue with hard drives: massively reduced
performance caused by exposure to excessively loud audio. this is well
documented. if you play live (or even in a studio) make sure that the
disk drive(s) are well isolated from extremely loud sounds. the
read/write failure rate goes up dramatically and the effective
streaming rate of the driver suffers. it can be enough to just put the
disk into a drawer.
2:47 p.m.
On 11/30/2010 02:57 PM, Paul Davis wrote:
On Tue, Nov 30, 2010 at 4:59 AM, David Griffiths
<dave(a)pawfal.org> wrote:
fwiw, the manufacturer of the grandMA range of lighting desks used to
(and probably still does) recommend that backups (to the internal hd)
not be attempted during periods of high sound pressure level. :)
Hi all,
I don't know if this is a known issue or something fixed in recent
kernels, but I recently found a fix for a problem I was having with my
harddisk spinning down in live performances, and then loading samples
from disk:
http://www.pawfal.org/dave/blog/2010/11/jackd-performances-and-harddisks/
lets not forget the other issue with hard drives: massively reduced
performance caused by exposure to excessively loud audio. this is well
documented. if you play live (or even in a studio) make sure that the
disk drive(s) are well isolated from extremely loud sounds. the
read/write failure rate goes up dramatically and the effective
streaming rate of the driver suffers. it can be enough to just put the
disk into a drawer.
2:57 p.m.
On Tue, 2010-11-30 at 08:57 -0500, Paul Davis wrote:
On Tue, Nov 30, 2010 at 4:59 AM, David Griffiths
<dave(a)pawfal.org> wrote:
I'd not noticed this. It makes sense though. I was once cheerfully told
about very loud bassy sounds causing disk heads to hit platters when I
was just about to start doing visuals at a squat party with an outsized
sound system playing dubstep. That was amusing.
cheers,
dave
Hi all,
I don't know if this is a known issue or something fixed in recent
kernels, but I recently found a fix for a problem I was having with my
harddisk spinning down in live performances, and then loading samples
from disk:
http://www.pawfal.org/dave/blog/2010/11/jackd-performances-and-harddisks/
lets not forget the other issue with hard drives: massively reduced
performance caused by exposure to excessively loud audio. this is well
documented. if you play live (or even in a studio) make sure that the
disk drive(s) are well isolated from extremely loud sounds. the
read/write failure rate goes up dramatically and the effective
streaming rate of the driver suffers. it can be enough to just put the
disk into a drawer. 
1 Dec
1 Dec
12:12 p.m.
On Tue, Nov 30, 2010 at 11:59:37AM +0200, David Griffiths wrote:
Hi all,
I don't know if this is a known issue or something fixed in recent
kernels, but I recently found a fix for a problem I was having with my
harddisk spinning down in live performances, and then loading samples
from disk:
http://www.pawfal.org/dave/blog/2010/11/jackd-performances-and-harddisks/
apart from just preventing your harddisk from spinning down, you could
also have increased the -t timeout value.
the semantics of --nozombies only prevent zombification of clients which
dont respond to audiocallbacks in time.
if the client hits the request timeout for normal requests it gets
zombified.
its been a long time since i have seen these kinds of lockups.
what kernel are you using ?
Also, while I'm here, this was the performance in which I tested the fix
(slub livecoding at Piksel a couple of weeks ago):
http://giss.tv/dmmdb//player.php?ID=1450&mode_clip&autoplay=no&…
cheers,
dave
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev
--
torben Hohn
4566
days inactive
4567
days old
linux-audio-dev@lists.linuxaudio.org
4 comments
4 participants
participants (4)
-
David Griffiths -
Jörn Nettingsmeier -
Paul Davis -
torbenh