Suggested modification/extension of beep

Rob Landley rob at landley.net
Fri Feb 19 23:24:56 UTC 2010


On Friday 19 February 2010 15:00:52 Harald Becker wrote:
> Hallo Jim!
>
> On 19.02.2010 21:30, Cathey, Jim wrote:
> > The 'musicker' you get, the 'pipier' you need to be.
> > I see a place for both usages.
>
> You are absolutely true and if there is interest I can add this
> functionality to beep, may be with an option to enable or disable this
> in the configuration menu.
>
> ... but just think about this:
>
> Memory consumption is temporary at the moment xargs/beep is used. Adding
> pipe support to beep adds code statically to the binary which consumes
> memory all the time regardless of playing tunes or not.

Busybox development balances a bunch of criteria.

We try to minimize space the binary takes up on disk (or flash, etc).  We try 
to minimize runtime memory usage.  We try to keep the code as simple and 
understandable as possible.  We try to keep the code fast.  We try to add a 
lot of functionality.  And so on.

Just about all these goals conflict, and we make tradeoffs and balance things 
against each other all the time.  Figuring out how much configurability we 
should have is its own little headache.  (Is a config option to save 100 bytes 
of code worth making the project that much harder to configure, so fewer people 
will go in and tune it to their needs rather than just grabbing defconfig?)

> Playing sounds on the pc speaker isn't accurate either. There are no
> fractional of the frequencies and the clock sources tend to be
> inaccurate. Additionally there are several other points producing
> unintended delays and variations in tone length depending on the systems
> speed and other load. Not to mention those clicks most systems produce
> when you turn the speaker on or off.

Trying to optimize PC speaker output is kind of iffy.  It's the PC speaker.  If 
you want ALSA, we've got ALSA.

If your use case led you to add extra features that you actually use, great.  
If somebody else says that your use case is insufficient and they want the 
program to produce ponies, but this desire on their part didn't motivate them 
to actually code up a solution, and yours did... I lean pretty strongly 
towards your use case as being more persuasive.

Rob
-- 
Latency is more important than throughput. It's that simple. - Linus Torvalds


More information about the busybox mailing list