Recording may channels at once

[Kjetil S. Matheussen-3]

(cc to ardour-dev)


On Wed, 2 Jul 2008, Thomas Vecchione wrote:

>
>
> And is far from a standard setup as well;)  If the OS is running from
> memory, and you are not swapping anything in or out of the swap partition(Or
> file as the case may be), but are still running X, GUI based programs(Azerus
> etc.) and doing 128 tracks of recording, all from a single disk, you are
> pretty lucky IMO, even on Linux.  I can't even depend on 64 tracks without a
> dropout due to disk access on a system disk.  32 is even pushing it, but i
> will say I have done it.  This is running Ardour, X, e17, jackd, and that is
> about it, on a properly patched kernel, with proper PAM permissions, but
> that does still have logging set up etc.
>

I think this might be because ardour records to separate files. I just
tried recording 128 channels in ardour using 16 X 8 channel tracks,
and it failed quite immediate. Recording 128 channels using jack_capture,
on the other hand, seems rock solid. Recording 64 channels (8 X 8) in
ardour seems to work fine too.

However, it could also be because Ardour does some graphical operations
while recording. Is there any way to turn off all that?

Perhaps this is an area where Ardour could be optimized quite a bit?

_______________________________________________
ardour-dev mailing list
ardour-dev@...
http://lists.ardour.org/listinfo.cgi/ardour-dev-ardour.org

[Sampo Savolainen]

On Thu, 2008-07-03 at 16:25 +0200, Kjetil S. Matheussen wrote:

> (cc to ardour-dev)
>
>
> On Wed, 2 Jul 2008, Thomas Vecchione wrote:
> >
> >
> > And is far from a standard setup as well;)  If the OS is running from
> > memory, and you are not swapping anything in or out of the swap partition(Or
> > file as the case may be), but are still running X, GUI based programs(Azerus
> > etc.) and doing 128 tracks of recording, all from a single disk, you are
> > pretty lucky IMO, even on Linux.  I can't even depend on 64 tracks without a
> > dropout due to disk access on a system disk.  32 is even pushing it, but i
> > will say I have done it.  This is running Ardour, X, e17, jackd, and that is
> > about it, on a properly patched kernel, with proper PAM permissions, but
> > that does still have logging set up etc.
> >
>
> I think this might be because ardour records to separate files. I just
> tried recording 128 channels in ardour using 16 X 8 channel tracks,
> and it failed quite immediate. Recording 128 channels using jack_capture,
> on the other hand, seems rock solid. Recording 64 channels (8 X 8) in
> ardour seems to work fine too.

Your CPU might be running out of time, or your disk system (platters or
filesystem or memory).

> However, it could also be because Ardour does some graphical operations
> while recording. Is there any way to turn off all that?

You can disable showing waveforms while recording (View->show waveforms
while recording). You used to be able to disable the "pink boxes" also,
but I can't find the option in 2.0 ongoing at the moment. But ...

> Perhaps this is an area where Ardour could be optimized quite a bit?

.. If jack (and thus, the Ardour audio thread) is running with realtime
scheduling plus you have a sane kernel and enough memory - none of these
things really matter. The audio and disk threads will always get
priority over the GUI and thus no pink box will interfere with the
performance that really matters.

Oh, and proper scheduling also promises food for everyone and world
peace.

 Sampo


_______________________________________________
ardour-dev mailing list
ardour-dev@...
http://lists.ardour.org/listinfo.cgi/ardour-dev-ardour.org

[Kjetil S. Matheussen-3]

On Fri, 4 Jul 2008, Sampo Savolainen wrote:

> On Thu, 2008-07-03 at 16:25 +0200, Kjetil S. Matheussen wrote:
> > (cc to ardour-dev)
> >
> >
> > On Wed, 2 Jul 2008, Thomas Vecchione wrote:
> > >
> > >
> > > And is far from a standard setup as well;)  If the OS is running from
> > > memory, and you are not swapping anything in or out of the swap partition(Or
> > > file as the case may be), but are still running X, GUI based programs(Azerus
> > > etc.) and doing 128 tracks of recording, all from a single disk, you are
> > > pretty lucky IMO, even on Linux.  I can't even depend on 64 tracks without a
> > > dropout due to disk access on a system disk.  32 is even pushing it, but i
> > > will say I have done it.  This is running Ardour, X, e17, jackd, and that is
> > > about it, on a properly patched kernel, with proper PAM permissions, but
> > > that does still have logging set up etc.
> > >
> >
> > I think this might be because ardour records to separate files. I just
> > tried recording 128 channels in ardour using 16 X 8 channel tracks,
> > and it failed quite immediate. Recording 128 channels using jack_capture,
> > on the other hand, seems rock solid. Recording 64 channels (8 X 8) in
> > ardour seems to work fine too.
>
> Your CPU might be running out of time, or your disk system (platters or
> filesystem or memory).
>
> > However, it could also be because Ardour does some graphical operations
> > while recording. Is there any way to turn off all that?
>
> You can disable showing waveforms while recording (View->show waveforms
> while recording). You used to be able to disable the "pink boxes" also,
> but I can't find the option in 2.0 ongoing at the moment. But ...
>

I just did some benchmarks recording 128 channels (16 X 8):

Recording times before failing, without waveforms while recording:
55s
19s
8s

Recording times before failing, with waveforms while recording:
16s
24s
18s

I run some other programs in the background accessing the
disk, so that could explain the large variations.


However, recording times before failing, using jack_capture,
128 channels, 5 second buffer, "$jack_capture -dm -B 5 -c 128" :

Manually stopped after 7.59 minutes, no failure.



> > Perhaps this is an area where Ardour could be optimized quite a bit?
>
> .. If jack (and thus, the Ardour audio thread) is running with realtime
> scheduling plus you have a sane kernel and enough memory - none of these
> things really matter. The audio and disk threads will always get
> priority over the GUI and thus no pink box will interfere with the
> performance that really matters.
>

Yes, but jack_capture only writes to one file, while ardour
writes to several. That could explain the difference.



> Oh, and proper scheduling also promises food for everyone and world
> peace.
>
>  Sampo
>
>
>
_______________________________________________
ardour-dev mailing list
ardour-dev@...
http://lists.ardour.org/listinfo.cgi/ardour-dev-ardour.org

[Sampo Savolainen]

On Fri, 2008-07-04 at 13:05 +0200, Kjetil S. Matheussen wrote:

> I just did some benchmarks recording 128 channels (16 X 8):
>
> Recording times before failing, without waveforms while recording:
> 55s
> 19s
> 8s
>
> Recording times before failing, with waveforms while recording:
> 16s
> 24s
> 18s
>
> I run some other programs in the background accessing the
> disk, so that could explain the large variations.

Sounds bad though. Can you try the same test so that you use the same
background load. Preferably no extra load.

Ardour does have extra 128 ports (if mono-mono trakcs), or 256 ports (if
mono-stereo tracks) compared to jack_capture.

> However, recording times before failing, using jack_capture,
> 128 channels, 5 second buffer, "$jack_capture -dm -B 5 -c 128" :

Are these parameters correct? jack_capture 0.9.16 tells me that -B
defines the amount of seconds you are recording ...

> Manually stopped after 7.59 minutes, no failure.

.. and that time conflicts with how I read that parameter.


  Sampo

_______________________________________________
ardour-dev mailing list
ardour-dev@...
http://lists.ardour.org/listinfo.cgi/ardour-dev-ardour.org

[Kjetil S. Matheussen-3]

On Wed, 9 Jul 2008, Sampo Savolainen wrote:

> On Fri, 2008-07-04 at 13:05 +0200, Kjetil S. Matheussen wrote:
> > I just did some benchmarks recording 128 channels (16 X 8):
> >
> > Recording times before failing, without waveforms while recording:
> > 55s
> > 19s
> > 8s
> >
> > Recording times before failing, with waveforms while recording:
> > 16s
> > 24s
> > 18s
> >
> > I run some other programs in the background accessing the
> > disk, so that could explain the large variations.
>
> Sounds bad though. Can you try the same test so that you use the same
> background load. Preferably no extra load.
>

I'll do that when I get home.


> Ardour does have extra 128 ports (if mono-mono trakcs), or 256 ports (if
> mono-stereo tracks) compared to jack_capture.
>

I'm not quite sure what you mean. Are these tracks allways there, or
did you mean 64 ports / 128 ports?

I used 16 8 channel tracks. The
results would probably be much worse with 64 or 128 tracks.

Regarding running jack_capture, it's possible I didn't stop ardour
when doing the test with jack_capture.



> > However, recording times before failing, using jack_capture,
> > 128 channels, 5 second buffer, "$jack_capture -dm -B 5 -c 128" :
>
> Are these parameters correct? jack_capture 0.9.16 tells me that -B
> defines the amount of seconds you are recording ...
>

Yes, those parameters are correct. Where did you read that
-B defines the amount of seconds you are recording?

_______________________________________________
ardour-dev mailing list
ardour-dev@...
http://lists.ardour.org/listinfo.cgi/ardour-dev-ardour.org

[Sampo Savolainen]

On Wed, 2008-07-09 at 20:40 +0200, Kjetil S. Matheussen wrote:

> On Wed, 9 Jul 2008, Sampo Savolainen wrote:
> > Ardour does have extra 128 ports (if mono-mono trakcs), or 256 ports (if
> > mono-stereo tracks) compared to jack_capture.
> >
>
> I'm not quite sure what you mean. Are these tracks allways there, or
> did you mean 64 ports / 128 ports?
>
> I used 16 8 channel tracks. The
> results would probably be much worse with 64 or 128 tracks.

I guess the question is what are you doing with the 8 tracks. The
default 8 track channel has only two outputs. So it would mean only 32
extra ports (compared to jack_capture).

Many might want to use 8 channel tracks with 8 separate outputs for each
track. This would mean a lot more outputs.

You can use jack_lsp to check the amount.

> Yes, those parameters are correct. Where did you read that
> -B defines the amount of seconds you are recording?

See the third line of the usage:

v2@mustis:~/dev/audio/jack_capture-0.9.16$ ./jack_capture --help
Usage: jack_capture  [--bitdepth n] [--bufsize seconds] [--channels n]
[--port port] [filename]
                     [ -b n]        [ -B seconds]       [ -c n]
[ -p port]
...
...
..

If it doesn't stand for seconds, what does it mean? --bufsize?

 Sampo

_______________________________________________
ardour-dev mailing list
ardour-dev@...
http://lists.ardour.org/listinfo.cgi/ardour-dev-ardour.org

[Sampo Savolainen]

On Wed, 2008-07-09 at 22:08 +0300, Sampo Savolainen wrote:

> v2@mustis:~/dev/audio/jack_capture-0.9.16$ ./jack_capture --help
> Usage: jack_capture  [--bitdepth n] [--bufsize seconds] [--channels n]
> [--port port] [filename]
>                      [ -b n]        [ -B seconds]       [ -c n]
> [ -p port]
> ...
> ...
> ..
>
> If it doesn't stand for seconds, what does it mean? --bufsize?

*doh* buffer size, in seconds...


 Sampo

_______________________________________________
ardour-dev mailing list
ardour-dev@...
http://lists.ardour.org/listinfo.cgi/ardour-dev-ardour.org

[Kjetil S. Matheussen-3]

On Wed, 9 Jul 2008, Sampo Savolainen wrote:

> On Wed, 2008-07-09 at 20:40 +0200, Kjetil S. Matheussen wrote:
>> On Wed, 9 Jul 2008, Sampo Savolainen wrote:
>>> Ardour does have extra 128 ports (if mono-mono trakcs), or 256 ports (if
>>> mono-stereo tracks) compared to jack_capture.
>>>
>>
>> I'm not quite sure what you mean. Are these tracks allways there, or
>> did you mean 64 ports / 128 ports?
>>
>> I used 16 8 channel tracks. The
>> results would probably be much worse with 64 or 128 tracks.
>
> I guess the question is what are you doing with the 8 tracks. The
> default 8 track channel has only two outputs. So it would mean only 32
> extra ports (compared to jack_capture).
>
> Many might want to use 8 channel tracks with 8 separate outputs for each
> track. This would mean a lot more outputs.
>
> You can use jack_lsp to check the amount.
>

Aha. Well, this should only matter if I run out of CPU though.
I'll check the CPU too at next benchmark.

>> Yes, those parameters are correct. Where did you read that
>> -B defines the amount of seconds you are recording?
>
> See the third line of the usage:
>
> v2@mustis:~/dev/audio/jack_capture-0.9.16$ ./jack_capture --help
> Usage: jack_capture  [--bitdepth n] [--bufsize seconds] [--channels n]
> [--port port] [filename]
>                     [ -b n]        [ -B seconds]       [ -c n]
> [ -p port]
> ...
> ...
> ..
>
> If it doesn't stand for seconds, what does it mean? --bufsize?
>

I don't understand why you would want to interpret the above text to be
that "-B" is the recording length. Are you using a terminal
with a non-fixed size font?

_______________________________________________
ardour-dev mailing list
ardour-dev@...
http://lists.ardour.org/listinfo.cgi/ardour-dev-ardour.org

[Kjetil S. Matheussen-3]

On Wed, 9 Jul 2008, Sampo Savolainen wrote:

> On Wed, 2008-07-09 at 22:08 +0300, Sampo Savolainen wrote:
>> v2@mustis:~/dev/audio/jack_capture-0.9.16$ ./jack_capture --help
>> Usage: jack_capture  [--bitdepth n] [--bufsize seconds] [--channels n]
>> [--port port] [filename]
>>                      [ -b n]        [ -B seconds]       [ -c n]
>> [ -p port]
>> ...
>> ...
>> ..
>>
>> If it doesn't stand for seconds, what does it mean? --bufsize?
>
> *doh* buffer size, in seconds...
>

Good. :-)
I'll see if I can make this a bit clearer anyway.

_______________________________________________
ardour-dev mailing list
ardour-dev@...
http://lists.ardour.org/listinfo.cgi/ardour-dev-ardour.org

[Kjetil S. Matheussen-3]

On Wed, 9 Jul 2008, Sampo Savolainen wrote:

> On Fri, 2008-07-04 at 13:05 +0200, Kjetil S. Matheussen wrote:
>> I just did some benchmarks recording 128 channels (16 X 8):
>>
>> Recording times before failing, without waveforms while recording:
>> 55s
>> 19s
>> 8s
>>
>> Recording times before failing, with waveforms while recording:
>> 16s
>> 24s
>> 18s
>>
>> I run some other programs in the background accessing the
>> disk, so that could explain the large variations.
>
> Sounds bad though. Can you try the same test so that you use the same
> background load. Preferably no extra load.
>

It's a bit more consistent now. Below are results without any other
programs running, exept emacs, pine, jack, konsole and qjackctl.
I had 1GB free of memory, and had 5.94s long buffer for ardour.
Total CPU usage was, according to "top", about 20% while recording,
and Jack reported about 12% dsp cpu usage.

09s
13s
12s
12s
12s
19s

The next time I tried, after the result with 19 seconds, something
interesting happened. Suddenly, after a few seconds, I get a bunch of
errors which says something like this:

   "can not write peak file, too many open files",

and when I press the stop button, ardour crashes.

I would think this is an OS limitation (although one not very gracefully
handled by Ardour), but anyway, if ardour writes peak files while
recording, then it's not that strange that jack_capture performs so much
better.

I guess I got the error because this was the 7th recording, with
128 peak files, yielding about 128*7 files.
This is how I worked:

1. Record.
2. Write down how many seconds of sound recorded.
3. Undo Capture
4. Goto 1.

Why isn't the older peak files closed and deleted?

kjetil@ttleush ~/longrecording/peaks $ ls -la |wc
     874    8730   57091
kjetil@ttleush ~/longrecording/peaks $

_______________________________________________
ardour-dev mailing list
ardour-dev@...
http://lists.ardour.org/listinfo.cgi/ardour-dev-ardour.org

[Kjetil S. Matheussen-3]

On Thu, 10 Jul 2008, Kjetil S. Matheussen wrote:

>
>
> On Wed, 9 Jul 2008, Sampo Savolainen wrote:
>
> > On Fri, 2008-07-04 at 13:05 +0200, Kjetil S. Matheussen wrote:
> >> I just did some benchmarks recording 128 channels (16 X 8):
> >>
> >> Recording times before failing, without waveforms while recording:
> >> 55s
> >> 19s
> >> 8s
> >>
> >> Recording times before failing, with waveforms while recording:
> >> 16s
> >> 24s
> >> 18s
> >>
> >> I run some other programs in the background accessing the
> >> disk, so that could explain the large variations.
> >
> > Sounds bad though. Can you try the same test so that you use the same
> > background load. Preferably no extra load.
> >
>
> It's a bit more consistent now. Below are results without any other
> programs running, exept emacs, pine, jack, konsole and qjackctl.
> I had 1GB free of memory, and had 5.94s long buffer for ardour.
> Total CPU usage was, according to "top", about 20% while recording,
> and Jack reported about 12% dsp cpu usage.
>
> 09s
> 13s
> 12s
> 12s
> 12s
> 19s
>
> The next time I tried, after the result with 19 seconds, something
> interesting happened. Suddenly, after a few seconds, I get a bunch of
> errors which says something like this:
>
>    "can not write peak file, too many open files",
>
> and when I press the stop button, ardour crashes.
>
> I would think this is an OS limitation (although one not very gracefully
> handled by Ardour), but anyway, if ardour writes peak files while
> recording, then it's not that strange that jack_capture performs so much
> better.
>
> I guess I got the error because this was the 7th recording, with
> 128 peak files, yielding about 128*7 files.
> This is how I worked:
>
> 1. Record.
> 2. Write down how many seconds of sound recorded.
> 3. Undo Capture
> 4. Goto 1.
>
> Why isn't the older peak files closed and deleted?
>
> kjetil@ttleush ~/longrecording/peaks $ ls -la |wc
>      874    8730   57091
> kjetil@ttleush ~/longrecording/peaks $
>
>

Oh, and the audio files weren't deleted either between each
capture:

kjetil@ttleush ~/longrecording $ ls -la interchange/longrecording/audiofiles/ |wc
    907    9060   57457
kjetil@ttleush ~/longrecording $


_______________________________________________
ardour-dev mailing list
ardour-dev@...
http://lists.ardour.org/listinfo.cgi/ardour-dev-ardour.org

[Scott Bahling]

On Thu, 2008-07-10 at 16:41 +0200, Kjetil S. Matheussen wrote:

> On Thu, 10 Jul 2008, Kjetil S. Matheussen wrote:
>
> >
> >
> > On Wed, 9 Jul 2008, Sampo Savolainen wrote:
> >
> > > On Fri, 2008-07-04 at 13:05 +0200, Kjetil S. Matheussen wrote:
> > >> I just did some benchmarks recording 128 channels (16 X 8):
> > >>
> > >> Recording times before failing, without waveforms while recording:
> > >> 55s
> > >> 19s
> > >> 8s
> > >>
> > >> Recording times before failing, with waveforms while recording:
> > >> 16s
> > >> 24s
> > >> 18s
> > >>
> > >> I run some other programs in the background accessing the
> > >> disk, so that could explain the large variations.
> > >
> > > Sounds bad though. Can you try the same test so that you use the same
> > > background load. Preferably no extra load.
> > >
> >
> > It's a bit more consistent now. Below are results without any other
> > programs running, exept emacs, pine, jack, konsole and qjackctl.
> > I had 1GB free of memory, and had 5.94s long buffer for ardour.
> > Total CPU usage was, according to "top", about 20% while recording,
> > and Jack reported about 12% dsp cpu usage.
> >
> > 09s
> > 13s
> > 12s
> > 12s
> > 12s
> > 19s
> >
> > The next time I tried, after the result with 19 seconds, something
> > interesting happened. Suddenly, after a few seconds, I get a bunch of
> > errors which says something like this:
> >
> >    "can not write peak file, too many open files",
> >
> > and when I press the stop button, ardour crashes.
> >
> > I would think this is an OS limitation (although one not very gracefully
> > handled by Ardour), but anyway, if ardour writes peak files while
> > recording, then it's not that strange that jack_capture performs so much
> > better.
> >
> > I guess I got the error because this was the 7th recording, with
> > 128 peak files, yielding about 128*7 files.
> > This is how I worked:
> >
> > 1. Record.
> > 2. Write down how many seconds of sound recorded.
> > 3. Undo Capture
> > 4. Goto 1.
> >
> > Why isn't the older peak files closed and deleted?
> >
> > kjetil@ttleush ~/longrecording/peaks $ ls -la |wc
> >      874    8730   57091
> > kjetil@ttleush ~/longrecording/peaks $
> >
> >
>
> Oh, and the audio files weren't deleted either between each
> capture:

If you want the audio files deleted, use "Remove Last Capture" for step
3 instead.

-Scott

_______________________________________________
ardour-dev mailing list
ardour-dev@...
http://lists.ardour.org/listinfo.cgi/ardour-dev-ardour.org