:: >Another point: I notice you changed the encoding status display to
:: >update every 2 seconds, rather than every 100 frames. Any reason for
:: >this? I prefer 100 frames because I like looking and nice round
:: >numbers, and it doesn't impact the speed. Also, to do the 2 second
::
:: I also noticed this, and imho it's much better than a fixed number of frames,
:: mainly because you will get a steady refresh no matter how fast/slow your cpu
:: is .. ie, on slow machines you don't have to wait ages to see how far it got,
:: and on fast machines the numbers won't change faster than you can read... ;)
::
Depending on lame options, sample frequency, quality settings and CPU speed
the display output speed changes from 10 displays per second until a display
every 20 seconds. There was always a patch reducing the 100 to 50 under
special circumstances, not very nice.
Every 2 seconds is a compromise between 1 second (nice fast) and 5 seconds
(it's a liitlleee biiit slooow). Also it's not exactly 2 seconds. It's 2
seconds plus time of the display update. So if display update takes 2
seconds the engine still works. But lame capable machines should not have
problems with output speed, a -DDISPLAY_UPDATE_TIME=60.0 is also possible.
On the other hand side, update starts using termcaps if available. This
reduces output, so update via slow internet lines may be becomes faster.
Maybe all console output should be handled in one source file?
Also, when the lame engine is nearly locked (bad convergence) you got a
message every frame instead of every 2 minutes. This may prevents from
typing ^C. Also you got the current frame number.
If also the verbose code should be thread save, there are a lot of other
variables. May be they should be collected in a gfpv structure.
:: I prefer 100 frames because I like looking and nice round numbers, and it
:: doesn't impact the speed.
::
On my 2 years old computer the average update speed hasn't changed so much.
Sometime it is faster, sometimes slower.
:: constants) to make the library thread safe. However, the whole
:: timestatus.c package is not thread safe, and the status display
:: wouldn't be used by someone doing multiple encodings within a single
:: executable, so it doesn't really matter.
Code like that?
typedef struct {
FILE* device;
const char* cursor_up;
const char* erase_end_of_line;
time_t last_display_update;
unsigned long last_total;
unsigned int last_kbps;
unsigned long last_frame;
unsigned long brhist_count [15];
unsigned long brhist_count_max;
unsigned brhist_vbrmin;
unsigned brhist_vbrmax;
char brhist_kbps [15] [4];
char brhist_bar [BRHIST_BARMAX + 1];
char stderr_buff [576];
} gfpv;
...
typedef struct {
....
gfpv* visual;
} gfp;
...
if (gfp -> gfpv) {
fprintf ( gfp -> visual -> device, "Hallo%s\n", gfp -> visual -> erase_end_of_line
);
}
...
--
Mit freundlichen Gr��en
Frank Klemm
eMail | [EMAIL PROTECTED] home: [EMAIL PROTECTED]
phone | +49 (3641) 64-2721 home: +49 (3641) 390545
sMail | R.-Breitscheid-Str. 43, 07747 Jena, Germany
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
