Subject: RE: [linux-audio-user] The trouble with disks
From: Mark Knecht (markknecht_AT_comcast.net)
Date: Fri Dec 19 2003 - 15:34:24 EET
On Thu, 2003-12-18 at 23:24, John Anderson wrote:
> > A quick calculation: 44.1K samples/second * 24-bits/sample = 132.3K
> > Bytes/Sec for a mono channel. At only 8 channels you'd barely be over
> > 1MB/Sec in streaming bandwidth. (2MB/Sec if they are stereo.) Certainly your
> > disk can handle that if the system cooperates.
>
> iostat tells me it's reading < 1Mb/sec. hdparm tells me the disk can do
> 50Mb/sec. iostat and my ears tell me that whenever there's a dropout,
> the system is spending about 6% of it's time in iowait.
>
> > I suspect the problem is something else....
>
> What are the other options? I've looked at PCI latencies for card and
> drive controller, IRQ ordering (although APIC seems to make this
> irrelevant, or at least uncontrollable), OS disk scheduler
> (anticipatory, deadline and cfq), tagged queueing (high values almost
> guarantee xruns on recording but don't seem to improve playback).
>
> Sheesh, at this rate if I get another dual-processor machine, I'll be
> able to run jackd at -p 16 -n 2 :-|
A dual-processor system won't necessarily change a disk latency problem.
Have you tried running with larger buffers? Sorry but I don't have the
original post. Try -p 2048 -n 2 or -p 1024 -n 2 or -p 512 -n 4/8/16 if
your card accepts it and see what happens. Possibly there is just a
better setting to be using.
Also, have you run Benno's latency test app? It's good at showing
problems like other apps stepping in and causing problems somewhere, and
it can guide you towards the best -p/-n settings.
- Mark
This archive was generated by hypermail 2b28 : Fri Dec 19 2003 - 15:33:23 EET