19 Nov
2008
19 Nov
'08
6:16 p.m.
Hi
I hope for answers, even though my problematic application is not open
source, so here goes:
I haven't done any recording with ardour on this box, so I have nothing
to compare with, but my DAW, energyXT, seems to dislike playing back 10+
audio tracks at the same time. I'm wondering if there are any
measurements and adjustments (changing priorities of interrupts, or
setting something in the lo level disk io-something) that in general
would allow realtim jack clients to perform better when reading from the
disc?
Of course, since my DAW is closed source, it could simply just be that
it is poorly written, only the author would know :-(
Any input appreciated.
--
Atte
http://atte.dk http://modlys.dk
19 Nov
19 Nov
8:49 p.m.
On Wed, Nov 19, 2008 at 5:16 PM, Atte André Jensen
<atte.jensen(a)gmail.com> wrote:
I haven't done any recording with ardour on this
box, so I have nothing
to compare with, but my DAW, energyXT, seems to dislike playing back 10+
audio tracks at the same time. I'm wondering if there are any
measurements and adjustments (changing priorities of interrupts, or
setting something in the lo level disk io-something) that in general
would allow realtim jack clients to perform better when reading from the
disc?
What format are the tracks in? 16 bit, 44.1Khz is 0.7MB/sec per track
which any drive
should be able to handle 10 tracks of. But with 96Khz and 24 or 32
bit samples, you
could be pushing the limits of the drive.
What does running hdparm -Tt on the block device (/dev/sdX) give you?
Realtime tuning should not matter because with any sanely written DAW the disk
IO will be done in it's own non-RT thread.
Lee
20 Nov
20 Nov
4:01 a.m.
Lee Revell wrote:
What format are the tracks in? 16 bit, 44.1Khz is
0.7MB/sec per track
which any drive
should be able to handle 10 tracks of. But with 96Khz and 24 or 32
bit samples, you
could be pushing the limits of the drive.
It's 16 bits, 44khz
What does running hdparm -Tt on the block device
(/dev/sdX) give you?
atte@vestbjerg:~$ sudo hdparm -Tt /dev/sda
/dev/sda:
Timing cached reads: 1862 MB in 2.00 seconds = 931.56 MB/sec
Timing buffered disk reads: 142 MB in 3.00 seconds = 47.29 MB/sec
How does that sound?
Realtime tuning should not matter because with any
sanely written DAW the disk
IO will be done in it's own non-RT thread.
Ok
I experimented further, and it's not only the number of audio tracks
that seems to be the problem. Other cpu intensive stuff like soft synths
and fx bring the cup usage up. But I still feel that many audio tracks
take more cpu than they're supposed to.
--
Atte
http://atte.dk http://modlys.dk
7:39 a.m.
Quoting Atte André Jensen <atte.jensen(a)gmail.com>om>:
atte@vestbjerg:~$ sudo hdparm -Tt /dev/sda
/dev/sda:
Timing cached reads: 1862 MB in 2.00 seconds = 931.56 MB/sec
Timing buffered disk reads: 142 MB in 3.00 seconds = 47.29 MB/sec
How does that sound?
Those numbers seem about right. The three disks in my PC at work show:
sda: Samsung SpinPoint SP0411C 40GB SATA/150 7200RPM 2MB HDD
/dev/sda:
Timing cached reads: 2920 MB in 2.00 seconds = 1460.18 MB/sec
Timing buffered disk reads: 150 MB in 3.02 seconds = 49.72 MB/sec
sdb: Seagate Barracuda ST380011A IDE 80 GB
/dev/sdb:
Timing cached reads: 2836 MB in 2.00 seconds = 1417.47 MB/sec
Timing buffered disk reads: 80 MB in 3.02 seconds = 26.45 MB/sec
sdc: MAXTOR 4G120J6 IDE 120.0GB
/dev/sdc:
Timing cached reads: 2920 MB in 2.00 seconds = 1460.83 MB/sec
Timing buffered disk reads: 80 MB in 3.07 seconds = 26.09 MB/sec
I think the IDE drives should be faster but I haven't got an ATA-100
cable so that might be the culprit.
- Peder
7:51 a.m.
Quoting Peder Hedlund <peder(a)musikhuset.org>rg>:
Those numbers seem about right. The three disks in my
PC at work show:
sda: Samsung SpinPoint SP0411C 40GB SATA/150 7200RPM 2MB HDD
/dev/sda:
Timing cached reads: 2920 MB in 2.00 seconds = 1460.18 MB/sec
Timing buffered disk reads: 150 MB in 3.02 seconds = 49.72 MB/sec
Hmm, I tried using hdparm-9.3 (as opposed to the default 6.6) and the
cached reads dropped to short of 700. The buffered numbers remained
though.
- Peder
1:10 p.m.
Peder Hedlund wrote:
I think the IDE drives should be faster but I
haven't got an ATA-100
cable so that might be the culprit.
atte@vestbjerg:~$ lspci | grep ATA
00:1f.2 SATA controller: Intel Corporation 82801HBM/HEM (ICH8M/ICH8M-E)
SATA AHCI Controller (rev 03)
I don't know what box you're on, this is an (almost) new toshiba with
dualcore 2G and sata disc:
atte@vestbjerg:~$ lspci | grep ATA
00:1f.2 SATA controller: Intel Corporation 82801HBM/HEM (ICH8M/ICH8M-E)
SATA AHCI Controller (rev 03)
So I would expect my system to perform better, you're 50% more throghput
than me :-(
--
Atte
http://atte.dk http://modlys.dk
21 Nov
21 Nov
3:10 a.m.
Quoting Atte André Jensen <atte.jensen(a)gmail.com>om>:
I don't know what box you're on, this is an
(almost) new toshiba with
dualcore 2G and sata disc:
So I would expect my system to perform better, you're 50% more
throghput than me :-(
This is an semi-old Fujitsu Scenic P320 with a Celeron 2.8GHz.
If you noticed the followup to myself, hdparm 9.3 gave me a cached
read of ~690 and buffered around 50 so your numbers seem about right.
As for upping to 8.10, I have no idea, I use Mandriva and openSUSE myself.
However, looking closer at the bug report it seems related to ubuntu
not beeing able to detect and correctly use an 80-pin IDE cable so it
shouldn't relate to this matter.
I'd suggest you try Ardour or Traverso to see if they work better.
Also make sure you disable any cron job that might me running while
you record (like updatedb, part of the slocate system).
- Peder
10:52 p.m.
On Thu, Nov 20, 2008 at 12:10 PM, Atte André Jensen
<atte.jensen(a)gmail.com> wrote:
Peder Hedlund wrote:
The buffered number is the interesting one, not the cached.
Your disk seems fine. Are you running plugins on each track or just
playing them straight off disk?
If you're doing heavy DSP on 10+ tracks I would expect the behavior
you see. What's your JACK period size?
I agree that you should try Ardour to rule out a poorly written DAW.
Lee
I think the IDE drives should be faster but I
haven't got an ATA-100
cable so that might be the culprit.
So I would expect my system to perform better, you're 50% more throghput
than me :-(
20 Nov
20 Nov
8:01 a.m.
Quoting Atte André Jensen <atte.jensen(a)gmail.com>om>:
atte@vestbjerg:~$ sudo hdparm -Tt /dev/sda
/dev/sda:
Timing cached reads: 1862 MB in 2.00 seconds = 931.56 MB/sec
Timing buffered disk reads: 142 MB in 3.00 seconds = 47.29 MB/sec
Though the numbers seem OK, perhaps you're bitten by this bug:
https://bugs.launchpad.net/ubuntu/+bug/195221
- Peder
1:07 p.m.
Peder Hedlund wrote:
Though the numbers seem OK, perhaps you're bitten
by this bug:
https://bugs.launchpad.net/ubuntu/+bug/195221
That's a loong list of posts. Is it specefiv to ubuntu 8.04? Would
upgrading to 8.10 help? Other solutions?
--
Atte
http://atte.dk http://modlys.dk
22 Nov
22 Nov
12:02 a.m.
Atte André Jensen wrote:
Peder Hedlund wrote:
With my ATI SB600 SATA chipset I got a decent speed increase going from
8.04 to 8.10. My primary SATA drive went from around 50MB/sec on 8.04
to around 75MB/sec in 8.10 I think it is the 2.6.27.* kernel that makes
the difference as I noticed similar increases in Gentoo using 2.6.27
Also, although I didn't read all the posts, it appears that the above
bug applies to SSD and not hard drives.
HTH.
Regards,
Ross.
Though the numbers seem OK, perhaps you're
bitten by this bug:
https://bugs.launchpad.net/ubuntu/+bug/195221
That's a loong list of posts. Is it specefiv to ubuntu 8.04? Would
upgrading to 8.10 help? Other solutions?
6042
days inactive
6044
days old
linux-audio-user@lists.linuxaudio.org
10 comments
4 participants
participants (4)
-
Atte André Jensen -
Lee Revell -
Peder Hedlund -
Ross