10 Sep
2004
10 Sep
'04
10:17 a.m.
Has anyone had a "good" experience installinga multiface with a Linux
laptop? I am ready to purchase a laptop and I am so skiddish of
realtime Linux laptop audio with a multiface that I am considering
purchasing a Mac. Any success stories with laptop model numbers would
be really great info here!
Thanks!
Matt
--
----
Matthew Polashek
Home e-mail: matt(a)tinysongs.com
URL: www.tinysongs.com
12 Sep
12 Sep
8:44 p.m.
My experiences are doco'd here:
http://danharper.org/Linux_on_the_IBM_ThinkPad_R50.html
Some more info (which hasn't made the doco yet):
Last Saturday I recorded a band in the studio. In total we did 8 analog
in, 5 analog out, 2 SPDIF out.
In a live recording sense, it worked sort of OK. The only thing I had
trouble with were random xruns that started to appear half way through
the day.
Overall, it works, but there are a few minor things that I don't like:
- I have to unload/reload the Cardbus/ALSA/HDSP after I boot, re-assign
IRQs etc. Not sure why, but I haven't got time to wade through Fedora's
config mess to fix it properly (I just run a script after I login to fix
it).
- xruns are $%*^& (really annoying). I still get them every now and
again, but I may have tracked it down to using a reiserfs filesystem.
I've now switched to ext2 and there are less xruns now.
- Is there an easy way to set mixer levels and config of the HDSP to
restore on bootup? I haven't looked too hard, but it seems a pain (I
use SPDIF optical as my main monitoring, so I have to enable SPDIF on
ADAT and set the levels every time).
- Ardour/JAMin/LADSPA/Jack etc etc "magically" get more bugs the more
you use them and rely on them for a finished project. Some are REALLY
driving me nuts. Apps dying is a common occurrence. If you're looking
at reliability, Linux audio is currently not the place for it. Some
people may disagree with this, and I can see why. If you're doing
simple stuff, then fine. But when you start utilising 10-12 tracks/7
buses/(sends don't work) in Ardour and LADSPA plugins/mastering. The
process falls apart real quick.
If you're looking for reliability, then wait, or bite the bullet if
you're willing to accept the cost.
The weird thing is, that Linux has this "pull", based on it's
philosophy. Once the software begins to further stabilise, then there
will be happiness. I've been tempted every time I'm trying to just get
something done without a crash to go to windows or something, but I'm
hooked on the concepts. Jack, Ardour, JAMin, Hydrogen, Zynaddsubfx,
LADSPA, all potentially great apps with source available, quick bug
fixes and an open community. There is enough here to keep me here and
not wander off to windows land. I'm just hanging out for these apps to
stabilise and offer what they are aiming for. Then I can more easily
make some music, which is all good.
Dan
On Sat, 2004-09-11 at 00:00, Matthew Polashek wrote:
Has anyone had a "good" experience
installinga multiface with a Linux
laptop? I am ready to purchase a laptop and I am so skiddish of
realtime Linux laptop audio with a multiface that I am considering
purchasing a Mac. Any success stories with laptop model numbers would
be really great info here!
Thanks!
Matt
--
Dan Harper
http://danharper.org
9:37 p.m.
On Sun, 2004-09-12 at 17:00, Dan Harper wrote:
<SNIP>
Last Saturday I recorded a band in the studio. In
total we did 8 analog
in, 5 analog out, 2 SPDIF out.
In a live recording sense, it worked sort of OK. The only thing I had
trouble with were random xruns that started to appear half way through
the day.
<SNIP>
- xruns are $%*^& (really annoying). I still get
them every now and
again, but I may have tracked it down to using a reiserfs filesystem.
I've now switched to ext2 and there are less xruns now.
<SNIP>
Dan,
I wonder how what you were using for an audio drive and how full it
was?
I did a two night session using Pro Tools back in late April. The
equivalent of an xrun in that environment is an 'Interrupts held off too
long' message. I didn't receive a single one in 5 hours of recording. A
couple of months later, using the same laptop, the same 002 Rack, and
the same disk drive we blew 3 takes early in the evening due to
interrupts being held off.
Looking at my drive I saw it was about 90% full. As this is a FAT32
drive that implied more fragmentation. I then deleted about 20% of the
drive that was backed up elsewhere, did a quick drive optimization, and
15 minutes later we started recording again. We recorded for 2 1/2 hours
without a problem.
While none of this directly applicable to what you are experiencing,
when I read your note it seemed similar enough to go ahead and write
back. It might not only be the type of files system, but also where on
the drive you are writing. It's not always that well known, but most
drives are 30-50% slower at the far end of the drive. Most drives are
speed rated when they are empty.
Good luck fixing your problems. Sounds like you're going down a good
path.
BTW - On guy recently built a 7200RPM 200GB 1394b S800 drive and
tested it under Linux. He got 55MB/s. On the same machine I thin he was
getting about 45MB/s from his 10K RPM SCSI drive. There are options...
Cheers,
Mark
11:04 p.m.
Mark Knecht wrote:
While none of this directly applicable to what you
are experiencing,
when I read your note it seemed similar enough to go ahead and write
back. It might not only be the type of files system, but also where on
the drive you are writing. It's not always that well known, but most
drives are 30-50% slower at the far end of the drive. Most drives are
speed rated when they are empty.
Without knowing anything about the details of
hard drive conception, I would think that ALL
drives are much slower for tracks near the
axe than on the border of the disks, since
the speed is proportional to the distance track->axe.
This is inherent to any system using a disk and having
constant angular speed.
I know that even windows
95 tried to put the data on the borders of the disks of
an hard drive as long as it could. I am pretty sure linux does the same.
cheers,
David
13 Sep
13 Sep
12:01 a.m.
On Sun, 2004-09-12 at 19:49, Cournapeau David (ENST) wrote:
Mark Knecht wrote:
Yep - that, and also that as a drive becomes more full it also naturally
becomes more fragmented, and fragmentation causes more drive head
movement seeking out places to put data.
It all ends up working against you and it a good reason to clean up
disks now and again, assuming that your file system doesn't do it for
you automatically. (I'm unclear about this aspect of Linux file systems.
Possibly some do this automatically, either in real time or
periodically. Much to learn...)
While none of this directly applicable to what
you are experiencing,
when I read your note it seemed similar enough to go ahead and write
back. It might not only be the type of files system, but also where on
the drive you are writing. It's not always that well known, but most
drives are 30-50% slower at the far end of the drive. Most drives are
speed rated when they are empty.
Without knowing anything about the details of
hard drive conception, I would think that ALL
drives are much slower for tracks near the
axe than on the border of the disks, since
the speed is proportional to the distance track->axe.
This is inherent to any system using a disk and having
constant angular speed.
I know that even windows
95 tried to put the data on the borders of the disks of
an hard drive as long as it could. I am pretty sure linux does the same.
cheers,
David 
12:28 a.m.
On Sun, 2004-09-12 at 23:44, Mark Knecht wrote:
On Sun, 2004-09-12 at 19:49, Cournapeau David (ENST)
wrote:
Many file systems also switch from their normal, fast layout algorithms
to a slower but more space efficient scheme when they reach 90% full. I
believe the BSD FFS was the first file system to do this, and large
parts of Windows are known to be copied from BSD.
Lee
Mark Knecht wrote:
Yep - that, and also that as a drive becomes more full it also naturally
becomes more fragmented, and fragmentation causes more drive head
movement seeking out places to put data.
While none of this directly applicable to what
you are experiencing,
when I read your note it seemed similar enough to go ahead and write
back. It might not only be the type of files system, but also where on
the drive you are writing. It's not always that well known, but most
drives are 30-50% slower at the far end of the drive. Most drives are
speed rated when they are empty.
Without knowing anything about the details of
hard drive conception, I would think that ALL
drives are much slower for tracks near the
axe than on the border of the disks, since
the speed is proportional to the distance track->axe.
This is inherent to any system using a disk and having
constant angular speed.
I know that even windows
95 tried to put the data on the borders of the disks of
an hard drive as long as it could. I am pretty sure linux does the same.
1:31 a.m.
On Sun, Sep 12, 2004 at 08:44:48PM -0700, Mark Knecht wrote:
It all ends up working against you and it a good
reason to clean up
disks now and again, assuming that your file system doesn't do it for
you automatically. (I'm unclear about this aspect of Linux file systems.
Possibly some do this automatically, either in real time or
periodically. Much to learn...)
This might be interesting:
http://www.osnews.com/story.php?news_id=69
--
Paul Winkler
http://www.slinkp.com
7510
days inactive
7513
days old
linux-audio-user@lists.linuxaudio.org
6 comments
6 participants
participants (6)
-
Cournapeau David (ENST) -
Dan Harper -
Lee Revell -
Mark Knecht -
Matthew Polashek -
Paul Winkler