One thing I've been pondering for a future release is improving hmp3's ability to serve as a web-radio encoder. MP3 still is very much in use there for maximum compatibility. Also, it seems most radios use CBR (meh) - and CBR is pretty robust in Helix.
Currently, hmp3 buffers quite a lot of data before flushing output to file or stdout: The encoding application will wait for ~126 KB before triggering a flush (variable "bs_trigger" in tomp3.cpp). For 128 kpbs streams, that's about 10 seconds of delay, for low-bitrate streams like 32 kbps (for that authentic dialup multimedia experience), that's about 40 seconds of delay.
For web radio, I guess it's best to flush encoded frames directly. This is trivial to fix, and I consider flushing packets directly if the output is stdout...
@Case Any opinions if "always quick flush to stdout" makes sense - or should this be behind a switch ("-QF" for quick flush or "-LD" for low delay....)
Flushing every packet (to stdout, to file can be another story) doesn't seem to impact performance significantly, so I wonder if a switch makes any sense at all here.
time hmp3 test.wav - > test.mp3
(Duration of test.wav: 01:15:01.00)
Flush on every packet:
real 0m8,593s
user 0m8,467s
sys 0m0,108s
real 0m8,591s
user 0m8,445s
sys 0m0,138s
real 0m8,615s
user 0m8,448s
sys 0m0,128s
Flush every ~126 KB:
real 0m8,594s
user 0m8,515s
sys 0m0,072s
real 0m8,666s
user 0m8,565s
sys 0m0,092s
real 0m8,571s
user 0m8,457s
sys 0m0,112s