First off I'd like to say that cronolog really rocks. Nice work, it's
much appreciated.
Secondly, I have a question about what cronolog can be used
for. Some background info: I work for a community radio station in
Montreal, Quebec, CKUT 90.3 FM (www.ckut.ca) and I setup a realtime
archive/logging system of the broadcasts using open-source software.
I use jack
(http://jackit.sourceforge.net) as a realtime sound server, record
multiple times simultaneoulsy using ecasound which reads the audio
data from jackd, encode with lame and then cronolog takes care of
splitting it all up into an mp3 file for every 30 minutes. so, the
chain looks like the following:
ecasound | lame | cronolog
Multiple instances of the chain run simultaneously in order to make
several bitrates available. This allows me to have continuous
recording so no data is lost. Everything works great.
However, the cronolog website and the documentation are very much
oriented towards Apache access logs and to generalize, text logs. This
brings up my question: Are there any problems that you can think of that
might arise if one uses cronlog to log binary data such as Mp3?
My second question is about buffering. Meaning does cronolog take care
so that the data that it receives at 13:00:00 is really the data that is
at the start of a file that begins at 13:00:00? (both Jack and ecasound
are geared for low latency recording.)
I had a look at the source code to see whether anything needed to be
done to optimize the handling of binary data. However it works just
fine -- cronolog loops round reading from it input and writing to its
output. I suspect that it is reading in blocks of 1kb or multiples
thereof and if the input is a continuous stream then each block will
be a second or less of data, so a file starting at 13:00:00 will
really start at 13:00:00 plus or minus a fraction of a second.
