max capture duration?

Hello,

I would like to monitor audio inputs continuously for days,
and record 
specific acoustic events (bird vocalizations) to disk. I
started writing an 
application using alsa directly, but now I am thinking using
JACK might be a 
better idea. I have been browsing the available
documentation and tried the 
example capture client code, and everything looks very nice.
However I have 
one concern before I start to rewrite my program: the
possibility of a 
maximum duration of a JACK client process. I see in the API
documentation and 
header code that jack_nframes_t is a unsigned 32-bit number,
and from the 
existence of the function jack_frames_since_cycle_start() I
gather that JACK 
counts the number of frames it processed. So what happens if
I monitor a 
channel at a sampling rate of 44.1 kHz for 2 days? The
number of samples 
would be 7620480000, which is more than the max of a uint32.

In case this would raise problems, is there an easy way
around this?

Advice would be very much appreciated, Thanks,

Gabriel


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking
scripting language
that extends applications into web and mobile media. Attend
the live webcast
and join the prime developer group breaking into this new
coding territory!
http://sel.as-us.falkag.net/
sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Jackit-devel mailing list
Jackit-devellists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jackit-dev
el

On Tue, 2006-02-28 at 08:32 +0100, Gabriel Beckers wrote:
> Hello,
> 
> I would like to monitor audio inputs continuously for
days, and record 
> specific acoustic events (bird vocalizations) to disk.
I started writing an 
> application using alsa directly, but now I am thinking
using JACK might be a 
> better idea. I have been browsing the available
documentation and tried the 
> example capture client code, and everything looks very
nice. However I have 
> one concern before I start to rewrite my program: the
possibility of a 
> maximum duration of a JACK client process. I see in the
API documentation and 
> header code that jack_nframes_t is a unsigned 32-bit
number, and from the 
> existence of the function
jack_frames_since_cycle_start() I gather that JACK 
> counts the number of frames it processed. So what
happens if I monitor a 
> channel at a sampling rate of 44.1 kHz for 2 days? The
number of samples 
> would be 7620480000, which is more than the max of a
uint32.
> 
> In case this would raise problems, is there an easy way
around this?

this will not cause any problems in and of itself.

the problem you *will* face is finding a way to put that
much data into
files that do not exceed various artificial limits.

your best bet would probably be to avoid using any
"header" based format
(such as .wav or .aiff) and just write the raw sample data
to disk.
otherwise you will run into the limitations on file size
created by the
header formats. once you avoid that limit, all that is left
is the limit
imposed by the file system and operating system. you should
be sure that
you compile your code to use large file support, which will
allow it to
reach 2^64 bytes, essentially large enough for any recording
you can
imagine.

note that these issues will apply whether you use ALSA or
JACK.

--p




-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking
scripting language
that extends applications into web and mobile media. Attend
the live webcast
and join the prime developer group breaking into this new
coding territory!
http://sel.as-us.falkag.net/
sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Jackit-devel mailing list
Jackit-devellists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jackit-dev
el

On Tue, Feb 28, 2006 at 08:07:32AM -0500, Paul Davis wrote:
> On Tue, 2006-02-28 at 08:32 +0100, Gabriel Beckers
wrote:
> > Hello,
> > 
> > I would like to monitor audio inputs continuously
for days, and record 
> > specific acoustic events (bird vocalizations) to
disk. I started writing an 
> > application using alsa directly, but now I am
thinking using JACK might be a 
> > better idea. I have been browsing the available
documentation and tried the 
> > example capture client code, and everything looks
very nice. However I have 
> > one concern before I start to rewrite my program:
the possibility of a 
> > maximum duration of a JACK client process. I see
in the API documentation and 
> > header code that jack_nframes_t is a unsigned
32-bit number, and from the 
> > existence of the function
jack_frames_since_cycle_start() I gather that JACK 
> > counts the number of frames it processed. So what
happens if I monitor a 
> > channel at a sampling rate of 44.1 kHz for 2 days?
The number of samples 
> > would be 7620480000, which is more than the max of
a uint32.
> > 
> > In case this would raise problems, is there an
easy way around this?
> 
> this will not cause any problems in and of itself.
> 
> the problem you *will* face is finding a way to put
that much data into
> files that do not exceed various artificial limits.
> 
> your best bet would probably be to avoid using any
"header" based format
> (such as .wav or .aiff) and just write the raw sample
data to disk.
> otherwise you will run into the limitations on file
size created by the
> header formats. once you avoid that limit, all that is
left is the limit
> imposed by the file system and operating system. you
should be sure that
> you compile your code to use large file support, which
will allow it to
> reach 2^64 bytes, essentially large enough for any
recording you can
> imagine.
> 
> note that these issues will apply whether you use ALSA
or JACK.

If you write the recording application yourself (e.g.
starting from the
JACK example code), it should be simple enough to start a
new file 
(maybe with some overlap) every so much time. Having
separate files may
make management of all that data a little easier.

If you use JACK as the interface, the code required to do
this could
be just a bash script: start a recorder, wait a few hours,
start a second
recorder with a new file, wait a few seconds, terminate the
older one,
loop, ....

-- 
FA



-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking
scripting language
that extends applications into web and mobile media. Attend
the live webcast
and join the prime developer group breaking into this new
coding territory!
http://sel.as-us.falkag.net/
sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Jackit-devel mailing list
Jackit-devellists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jackit-dev
el

OK, thanks for the fast replies, Paul and Alfons. I am
writing the application 
myself, and at the moment I generate a series of sound files
of 600 Mb max 
each. This works fine because I based the code on the
capture client example, 
which uses threads. Originally (when using alsa directly) I
just had a loop 
reading audio data and writing it to file, but each time I
closed a file and 
opened an new one, I got xruns.

The next step will be to do triggering, that is read from
the capture device 
continuously but only write to disk if a bird vocalizes.

My only worry was that JACK itself would not cope with such
long capture 
sessions. My first attempt was to do this in MATLAB with the
DAQ toolbox. I 
could have spent the $1500 in a better way, because the
acquisition engine 
(and MATLAB) consistently crashes after acquiring a number
of samples that is 
suspiciously close to the max of a signed 32 bit int.

Thanks again,
Gabriel

On Tuesday 28 February 2006 14:24, Alfons Adriaensen wrote:
> On Tue, Feb 28, 2006 at 08:07:32AM -0500, Paul Davis
wrote:
> > On Tue, 2006-02-28 at 08:32 +0100, Gabriel Beckers
wrote:
> > > Hello,
> > >
> > > I would like to monitor audio inputs
continuously for days, and record
> > > specific acoustic events (bird vocalizations)
to disk. I started
> > > writing an application using alsa directly,
but now I am thinking using
> > > JACK might be a better idea. I have been
browsing the available
> > > documentation and tried the example capture
client code, and everything
> > > looks very nice. However I have one concern
before I start to rewrite
> > > my program: the possibility of a maximum
duration of a JACK client
> > > process. I see in the API documentation and
header code that
> > > jack_nframes_t is a unsigned 32-bit number,
and from the existence of
> > > the function jack_frames_since_cycle_start()
I gather that JACK counts
> > > the number of frames it processed. So what
happens if I monitor a
> > > channel at a sampling rate of 44.1 kHz for 2
days? The number of
> > > samples would be 7620480000, which is more
than the max of a uint32.
> > >
> > > In case this would raise problems, is there
an easy way around this?
> >
> > this will not cause any problems in and of itself.
> >
> > the problem you *will* face is finding a way to
put that much data into
> > files that do not exceed various artificial
limits.
> >
> > your best bet would probably be to avoid using any
"header" based format
> > (such as .wav or .aiff) and just write the raw
sample data to disk.
> > otherwise you will run into the limitations on
file size created by the
> > header formats. once you avoid that limit, all
that is left is the limit
> > imposed by the file system and operating system.
you should be sure that
> > you compile your code to use large file support,
which will allow it to
> > reach 2^64 bytes, essentially large enough for any
recording you can
> > imagine.
> >
> > note that these issues will apply whether you use
ALSA or JACK.
>
> If you write the recording application yourself (e.g.
starting from the
> JACK example code), it should be simple enough to start
a new file
> (maybe with some overlap) every so much time. Having
separate files may
> make management of all that data a little easier.
>
> If you use JACK as the interface, the code required to
do this could
> be just a bash script: start a recorder, wait a few
hours, start a second
> recorder with a new file, wait a few seconds, terminate
the older one,
> loop, ....


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking
scripting language
that extends applications into web and mobile media. Attend
the live webcast
and join the prime developer group breaking into this new
coding territory!
http://sel.as-us.falkag.net/
sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Jackit-devel mailing list
Jackit-devellists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jackit-dev
el