12 Nov
2012
12 Nov
'12
8:02 p.m.
Hello list,
For the first time in my life I need to work with huge recordings, I
would like to understand how much memory and computing power is
required to handle it on a linux box with Ardour.
The recording, retrieved from an Alesis hd24, will be about 1 hour and
a half long, 24 channels, 44.1KHz, 16bit,
What are the minimal requirements to work with it?
If I choose sample rate and bit depth to be 48kHz/24bit, will it
require much more resources (other than disk space)?
Thank you!
--
Asa Marco <marcoasa90(a)gmail.com> 朝
12 Nov
12 Nov
8:17 p.m.
On Mon, Nov 12, 2012 at 3:10 PM, Asa Marco <aesir.ml(a)gmail.com> wrote:
Hello list,
For the first time in my life I need to work with huge recordings, I
would like to understand how much memory and computing power is
required to handle it on a linux box with Ardour.
The recording, retrieved from an Alesis hd24, will be about 1 hour and
a half long, 24 channels, 44.1KHz, 16bit,
What are the minimal requirements to work with it?
If I choose sample rate and bit depth to be 48kHz/24bit, will it
require much more resources (other than disk space)?
you could record that on a 400MHz Pentium II (i.e. a box about 12 years
old) - you don't need any big hardware to record data like that.
now, when it comes to editing, the question is a bit different, but the
*size* of the session in terms of duration is largely irrelevant. 24 tracks
is manageable on just about any modern machine. if you edit it so that
there end being hundreds or thousands of regions, that could cause issues,
but by itself, the data size isn't really significant.
what demands big resources are
* disk i/o, but 24 tracks should be manageable on any modern disk
* plugins, which use (potentially) lots of CPU while processing audio
without knowing plugins you plan to use, it is hard to predict what you
would need in terms of CPU power.
with no plugins, it would be hard to buy a computer today that could *not*
handle editing that session.
9:19 p.m.
On Mon, Nov 12, 2012 at 02:17:03PM -0500, Paul Davis wrote:
with no plugins, it would be hard to buy a computer
today that could *not*
handle editing that session.
True. I've been doing 30-track editing on a P4 system with 512 MB
memory, no problem at all, Ardour handled that very well. That was
just editing, mixing with a lot of plugins etc. could be another
matter.
The *only* case when I've seen it fail was strangely enough when
recording just a single stereo track on a dual quad-core machine
with 4GB of memory. Input was coming from firefox playing a Youtube
video, routed via ALSA's Jack plugin, and recording failed repeatedly
with 'your hard disk was not fast enough' messages. Yet that same
system does 80-track sessions without a wink. So I'm pretty sure
firefox is the one to blame here.
Ciao,
--
FA
A world of exhaustive, reliable metadata would be an utopia.
It's also a pipe-dream, founded on self-delusion, nerd hubris
and hysterically inflated market opportunities. (Cory Doctorow)
13 Nov
13 Nov
12:29 a.m.
On 11/12/2012 10:19 AM, Fons Adriaensen wrote:
On Mon, Nov 12, 2012 at 02:17:03PM -0500, Paul Davis
wrote:
Or Flash, if the track was playing through flash.
--
David
gnome(a)hawaii.rr.com
authenticity, honesty, community
http://clanjones.org/david/
http://dancing-treefrog.deviantart.com/
with no plugins, it would be hard to buy a
computer today that could *not*
handle editing that session.
True. I've been doing 30-track editing on a P4 system with 512 MB
memory, no problem at all, Ardour handled that very well. That was
just editing, mixing with a lot of plugins etc. could be another
matter.
The *only* case when I've seen it fail was strangely enough when
recording just a single stereo track on a dual quad-core machine
with 4GB of memory. Input was coming from firefox playing a Youtube
video, routed via ALSA's Jack plugin, and recording failed repeatedly
with 'your hard disk was not fast enough' messages. Yet that same
system does 80-track sessions without a wink. So I'm pretty sure
firefox is the one to blame here. 
12 Nov
12 Nov
10:18 p.m.
Am 12.11.2012 20:17, schrieb Paul Davis:
On Mon, Nov 12, 2012 at 3:10 PM, Asa Marco <aesir.ml(a)gmail.com
<mailto:aesir.ml@gmail.com>> wrote:
Hello list,
For the first time in my life I need to work with huge recordings, I
would like to understand how much memory and computing power is
required to handle it on a linux box with Ardour.
The recording, retrieved from an Alesis hd24, will be about 1 hour and
a half long, 24 channels, 44.1KHz, 16bit,
What are the minimal requirements to work with it?
If I choose sample rate and bit depth to be 48kHz/24bit, will it
require much more resources (other than disk space)?
you could record that on a 400MHz Pentium II (i.e. a box about 12 years
old) - you don't need any big hardware to record data like that.
now, when it comes to editing, the question is a bit different, but the
*size* of the session in terms of duration is largely irrelevant. 24
tracks is manageable on just about any modern machine. if you edit it so
that there end being hundreds or thousands of regions, that could cause
issues, but by itself, the data size isn't really significant.
what demands big resources are
* disk i/o, but 24 tracks should be manageable on any modern disk
* plugins, which use (potentially) lots of CPU while processing audio
without knowing plugins you plan to use, it is hard to predict what you
would need in terms of CPU power.
with no plugins, it would be hard to buy a computer today that could
*not* handle editing that session.
All true. 24 channels, 44kHz and 16bit should not cause problems on any
mid-recent machine. I routinely handle sessions with 24 channels, 48kHz,
24bit. Mostly about 6 busses. CPU-usage can then be a bit high if you
have dynamics and an 8-band-parametric EQ on every channel +
cpu-intensive plugins (ir_lv2, ...) on the busses.
Just try it out and you'll see how your CPU can cope with the DSP load.
Of course more RAM is better since you can cache disk-reads but as Paul
said: any recent machine should be able to get the work done.
Jannis
13 Nov
13 Nov
10:13 a.m.
Il giorno Mon, 12 Nov 2012 22:18:11 +0100
Jannis Achstetter <jannis_achstetter(a)web.de> ha scritto:
Am 12.11.2012 20:17, schrieb Paul Davis:
Ok, that's what i hoped, since i don't expect to make heavy signal
processing. I think I would not have any problem with it.
Thank you all for the kind responses.
--
Asa Marco <aesir.ml(a)gmail.com> 朝
On Mon, Nov 12, 2012 at 3:10 PM, Asa Marco <aesir.ml(a)gmail.com
<mailto:aesir.ml@gmail.com>> wrote:
Hello list,
For the first time in my life I need to work with huge
recordings, I would like to understand how much memory and
computing power is required to handle it on a linux box with Ardour.
The recording, retrieved from an Alesis hd24, will be about 1
hour and a half long, 24 channels, 44.1KHz, 16bit,
What are the minimal requirements to work with it?
If I choose sample rate and bit depth to be 48kHz/24bit, will it
require much more resources (other than disk space)?
you could record that on a 400MHz Pentium II (i.e. a box about 12
years old) - you don't need any big hardware to record data like
that.
now, when it comes to editing, the question is a bit different, but
the *size* of the session in terms of duration is largely
irrelevant. 24 tracks is manageable on just about any modern
machine. if you edit it so that there end being hundreds or
thousands of regions, that could cause issues, but by itself, the
data size isn't really significant.
what demands big resources are
* disk i/o, but 24 tracks should be manageable on any modern disk
* plugins, which use (potentially) lots of CPU while processing
audio
without knowing plugins you plan to use, it is hard to predict what
you would need in terms of CPU power.
with no plugins, it would be hard to buy a computer today that could
*not* handle editing that session.
All true. 24 channels, 44kHz and 16bit should not cause problems on
any mid-recent machine. I routinely handle sessions with 24 channels,
48kHz, 24bit. Mostly about 6 busses. CPU-usage can then be a bit high
if you have dynamics and an 8-band-parametric EQ on every channel +
cpu-intensive plugins (ir_lv2, ...) on the busses.
Just try it out and you'll see how your CPU can cope with the DSP
load.
Of course more RAM is better since you can cache disk-reads but as
Paul said: any recent machine should be able to get the work done.
Jannis
12 Nov
12 Nov
11:39 p.m.
On Mon, November 12, 2012 12:10 pm, Asa Marco wrote:
Hello list,
For the first time in my life I need to work with huge recordings, I
would like to understand how much memory and computing power is
required to handle it on a linux box with Ardour.
The recording, retrieved from an Alesis hd24, will be about 1 hour and
a half long, 24 channels, 44.1KHz, 16bit,
What are the minimal requirements to work with it?
If I choose sample rate and bit depth to be 48kHz/24bit, will it
require much more resources (other than disk space)?
To change things to 48k you would have to do that outside of ardour. I
would suggest against doing that except as a final step after mixdown as
any time differences from track to track in the resample would be
magnified by such a long track. Even in shorter cases stereo imaging could
be affected. It would be best to leave 44100 if at all possible. If the
end product _has_ to be 48k then expect a (hopefully small) loss in
quality.
Ardour will switch it to 32bit float internally whatever the input is to
allow mixing headroom. 24 bit is chosen at export time. However, again
this would be decided by the final delivery route.
--
Len Ovens
www.OvenWerks.net
13 Nov
13 Nov
10:27 a.m.
Il giorno Mon, 12 Nov 2012 14:39:17 -0800
"Len Ovens" <len(a)ovenwerks.net> ha scritto:
On Mon, November 12, 2012 12:10 pm, Asa Marco wrote:
I would choose between 44.1KHz and 48KHz on the multitrack recorder,
so outside of Ardour. Since audio sources are radio microphones whose
specs report a band of 40-18000Hz I think 48Khz would be an unuseful
oversampling (provided a small use of DSP), am I wrong?
Hello list,
For the first time in my life I need to work with huge recordings, I
would like to understand how much memory and computing power is
required to handle it on a linux box with Ardour.
The recording, retrieved from an Alesis hd24, will be about 1 hour
and a half long, 24 channels, 44.1KHz, 16bit,
What are the minimal requirements to work with it?
If I choose sample rate and bit depth to be 48kHz/24bit, will it
require much more resources (other than disk space)?
To change things to 48k you would have to do that outside of ardour. I
would suggest against doing that except as a final step after mixdown
as any time differences from track to track in the resample would be
magnified by such a long track. Even in shorter cases stereo imaging
could be affected. It would be best to leave 44100 if at all
possible. If the end product _has_ to be 48k then expect a (hopefully
small) loss in quality.
Ardour will switch it to 32bit float internally whatever the input is
to allow mixing headroom. 24 bit is chosen at export time. However,
again this would be decided by the final delivery route.
Thank for this information, i didn't know of this behaviour.
--
Asa Marco <aesir.ml(a)gmail.com> 朝
1:13 p.m.
On Tue, Nov 13, 2012 at 5:36 AM, Asa Marco <aesir.ml(a)gmail.com> wrote:
I would choose between 44.1KHz and 48KHz on the multitrack recorder,
so outside of Ardour. Since audio sources are radio microphones whose
specs report a band of 40-18000Hz I think 48Khz would be an unuseful
oversampling (provided a small use of DSP), am I wrong?
If you are syncin'g to video, record at 48k, otherwise 44.1 is perfectly
fine. From the sounds of it you are recording live theater if you have
mostly radio mics?
By the way, don't depend on the HD24's FTP functionality, it sucks. Get
HD24Tools to transfer recordings, will work much better. Really the
recordings should have been done in 24 bit to be honest in my opinion.
For the record I mixed down and released a CD with recordings off an HD24
of live theater several years back on an old Opteron 1.6GHz IIRC. So yes a
P4 can work, even in mixing, but I will tell you I find it much easier to
deal with these days when I don't have to be quite so careful on resource
usage.
Seablade
5:14 p.m.
Il giorno Tue, 13 Nov 2012 07:13:31 -0500
Thomas Vecchione <seablaede(a)gmail.com> ha scritto:
On Tue, Nov 13, 2012 at 5:36 AM, Asa Marco
<aesir.ml(a)gmail.com> wrote:
Exactly, it's live theater. I'll definetely go for 48kHz/24bit ;)
Thank you for sharing your experience with hd24, I'll follow your
advices!
--
Asa Marco <aesir.ml(a)gmail.com> 朝
I would choose between 44.1KHz and 48KHz on the multitrack recorder,
so outside of Ardour. Since audio sources are radio microphones
whose specs report a band of 40-18000Hz I think 48Khz would be an
unuseful oversampling (provided a small use of DSP), am I wrong?
If you are syncin'g to video, record at 48k, otherwise 44.1 is
perfectly fine. From the sounds of it you are recording live theater
if you have mostly radio mics?
3:36 p.m.
On Tue, November 13, 2012 2:36 am, Asa Marco wrote:
Yes choose the final sample rate at the record time. avoid oversampling if
you can. If you already have the tracks recorded at 44.1k, I think
oversampling as a final step rather than on the tracks makes sense, but I
could be wrong. If you have all single tracks (not stereo) it may be
better to oversample first before you make stereo images.
Anyone else have an opinion on this?
--
Len Ovens
www.OvenWerks.net
To change
things to 48k you would have to do that outside of ardour. I
would suggest against doing that except as a final step after mixdown
as any time differences from track to track in the resample would be
magnified by such a long track. Even in shorter cases stereo imaging
could be affected. It would be best to leave 44100 if at all
possible. If the end product _has_ to be 48k then expect a (hopefully
small) loss in quality.
I would choose between 44.1KHz and 48KHz on the multitrack recorder,
so outside of Ardour. Since audio sources are radio microphones whose
specs report a band of 40-18000Hz I think 48Khz would be an unuseful
oversampling (provided a small use of DSP), am I wrong?
11:48 a.m.
On Mon, Nov 12, 2012 at 02:39:17PM -0800, Len Ovens wrote:
To change things to 48k you would have to do that
outside of ardour. I
would suggest against doing that except as a final step after mixdown as
any time differences from track to track in the resample would be
magnified by such a long track. Even in shorter cases stereo imaging could
be affected.
You must be using a *really* crap resampling app if you get that
sort of effects.
If you import the tracks in Ardour with resampling, or if you
use sndfile-resample, the work is done by Erik's libsamplerate.
This uses (double precision) floating point to maintain the
filter phase, and that will indeed lead to accumulating roundoff
errors. But in practice these are *absolutely insignificant*.
I actually did the test, checking the timing after 10 hours
of resampling from 44.1 to 48 kHz. Within the precision of
the test (around 1 millionth of a sample, 25 picoseconds)
there was *zero* error.
And if you use zresample the problem doesn't exist by design,
as it uses only rational arithmetic (i.e. all integers) to do
the same calculations.
Ciao,
--
FA
A world of exhaustive, reliable metadata would be an utopia.
It's also a pipe-dream, founded on self-delusion, nerd hubris
and hysterically inflated market opportunities. (Cory Doctorow)
3:41 p.m.
On Tue, November 13, 2012 2:48 am, Fons Adriaensen wrote:
On Mon, Nov 12, 2012 at 02:39:17PM -0800, Len Ovens
wrote:
My information is probably out of date :) or I was thinking of some of the
"on the fly" resampling from the late 90s. Thank you for setting me
straight.
--
Len Ovens
www.OvenWerks.net
To change things to 48k you would have to do that
outside of ardour. I
would suggest against doing that except as a final step after mixdown as
any time differences from track to track in the resample would be
magnified by such a long track. Even in shorter cases stereo imaging
could
be affected.
You must be using a *really* crap resampling app if you get that
sort of effects.
4491
days inactive
4492
days old
linux-audio-user@lists.linuxaudio.org
12 comments
7 participants
participants (7)
-
Asa Marco -
david -
Fons Adriaensen -
Jannis Achstetter -
Len Ovens -
Paul Davis -
Thomas Vecchione