plib-users

[Plib-users] Damage to sound hardware

[Risto S V. <rva...@cc...>]

I gather it is possible to damage your audio hardware, eg. the
speakers, if you for example turn the volume high enough and play
some clicks or noise. I imagine this could happen with badly
coded / pre-alpha / prototype applications. 

How do you guard against this using Plib, so you can avoid
problems with your users? Should you always set your safetyMargin
high enough and check that you get the same from getRate etc. for
your slSample and slScheduler? (Btw, what would happen if you call
slSample::adjustVolume in a loop?)

-- 
Risto Varanka | http://www.helsinki.fi/~rvaranka/		
ris...@he...

Re: [Plib-users] Damage to sound hardware

[<Va...@t-...>]

Risto S Varanka wrote:
> 
> I gather it is possible to damage your audio hardware, eg. the
> speakers, if you for example turn the volume high enough and play
> some clicks or noise. I imagine this could happen with badly
> coded / pre-alpha / prototype applications.
> 
> How do you guard against this using Plib, so you can avoid
> problems with your users? Should you always set your safetyMargin
> high enough and check that you get the same from getRate etc. for
> your slSample and slScheduler? (Btw, what would happen if you call
> slSample::adjustVolume in a loop?)

IMHO it's not the task of PLIB to protect the user/speaker from such
sounds. There are two reasons:

1) it's technically too complex and would consume too much CPU for
something that nearly no application needs. We'd need to add a 'noise
detection' that most probably would require some sort of fourier
transformation - or we would need to scale the volume down generally.
Both sollutions wouldn't be wanted by our customers (i.e. the
application programmers) as there are quite a lot real time programmers
(they need every bit of the CPU). And a downscaled volume would force
the programmers to scale the sound up before he sends it to SL - due to
the limited precition we'd loose quality.

2) If the application destroys the speakers it's the applications fault,
not ours. We didn't provide the sound - we are just passing it to the OS
which is passing it to the soundcard wich is passing it to the speakers.
So we also should require the OS and the soundcard to protect the
speakers (oh, and the speakers should protect themselves, too)
IMHO it's ridiculous to make a library guilty for destroying the
speakers; we'd just have to bewareabout the USA as there's a microwave
producer guilty for the death of an hamster that a customer put into it
to dry it after a bath (unless the puts a warning in the manual...).
Both examples show that the problem lies somewhere else.

CU,
Christian

Re: [Plib-users] Damage to sound hardware

[Risto S V. <rva...@cc...>]

> IMHO it's not the task of PLIB to protect the user/speaker from such
> sounds. 

Indeed, as it seems unfeasible. I was asking what one can do on
the application level to avoid nasty surprises - I was not supposing
the library could be foolproof. 

-- 
Risto Varanka | http://www.helsinki.fi/~rvaranka/		
ris...@he...

Re: [Plib-users] Damage to sound hardware

[Steve B. <sjb...@ai...>]

Christian Mayer wrote:

> we'd just have to bewareabout the USA as there's a microwave
> producer guilty for the death of an hamster that a customer put into it
> to dry it after a bath (unless the puts a warning in the manual...).

Actually, I think that's an urban legend - and the original story
was that it was a miniature poodle (a DOG not a hamster) and the
cause of the court case was that in the long list of foods and
cooking times printed on the door of the oven was "Dogs...3 minutes"
(meaning HotDogs - not Canines).  However, even with that modification,
I don't think this is a true story.

I should point out that in using PLIB (which is an LGPL'ed library),
you are accepting the following clauses from the LGPL:

  Quoting from 'LICENSE' in the PLIB root directory:

                            NO WARRANTY
 
  15. BECAUSE THE LIBRARY IS LICENSED FREE OF CHARGE, THERE IS NO
  WARRANTY FOR THE LIBRARY, TO THE EXTENT PERMITTED BY APPLICABLE LAW.
  EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR
  OTHER PARTIES PROVIDE THE LIBRARY "AS IS" WITHOUT WARRANTY OF ANY
  KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE
  IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
  PURPOSE.  THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE
  LIBRARY IS WITH YOU.  SHOULD THE LIBRARY PROVE DEFECTIVE, YOU ASSUME
  THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION.
 
  16. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN
  WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY
  AND/OR REDISTRIBUTE THE LIBRARY AS PERMITTED ABOVE, BE LIABLE TO YOU
  FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR
  CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE
  LIBRARY (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING
  RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR A
  FAILURE OF THE LIBRARY TO OPERATE WITH ANY OTHER SOFTWARE), EVEN IF
  SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH
  DAMAGES.

So, if an off-by-one error in the audio library causes a 'click' and
that causes your speakers to explode thereby setting fire to your
house - resulting in a gas pipeline blow-back that takes out your local
plutonium storage facility - which then leaves a poisonous radioactive
cloud encircling the globe - leaving only three humans left alive (You,
me and a lawyer), it'll be YOU that gets sued...not me.

Hmmm - I'd better just go back and look at that replay routine *one*
more time!   :-)

-- 
Steve Baker   HomeEmail: <sjb...@ai...>
              WorkEmail: <sj...@li...>
              HomePage : http://web2.airmail.net/sjbaker1
              Projects : http://plib.sourceforge.net
                         http://tuxaqfh.sourceforge.net
                         http://tuxkart.sourceforge.net
                         http://prettypoly.sourceforge.net

Re: [Plib-users] Damage to sound hardware

[Steve B. <sjb...@ai...>]

Risto S Varanka wrote:
> 
> I gather it is possible to damage your audio hardware, eg. the
> speakers, if you for example turn the volume high enough and play
> some clicks or noise. I imagine this could happen with badly
> coded / pre-alpha / prototype applications.

I guess it's theoretically possible with really high powered amplifiers
and such - I've never heard of anyone actually doing that though.

> How do you guard against this using Plib, so you can avoid
> problems with your users?

I don't - it's really impossible to write a bullet-proof check without
doing some realtime signal analysis - and that's really not going to
happen while the computer is busy doing graphics, etc.

In the end, if your amp/speakers are set up in such a way that damage
could occur, then it could happen because a program crashed - or you
played back an MP3 that had a click in it - anything really.

I just don't think you should worry about it.  If you are overdriving
your speakers to that degree then it's all your own fault IMHO.

> Should you always set your safetyMargin
> high enough and check that you get the same from getRate etc. for
> your slSample and slScheduler?

Safety margin should certainly be set to the longest expected interval
between calls to the SL update routine - or else there can be gaps
in the audio stream.  It's hard for an application writer to get that
right because in a multitasking system, another program could come along
and lock up the CPU for a couple of seconds...so sound breakup is
always a possibility.

Again though, this is nothing unique to PLIB's sound replayer - it could
happen with any of them.

It's a good idea to ensure that your sounds are sampled at the same rate
that they will be replayed - or else they'll be too fast or too slow.
In most applications, you'll be shipping the sound files with the program,
so you can just record them at a suitably high speed and have PLIB downsample
them for you.

> (Btw, what would happen if you call
> slSample::adjustVolume in a loop?)

Not good - the quality of the audio will gradually degrade due to roundoff
errors.  The sample adjust routines make a permenant change to the actual
sound sample data itself.

If you need runtime volume/frequency control, use a one-step slEnvelope
which is applied as the sound is replayed.

-- 
Steve Baker   HomeEmail: <sjb...@ai...>
              WorkEmail: <sj...@li...>
              HomePage : http://web2.airmail.net/sjbaker1
              Projects : http://plib.sourceforge.net
                         http://tuxaqfh.sourceforge.net
                         http://tuxkart.sourceforge.net
                         http://prettypoly.sourceforge.net