I know this issue has come up in the past about limiting the output of a signal to 0dbfs. I was hoping that in Csound6 that this would be the case, though my ears just discovered this isn't the case. Very recently I had a very, *very* loud sound come out of my computer's built-in speakers, which I didn't realize they were capable of:

  rtevent:   T1252.647 TT1252.647 M:1471186648363761720503832244583935833526348654611550862152130928718211521883619377814242972039341828345952461695023580810974748468255456191775101001117160226807275991094039549552334879063512724258134702669861017454668597260286619400173267937575177772533863677952.00000

Now that Csound6 is primed for realtime live-coding, potentially with audiences and giant speakers systems, it would be in the best interest to do everything possible to avoid causing long term hearing damage to everyone in the auditorium.

And I specifically mean building the limiter directly into the Csound "out" series of opcodes and are turned on by default. Requiring someone to invest into a physical limiter/compressor or requiring every single instrument isn't practical, nor the safest option.

Best,

Jake

I have no problem with this as long as the limiter can be turned off using a command line option.

Regards,

Mike

On Mon, May 13, 2013 at 11:42 AM, Jacob Joaquin <jacobjoaquin@gmail.com> wrote:

I know this issue has come up in the past about limiting the output of a signal to 0dbfs. I was hoping that in Csound6 that this would be the case, though my ears just discovered this isn't the case. Very recently I had a very, *very* loud sound come out of my computer's built-in speakers, which I didn't realize they were capable of:

  rtevent:   T1252.647 TT1252.647 M:1471186648363761720503832244583935833526348654611550862152130928718211521883619377814242972039341828345952461695023580810974748468255456191775101001117160226807275991094039549552334879063512724258134702669861017454668597260286619400173267937575177772533863677952.00000

Now that Csound6 is primed for realtime live-coding, potentially with audiences and giant speakers systems, it would be in the best interest to do everything possible to avoid causing long term hearing damage to everyone in the auditorium.

And I specifically mean building the limiter directly into the Csound "out" series of opcodes and are turned on by default. Requiring someone to invest into a physical limiter/compressor or requiring every single instrument isn't practical, nor the safest option.

Best,

Jake

--
Michael Gogins
Irreducible Productions
http://www.michael-gogins.com
Michael dot Gogins at gmail dot com

OK, this really makes no sense to me - how can a value larger than 0dbfs even come out of the sound card, when 0dbfs is by definition the csound value that translates to the largest sample the sound card can accept as a value.

quoting the manual page for 0dbfs:

"Amplitude values in Csound are always relative to a "0dbfs" value representing the peak available amplitude before clipping."

anything over 0dbfs is larger than the output format the sound card accepts, and is clipped to 0dbfs by the sound card's driver (or maybe wrapped to a lower value modulo the data size?), if not by csound beforehand.

On Mon, May 13, 2013 at 9:15 AM, Steven Yi <stevenyi@gmail.com> wrote:

... I'd rather like to have a built-in limiter by

default too, but set to some multiple of 0dbfs, perhaps +12db.

...

After being burned a few times too many on samples going way out of
range, I've gotten in the habit of putting a limiter on the master out
of my mixer instrument.  I'd rather like to have a built-in limiter by
default too, but set to some multiple of 0dbfs, perhaps +12db.  I
think having the extra space would be good so that you can hear if
something blows up, but without it getting to damaging levels.
Otherwise, I'm afraid someone might miss an out of range message or
just keep going with a limit-distorted signal thinking that was a
result of their instrument design, rather than the built-in limiter
kicking in.  Having this be adjustable by commandline-flag would be
good, with options to set the limit level including an off option.

On Mon, May 13, 2013 at 5:49 PM, Justin Smith <noisesmith@gmail.com> wrote:
> Wait, I don't understand?
>
> My impression was that when you set 0dbfs that would be the value that would
> translate to the largest magnitude possible to send to the sound card. How
> exactly would you output a value higher than the highest possible for the
> sound card? This seems absurd. If you don't want to use the full dynamic
> range of your sound card, then don't let your output reach the 0dbfs level,
> and frankly, if your speaker is too loud the right place to fix that is the
> amplification system, not the software outputting to it. For maximum audio
> quality you should be using the full available bit depth and adjusting on
> the amplifier end.
>
>
> On Mon, May 13, 2013 at 8:45 AM, Michael Gogins <michael.gogins@gmail.com>
> wrote:
>>
>> I have no problem with this as long as the limiter can be turned off using
>> a command line option.
>>
>> Regards,
>> Mike
>>
>>
>> On Mon, May 13, 2013 at 11:42 AM, Jacob Joaquin <jacobjoaquin@gmail.com>
>> wrote:
>>>
>>> I know this issue has come up in the past about limiting the output of a
>>> signal to 0dbfs. I was hoping that in Csound6 that this would be the case,
>>> though my ears just discovered this isn't the case. Very recently I had a
>>> very, *very* loud sound come out of my computer's built-in speakers, which I
>>> didn't realize they were capable of:
>>>
>>>   rtevent:   T1252.647 TT1252.647
>>> M:1471186648363761720503832244583935833526348654611550862152130928718211521883619377814242972039341828345952461695023580810974748468255456191775101001117160226807275991094039549552334879063512724258134702669861017454668597260286619400173267937575177772533863677952.00000
>>>
>>> Now that Csound6 is primed for realtime live-coding, potentially with
>>> audiences and giant speakers systems, it would be in the best interest to do
>>> everything possible to avoid causing long term hearing damage to everyone in
>>> the auditorium.
>>>
>>> And I specifically mean building the limiter directly into the Csound
>>> "out" series of opcodes and are turned on by default. Requiring someone to
>>> invest into a physical limiter/compressor or requiring every single
>>> instrument isn't practical, nor the safest option.
>>>
>>> Best,
>>> Jake
>>
>>
>>
>>
>> --
>> Michael Gogins
>> Irreducible Productions
>> http://www.michael-gogins.com
>> Michael dot Gogins at gmail dot com
>
>

Send bugs reports to the Sourceforge bug tracker
            https://sourceforge.net/tracker/?group_id=81968&atid=564599
Discussions of bugs and features can be posted here
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

I personally would prefer if it was at 0db by default for a couple reason. It would be right in line with much of the literature I've read about how in digital systems, 0db is the highest value you can generate. Even as a practical matter, I've worked on pieces in the past where everything sounded great as I rendered them in realtime, and then rendered a soundfile to share only to have it clipped and distorted.

Though having a command-line flag to optionally go beyond 0db would be a nice.

On Mon, May 13, 2013 at 9:15 AM, Steven Yi <stevenyi@gmail.com> wrote:

After being burned a few times too many on samples going way out of
range, I've gotten in the habit of putting a limiter on the master out
of my mixer instrument.  I'd rather like to have a built-in limiter by
default too, but set to some multiple of 0dbfs, perhaps +12db.  I
think having the extra space would be good so that you can hear if
something blows up, but without it getting to damaging levels.
Otherwise, I'm afraid someone might miss an out of range message or
just keep going with a limit-distorted signal thinking that was a
result of their instrument design, rather than the built-in limiter
kicking in.  Having this be adjustable by commandline-flag would be
good, with options to set the limit level including an off option.

On Mon, May 13, 2013 at 5:49 PM, Justin Smith <noisesmith@gmail.com> wrote:
> Wait, I don't understand?
>
> My impression was that when you set 0dbfs that would be the value that would
> translate to the largest magnitude possible to send to the sound card. How
> exactly would you output a value higher than the highest possible for the
> sound card? This seems absurd. If you don't want to use the full dynamic
> range of your sound card, then don't let your output reach the 0dbfs level,
> and frankly, if your speaker is too loud the right place to fix that is the
> amplification system, not the software outputting to it. For maximum audio
> quality you should be using the full available bit depth and adjusting on
> the amplifier end.
>
>
> On Mon, May 13, 2013 at 8:45 AM, Michael Gogins <michael.gogins@gmail.com>
> wrote:
>>
>> I have no problem with this as long as the limiter can be turned off using
>> a command line option.
>>
>> Regards,
>> Mike
>>
>>
>> On Mon, May 13, 2013 at 11:42 AM, Jacob Joaquin <jacobjoaquin@gmail.com>
>> wrote:
>>>
>>> I know this issue has come up in the past about limiting the output of a
>>> signal to 0dbfs. I was hoping that in Csound6 that this would be the case,
>>> though my ears just discovered this isn't the case. Very recently I had a
>>> very, *very* loud sound come out of my computer's built-in speakers, which I
>>> didn't realize they were capable of:
>>>
>>>   rtevent:   T1252.647 TT1252.647
>>> M:1471186648363761720503832244583935833526348654611550862152130928718211521883619377814242972039341828345952461695023580810974748468255456191775101001117160226807275991094039549552334879063512724258134702669861017454668597260286619400173267937575177772533863677952.00000
>>>
>>> Now that Csound6 is primed for realtime live-coding, potentially with
>>> audiences and giant speakers systems, it would be in the best interest to do
>>> everything possible to avoid causing long term hearing damage to everyone in
>>> the auditorium.
>>>
>>> And I specifically mean building the limiter directly into the Csound
>>> "out" series of opcodes and are turned on by default. Requiring someone to
>>> invest into a physical limiter/compressor or requiring every single
>>> instrument isn't practical, nor the safest option.
>>>
>>> Best,
>>> Jake
>>
>>
>>
>>
>> --
>> Michael Gogins
>> Irreducible Productions
>> http://www.michael-gogins.com
>> Michael dot Gogins at gmail dot com
>
>

Send bugs reports to the Sourceforge bug tracker
            https://sourceforge.net/tracker/?group_id=81968&atid=564599
Discussions of bugs and features can be posted here
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

--
codehop.com | #code #art #music

So csound can generate values higher than 0dbfs, and when scaled down by OS mixers it is no longer beyond the sound card's range?

Since we have no control about how software mixers on the OS behave, I suggest that csound should hard clip output to 0dbfs before sending it to an RT driver as the most reasonable behavior.

On Mon, May 13, 2013 at 9:33 AM, Jacob Joaquin <jacobjoaquin@gmail.com> wrote:

I personally would prefer if it was at 0db by default for a couple reason. It would be right in line with much of the literature I've read about how in digital systems, 0db is the highest value you can generate. Even as a practical matter, I've worked on pieces in the past where everything sounded great as I rendered them in realtime, and then rendered a soundfile to share only to have it clipped and distorted.

Though having a command-line flag to optionally go beyond 0db would be a nice.

On Mon, May 13, 2013 at 9:15 AM, Steven Yi <stevenyi@gmail.com> wrote:

After being burned a few times too many on samples going way out of
range, I've gotten in the habit of putting a limiter on the master out
of my mixer instrument.  I'd rather like to have a built-in limiter by
default too, but set to some multiple of 0dbfs, perhaps +12db.  I
think having the extra space would be good so that you can hear if
something blows up, but without it getting to damaging levels.
Otherwise, I'm afraid someone might miss an out of range message or
just keep going with a limit-distorted signal thinking that was a
result of their instrument design, rather than the built-in limiter
kicking in.  Having this be adjustable by commandline-flag would be
good, with options to set the limit level including an off option.

On Mon, May 13, 2013 at 5:49 PM, Justin Smith <noisesmith@gmail.com> wrote:
> Wait, I don't understand?
>
> My impression was that when you set 0dbfs that would be the value that would
> translate to the largest magnitude possible to send to the sound card. How
> exactly would you output a value higher than the highest possible for the
> sound card? This seems absurd. If you don't want to use the full dynamic
> range of your sound card, then don't let your output reach the 0dbfs level,
> and frankly, if your speaker is too loud the right place to fix that is the
> amplification system, not the software outputting to it. For maximum audio
> quality you should be using the full available bit depth and adjusting on
> the amplifier end.
>
>
> On Mon, May 13, 2013 at 8:45 AM, Michael Gogins <michael.gogins@gmail.com>
> wrote:
>>
>> I have no problem with this as long as the limiter can be turned off using
>> a command line option.
>>
>> Regards,
>> Mike
>>
>>
>> On Mon, May 13, 2013 at 11:42 AM, Jacob Joaquin <jacobjoaquin@gmail.com>
>> wrote:
>>>
>>> I know this issue has come up in the past about limiting the output of a
>>> signal to 0dbfs. I was hoping that in Csound6 that this would be the case,
>>> though my ears just discovered this isn't the case. Very recently I had a
>>> very, *very* loud sound come out of my computer's built-in speakers, which I
>>> didn't realize they were capable of:
>>>
>>>   rtevent:   T1252.647 TT1252.647
>>> M:1471186648363761720503832244583935833526348654611550862152130928718211521883619377814242972039341828345952461695023580810974748468255456191775101001117160226807275991094039549552334879063512724258134702669861017454668597260286619400173267937575177772533863677952.00000
>>>
>>> Now that Csound6 is primed for realtime live-coding, potentially with
>>> audiences and giant speakers systems, it would be in the best interest to do
>>> everything possible to avoid causing long term hearing damage to everyone in
>>> the auditorium.
>>>
>>> And I specifically mean building the limiter directly into the Csound
>>> "out" series of opcodes and are turned on by default. Requiring someone to
>>> invest into a physical limiter/compressor or requiring every single
>>> instrument isn't practical, nor the safest option.
>>>
>>> Best,
>>> Jake
>>
>>
>>
>>
>> --
>> Michael Gogins
>> Irreducible Productions
>> http://www.michael-gogins.com
>> Michael dot Gogins at gmail dot com
>
>

Send bugs reports to the Sourceforge bug tracker
            https://sourceforge.net/tracker/?group_id=81968&atid=564599
Discussions of bugs and features can be posted here
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

--
codehop.com | #code #art #music

So csound can generate values higher than 0dbfs, and when scaled down by OS mixers it is no longer beyond the sound card's range?

Since we have no control about how software mixers on the OS behave, I suggest that csound should hard clip output to 0dbfs before sending it to an RT driver as the most reasonable behavior.

On Mon, May 13, 2013 at 9:33 AM, Jacob Joaquin <jacobjoaquin@gmail.com> wrote:

I personally would prefer if it was at 0db by default for a couple reason. It would be right in line with much of the literature I've read about how in digital systems, 0db is the highest value you can generate. Even as a practical matter, I've worked on pieces in the past where everything sounded great as I rendered them in realtime, and then rendered a soundfile to share only to have it clipped and distorted.

Though having a command-line flag to optionally go beyond 0db would be a nice.

On Mon, May 13, 2013 at 9:15 AM, Steven Yi <stevenyi@gmail.com> wrote:

After being burned a few times too many on samples going way out of
range, I've gotten in the habit of putting a limiter on the master out
of my mixer instrument.  I'd rather like to have a built-in limiter by
default too, but set to some multiple of 0dbfs, perhaps +12db.  I
think having the extra space would be good so that you can hear if
something blows up, but without it getting to damaging levels.
Otherwise, I'm afraid someone might miss an out of range message or
just keep going with a limit-distorted signal thinking that was a
result of their instrument design, rather than the built-in limiter
kicking in.  Having this be adjustable by commandline-flag would be
good, with options to set the limit level including an off option.

On Mon, May 13, 2013 at 5:49 PM, Justin Smith <noisesmith@gmail.com> wrote:
> Wait, I don't understand?
>
> My impression was that when you set 0dbfs that would be the value that would
> translate to the largest magnitude possible to send to the sound card. How
> exactly would you output a value higher than the highest possible for the
> sound card? This seems absurd. If you don't want to use the full dynamic
> range of your sound card, then don't let your output reach the 0dbfs level,
> and frankly, if your speaker is too loud the right place to fix that is the
> amplification system, not the software outputting to it. For maximum audio
> quality you should be using the full available bit depth and adjusting on
> the amplifier end.
>
>
> On Mon, May 13, 2013 at 8:45 AM, Michael Gogins <michael.gogins@gmail.com>
> wrote:
>>
>> I have no problem with this as long as the limiter can be turned off using
>> a command line option.
>>
>> Regards,
>> Mike
>>
>>
>> On Mon, May 13, 2013 at 11:42 AM, Jacob Joaquin <jacobjoaquin@gmail.com>
>> wrote:
>>>
>>> I know this issue has come up in the past about limiting the output of a
>>> signal to 0dbfs. I was hoping that in Csound6 that this would be the case,
>>> though my ears just discovered this isn't the case. Very recently I had a
>>> very, *very* loud sound come out of my computer's built-in speakers, which I
>>> didn't realize they were capable of:
>>>
>>>   rtevent:   T1252.647 TT1252.647
>>> M:1471186648363761720503832244583935833526348654611550862152130928718211521883619377814242972039341828345952461695023580810974748468255456191775101001117160226807275991094039549552334879063512724258134702669861017454668597260286619400173267937575177772533863677952.00000
>>>
>>> Now that Csound6 is primed for realtime live-coding, potentially with
>>> audiences and giant speakers systems, it would be in the best interest to do
>>> everything possible to avoid causing long term hearing damage to everyone in
>>> the auditorium.
>>>
>>> And I specifically mean building the limiter directly into the Csound
>>> "out" series of opcodes and are turned on by default. Requiring someone to
>>> invest into a physical limiter/compressor or requiring every single
>>> instrument isn't practical, nor the safest option.
>>>
>>> Best,
>>> Jake
>>
>>
>>
>>
>> --
>> Michael Gogins
>> Irreducible Productions
>> http://www.michael-gogins.com
>> Michael dot Gogins at gmail dot com
>
>

Send bugs reports to the Sourceforge bug tracker
            https://sourceforge.net/tracker/?group_id=81968&atid=564599
Discussions of bugs and features can be posted here
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

--
codehop.com | #code #art #music

An analog to emphasize how ridiculous this software mixing behavior is:

imagine a program that specifies color brightness as floating point, and some user input results in pixel values that are beyond the range of the pixels of the hardware

the brightness of the windows is being controlled in the software compositing layer, and the user has turned down the brightness of the compositor to a very low level, and left all inputs to the compositors at a very high brightness which becomes normal to dim after the compositing is applied

the experimental graphics generating program produces pixel values that are so large they actually hit the full hardware output capacity of the monitor (which is very extreme) and produce an output which injures the user's eyes

where was the problem here?
a) the experimental graphics program sending arbitrary data to the compositor?
b) the compositor which allows inputs beyond the range the hardware can accept but then scales them rather than clipping them?
c) the user setting the hardware to such an extreme setting that it could cause injury?
d) the hardware maker producing a device capable of causing injury?

in graphics we have the common sense not to point a high powered projector directly at our eyes, and the software works directly with the data format that the graphics driver receives without arbitrary scaling happening in software.

On Mon, May 13, 2013 at 9:37 AM, Justin Smith <noisesmith@gmail.com> wrote:

So csound can generate values higher than 0dbfs, and when scaled down by OS mixers it is no longer beyond the sound card's range?

Since we have no control about how software mixers on the OS behave, I suggest that csound should hard clip output to 0dbfs before sending it to an RT driver as the most reasonable behavior.

On Mon, May 13, 2013 at 9:33 AM, Jacob Joaquin <jacobjoaquin@gmail.com> wrote:

I personally would prefer if it was at 0db by default for a couple reason. It would be right in line with much of the literature I've read about how in digital systems, 0db is the highest value you can generate. Even as a practical matter, I've worked on pieces in the past where everything sounded great as I rendered them in realtime, and then rendered a soundfile to share only to have it clipped and distorted.

Though having a command-line flag to optionally go beyond 0db would be a nice.

On Mon, May 13, 2013 at 9:15 AM, Steven Yi <stevenyi@gmail.com> wrote:

After being burned a few times too many on samples going way out of
range, I've gotten in the habit of putting a limiter on the master out
of my mixer instrument.  I'd rather like to have a built-in limiter by
default too, but set to some multiple of 0dbfs, perhaps +12db.  I
think having the extra space would be good so that you can hear if
something blows up, but without it getting to damaging levels.
Otherwise, I'm afraid someone might miss an out of range message or
just keep going with a limit-distorted signal thinking that was a
result of their instrument design, rather than the built-in limiter
kicking in.  Having this be adjustable by commandline-flag would be
good, with options to set the limit level including an off option.

On Mon, May 13, 2013 at 5:49 PM, Justin Smith <noisesmith@gmail.com> wrote:
> Wait, I don't understand?
>
> My impression was that when you set 0dbfs that would be the value that would
> translate to the largest magnitude possible to send to the sound card. How
> exactly would you output a value higher than the highest possible for the
> sound card? This seems absurd. If you don't want to use the full dynamic
> range of your sound card, then don't let your output reach the 0dbfs level,
> and frankly, if your speaker is too loud the right place to fix that is the
> amplification system, not the software outputting to it. For maximum audio
> quality you should be using the full available bit depth and adjusting on
> the amplifier end.
>
>
> On Mon, May 13, 2013 at 8:45 AM, Michael Gogins <michael.gogins@gmail.com>
> wrote:
>>
>> I have no problem with this as long as the limiter can be turned off using
>> a command line option.
>>
>> Regards,
>> Mike
>>
>>
>> On Mon, May 13, 2013 at 11:42 AM, Jacob Joaquin <jacobjoaquin@gmail.com>
>> wrote:
>>>
>>> I know this issue has come up in the past about limiting the output of a
>>> signal to 0dbfs. I was hoping that in Csound6 that this would be the case,
>>> though my ears just discovered this isn't the case. Very recently I had a
>>> very, *very* loud sound come out of my computer's built-in speakers, which I
>>> didn't realize they were capable of:
>>>
>>>   rtevent:   T1252.647 TT1252.647
>>> M:1471186648363761720503832244583935833526348654611550862152130928718211521883619377814242972039341828345952461695023580810974748468255456191775101001117160226807275991094039549552334879063512724258134702669861017454668597260286619400173267937575177772533863677952.00000
>>>
>>> Now that Csound6 is primed for realtime live-coding, potentially with
>>> audiences and giant speakers systems, it would be in the best interest to do
>>> everything possible to avoid causing long term hearing damage to everyone in
>>> the auditorium.
>>>
>>> And I specifically mean building the limiter directly into the Csound
>>> "out" series of opcodes and are turned on by default. Requiring someone to
>>> invest into a physical limiter/compressor or requiring every single
>>> instrument isn't practical, nor the safest option.
>>>
>>> Best,
>>> Jake
>>
>>
>>
>>
>> --
>> Michael Gogins
>> Irreducible Productions
>> http://www.michael-gogins.com
>> Michael dot Gogins at gmail dot com
>
>

Send bugs reports to the Sourceforge bug tracker
            https://sourceforge.net/tracker/?group_id=81968&atid=564599
Discussions of bugs and features can be posted here
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

--
codehop.com | #code #art #music

Hi Justin,

I haven't ever spent the time to figure out how these out of range
values can get so loud, but I'll take a guess here.  First, csound
renders internally with floats or doubles.  From here, it 0dbfs is
used to scale the generated value to the range of the output format.
The problem then is the assumption that the output is 16-bit short
values.   I think with Core Audio, the native rendering is 32-bit
floats; the link at [1] mentions:

"In OS X, Core Audio expects audio data to be in native-endian, 32-bit
floating-point, linear PCM format."

My guess is CoreAudio expects -/+1.0 range values, and that it itself
does not enforce that.  Also, the system volume control then would be
just an additional multiply to signals.  After that, any signal would
finally get converted to the HW data format necessary, where your
thoughts about 16-bit (or 24-bit, etc.) would apply.

I imagine if we rendered to file with 16-bit audio, we'd automatically
get clipped sound that in no way could go over the expected 0dbfs set
in Csound. I also imagine this situation is specifically an issue when
rendering in realtime, and may be an issue specific to OSX.

This is all just a guess though, but seems a reasonable assumption to
me at least. I'd welcome any corrections though.

Thanks!
steven


[1] - http://developer.apple.com/library/ios/#documentation/MusicAudio/Conceptual/CoreAudioOverview/WhatisCoreAudio/WhatisCoreAudio.html

On Mon, May 13, 2013 at 7:07 PM, Justin Smith <noisesmith@gmail.com> wrote:
> An analog to emphasize how ridiculous this software mixing behavior is:
>
> imagine a program that specifies color brightness as floating point, and
> some user input results in pixel values that are beyond the range of the
> pixels of the hardware
>
> the brightness of the windows is being controlled in the software
> compositing layer, and the user has turned down the brightness of the
> compositor to a very low level, and left all inputs to the compositors at a
> very high brightness which becomes normal to dim after the compositing is
> applied
>
> the experimental graphics generating program produces pixel values that are
> so large they actually hit the full hardware output capacity of the monitor
> (which is very extreme) and produce an output which injures the user's eyes
>
> where was the problem here?
> a) the experimental graphics program sending arbitrary data to the
> compositor?
> b) the compositor which allows inputs beyond the range the hardware can
> accept but then scales them rather than clipping them?
> c) the user setting the hardware to such an extreme setting that it could
> cause injury?
> d) the hardware maker producing a device capable of causing injury?
>
> in graphics we have the common sense not to point a high powered projector
> directly at our eyes, and the software works directly with the data format
> that the graphics driver receives without arbitrary scaling happening in
> software.
>
>
> On Mon, May 13, 2013 at 9:37 AM, Justin Smith <noisesmith@gmail.com> wrote:
>>
>> So csound can generate values higher than 0dbfs, and when scaled down by
>> OS mixers it is no longer beyond the sound card's range?
>>
>> Since we have no control about how software mixers on the OS behave, I
>> suggest that csound should hard clip output to 0dbfs before sending it to an
>> RT driver as the most reasonable behavior.
>>
>>
>> On Mon, May 13, 2013 at 9:33 AM, Jacob Joaquin <jacobjoaquin@gmail.com>
>> wrote:
>>>
>>> I personally would prefer if it was at 0db by default for a couple
>>> reason. It would be right in line with much of the literature I've read
>>> about how in digital systems, 0db is the highest value you can generate.
>>> Even as a practical matter, I've worked on pieces in the past where
>>> everything sounded great as I rendered them in realtime, and then rendered a
>>> soundfile to share only to have it clipped and distorted.
>>>
>>> Though having a command-line flag to optionally go beyond 0db would be a
>>> nice.
>>>
>>>
>>>
>>> On Mon, May 13, 2013 at 9:15 AM, Steven Yi <stevenyi@gmail.com> wrote:
>>>>
>>>> After being burned a few times too many on samples going way out of
>>>> range, I've gotten in the habit of putting a limiter on the master out
>>>> of my mixer instrument.  I'd rather like to have a built-in limiter by
>>>> default too, but set to some multiple of 0dbfs, perhaps +12db.  I
>>>> think having the extra space would be good so that you can hear if
>>>> something blows up, but without it getting to damaging levels.
>>>> Otherwise, I'm afraid someone might miss an out of range message or
>>>> just keep going with a limit-distorted signal thinking that was a
>>>> result of their instrument design, rather than the built-in limiter
>>>> kicking in.  Having this be adjustable by commandline-flag would be
>>>> good, with options to set the limit level including an off option.
>>>>
>>>> On Mon, May 13, 2013 at 5:49 PM, Justin Smith <noisesmith@gmail.com>
>>>> wrote:
>>>> > Wait, I don't understand?
>>>> >
>>>> > My impression was that when you set 0dbfs that would be the value that
>>>> > would
>>>> > translate to the largest magnitude possible to send to the sound card.
>>>> > How
>>>> > exactly would you output a value higher than the highest possible for
>>>> > the
>>>> > sound card? This seems absurd. If you don't want to use the full
>>>> > dynamic
>>>> > range of your sound card, then don't let your output reach the 0dbfs
>>>> > level,
>>>> > and frankly, if your speaker is too loud the right place to fix that
>>>> > is the
>>>> > amplification system, not the software outputting to it. For maximum
>>>> > audio
>>>> > quality you should be using the full available bit depth and adjusting
>>>> > on
>>>> > the amplifier end.
>>>> >
>>>> >
>>>> > On Mon, May 13, 2013 at 8:45 AM, Michael Gogins
>>>> > <michael.gogins@gmail.com>
>>>> > wrote:
>>>> >>
>>>> >> I have no problem with this as long as the limiter can be turned off
>>>> >> using
>>>> >> a command line option.
>>>> >>
>>>> >> Regards,
>>>> >> Mike
>>>> >>
>>>> >>
>>>> >> On Mon, May 13, 2013 at 11:42 AM, Jacob Joaquin
>>>> >> <jacobjoaquin@gmail.com>
>>>> >> wrote:
>>>> >>>
>>>> >>> I know this issue has come up in the past about limiting the output
>>>> >>> of a
>>>> >>> signal to 0dbfs. I was hoping that in Csound6 that this would be the
>>>> >>> case,
>>>> >>> though my ears just discovered this isn't the case. Very recently I
>>>> >>> had a
>>>> >>> very, *very* loud sound come out of my computer's built-in speakers,
>>>> >>> which I
>>>> >>> didn't realize they were capable of:
>>>> >>>
>>>> >>>   rtevent:   T1252.647 TT1252.647
>>>> >>>
>>>> >>> M:1471186648363761720503832244583935833526348654611550862152130928718211521883619377814242972039341828345952461695023580810974748468255456191775101001117160226807275991094039549552334879063512724258134702669861017454668597260286619400173267937575177772533863677952.00000
>>>> >>>
>>>> >>> Now that Csound6 is primed for realtime live-coding, potentially
>>>> >>> with
>>>> >>> audiences and giant speakers systems, it would be in the best
>>>> >>> interest to do
>>>> >>> everything possible to avoid causing long term hearing damage to
>>>> >>> everyone in
>>>> >>> the auditorium.
>>>> >>>
>>>> >>> And I specifically mean building the limiter directly into the
>>>> >>> Csound
>>>> >>> "out" series of opcodes and are turned on by default. Requiring
>>>> >>> someone to
>>>> >>> invest into a physical limiter/compressor or requiring every single
>>>> >>> instrument isn't practical, nor the safest option.
>>>> >>>
>>>> >>> Best,
>>>> >>> Jake
>>>> >>
>>>> >>
>>>> >>
>>>> >>
>>>> >> --
>>>> >> Michael Gogins
>>>> >> Irreducible Productions
>>>> >> http://www.michael-gogins.com
>>>> >> Michael dot Gogins at gmail dot com
>>>> >
>>>> >
>>>>
>>>>
>>>> Send bugs reports to the Sourceforge bug tracker
>>>>             https://sourceforge.net/tracker/?group_id=81968&atid=564599
>>>> Discussions of bugs and features can be posted here
>>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>>>> csound"
>>>>
>>>
>>>
>>>
>>> --
>>> codehop.com | #code #art #music
>>
>>
>


Send bugs reports to the Sourceforge bug tracker
            https://sourceforge.net/tracker/?group_id=81968&atid=564599
Discussions of bugs and features can be posted here
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

How about a new global variable called "clip":

sr = 44100

ksmps = 128

0dbfs = 1.0

clip = 0.5

That way you can force clipping even at a lower amplitude than 0dbfs. This would be very useful for multichannel systems or for systems with very loud loudspeakers (where no external mixer or level is available).

Cheers,
Andrés

On Mon, May 13, 2013 at 10:31 AM, Steven Yi <stevenyi@gmail.com> wrote:

Hi Justin,

I haven't ever spent the time to figure out how these out of range
values can get so loud, but I'll take a guess here.  First, csound
renders internally with floats or doubles.  From here, it 0dbfs is
used to scale the generated value to the range of the output format.
The problem then is the assumption that the output is 16-bit short
values.   I think with Core Audio, the native rendering is 32-bit
floats; the link at [1] mentions:

"In OS X, Core Audio expects audio data to be in native-endian, 32-bit
floating-point, linear PCM format."

My guess is CoreAudio expects -/+1.0 range values, and that it itself
does not enforce that.  Also, the system volume control then would be
just an additional multiply to signals.  After that, any signal would
finally get converted to the HW data format necessary, where your
thoughts about 16-bit (or 24-bit, etc.) would apply.

I imagine if we rendered to file with 16-bit audio, we'd automatically
get clipped sound that in no way could go over the expected 0dbfs set
in Csound. I also imagine this situation is specifically an issue when
rendering in realtime, and may be an issue specific to OSX.

This is all just a guess though, but seems a reasonable assumption to
me at least. I'd welcome any corrections though.

Thanks!
steven


[1] - http://developer.apple.com/library/ios/#documentation/MusicAudio/Conceptual/CoreAudioOverview/WhatisCoreAudio/WhatisCoreAudio.html

On Mon, May 13, 2013 at 7:07 PM, Justin Smith <noisesmith@gmail.com> wrote:
> An analog to emphasize how ridiculous this software mixing behavior is:
>
> imagine a program that specifies color brightness as floating point, and
> some user input results in pixel values that are beyond the range of the
> pixels of the hardware
>
> the brightness of the windows is being controlled in the software
> compositing layer, and the user has turned down the brightness of the
> compositor to a very low level, and left all inputs to the compositors at a
> very high brightness which becomes normal to dim after the compositing is
> applied
>
> the experimental graphics generating program produces pixel values that are
> so large they actually hit the full hardware output capacity of the monitor
> (which is very extreme) and produce an output which injures the user's eyes
>
> where was the problem here?
> a) the experimental graphics program sending arbitrary data to the
> compositor?
> b) the compositor which allows inputs beyond the range the hardware can
> accept but then scales them rather than clipping them?
> c) the user setting the hardware to such an extreme setting that it could
> cause injury?
> d) the hardware maker producing a device capable of causing injury?
>
> in graphics we have the common sense not to point a high powered projector
> directly at our eyes, and the software works directly with the data format
> that the graphics driver receives without arbitrary scaling happening in
> software.
>
>
> On Mon, May 13, 2013 at 9:37 AM, Justin Smith <noisesmith@gmail.com> wrote:
>>
>> So csound can generate values higher than 0dbfs, and when scaled down by
>> OS mixers it is no longer beyond the sound card's range?
>>
>> Since we have no control about how software mixers on the OS behave, I
>> suggest that csound should hard clip output to 0dbfs before sending it to an
>> RT driver as the most reasonable behavior.
>>
>>
>> On Mon, May 13, 2013 at 9:33 AM, Jacob Joaquin <jacobjoaquin@gmail.com>
>> wrote:
>>>
>>> I personally would prefer if it was at 0db by default for a couple
>>> reason. It would be right in line with much of the literature I've read
>>> about how in digital systems, 0db is the highest value you can generate.
>>> Even as a practical matter, I've worked on pieces in the past where
>>> everything sounded great as I rendered them in realtime, and then rendered a
>>> soundfile to share only to have it clipped and distorted.
>>>
>>> Though having a command-line flag to optionally go beyond 0db would be a
>>> nice.
>>>
>>>
>>>
>>> On Mon, May 13, 2013 at 9:15 AM, Steven Yi <stevenyi@gmail.com> wrote:
>>>>
>>>> After being burned a few times too many on samples going way out of
>>>> range, I've gotten in the habit of putting a limiter on the master out
>>>> of my mixer instrument.  I'd rather like to have a built-in limiter by
>>>> default too, but set to some multiple of 0dbfs, perhaps +12db.  I
>>>> think having the extra space would be good so that you can hear if
>>>> something blows up, but without it getting to damaging levels.
>>>> Otherwise, I'm afraid someone might miss an out of range message or
>>>> just keep going with a limit-distorted signal thinking that was a
>>>> result of their instrument design, rather than the built-in limiter
>>>> kicking in.  Having this be adjustable by commandline-flag would be
>>>> good, with options to set the limit level including an off option.
>>>>
>>>> On Mon, May 13, 2013 at 5:49 PM, Justin Smith <noisesmith@gmail.com>
>>>> wrote:
>>>> > Wait, I don't understand?
>>>> >
>>>> > My impression was that when you set 0dbfs that would be the value that
>>>> > would
>>>> > translate to the largest magnitude possible to send to the sound card.
>>>> > How
>>>> > exactly would you output a value higher than the highest possible for
>>>> > the
>>>> > sound card? This seems absurd. If you don't want to use the full
>>>> > dynamic
>>>> > range of your sound card, then don't let your output reach the 0dbfs
>>>> > level,
>>>> > and frankly, if your speaker is too loud the right place to fix that
>>>> > is the
>>>> > amplification system, not the software outputting to it. For maximum
>>>> > audio
>>>> > quality you should be using the full available bit depth and adjusting
>>>> > on
>>>> > the amplifier end.
>>>> >
>>>> >
>>>> > On Mon, May 13, 2013 at 8:45 AM, Michael Gogins
>>>> > <michael.gogins@gmail.com>
>>>> > wrote:
>>>> >>
>>>> >> I have no problem with this as long as the limiter can be turned off
>>>> >> using
>>>> >> a command line option.
>>>> >>
>>>> >> Regards,
>>>> >> Mike
>>>> >>
>>>> >>
>>>> >> On Mon, May 13, 2013 at 11:42 AM, Jacob Joaquin
>>>> >> <jacobjoaquin@gmail.com>
>>>> >> wrote:
>>>> >>>
>>>> >>> I know this issue has come up in the past about limiting the output
>>>> >>> of a
>>>> >>> signal to 0dbfs. I was hoping that in Csound6 that this would be the
>>>> >>> case,
>>>> >>> though my ears just discovered this isn't the case. Very recently I
>>>> >>> had a
>>>> >>> very, *very* loud sound come out of my computer's built-in speakers,
>>>> >>> which I
>>>> >>> didn't realize they were capable of:
>>>> >>>
>>>> >>>   rtevent:   T1252.647 TT1252.647
>>>> >>>
>>>> >>> M:1471186648363761720503832244583935833526348654611550862152130928718211521883619377814242972039341828345952461695023580810974748468255456191775101001117160226807275991094039549552334879063512724258134702669861017454668597260286619400173267937575177772533863677952.00000
>>>> >>>
>>>> >>> Now that Csound6 is primed for realtime live-coding, potentially
>>>> >>> with
>>>> >>> audiences and giant speakers systems, it would be in the best
>>>> >>> interest to do
>>>> >>> everything possible to avoid causing long term hearing damage to
>>>> >>> everyone in
>>>> >>> the auditorium.
>>>> >>>
>>>> >>> And I specifically mean building the limiter directly into the
>>>> >>> Csound
>>>> >>> "out" series of opcodes and are turned on by default. Requiring
>>>> >>> someone to
>>>> >>> invest into a physical limiter/compressor or requiring every single
>>>> >>> instrument isn't practical, nor the safest option.
>>>> >>>
>>>> >>> Best,
>>>> >>> Jake
>>>> >>
>>>> >>
>>>> >>
>>>> >>
>>>> >> --
>>>> >> Michael Gogins
>>>> >> Irreducible Productions
>>>> >> http://www.michael-gogins.com
>>>> >> Michael dot Gogins at gmail dot com
>>>> >
>>>> >
>>>>
>>>>
>>>> Send bugs reports to the Sourceforge bug tracker
>>>>             https://sourceforge.net/tracker/?group_id=81968&atid=564599
>>>> Discussions of bugs and features can be posted here
>>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>>>> csound"
>>>>
>>>
>>>
>>>
>>> --
>>> codehop.com | #code #art #music
>>
>>
>


Send bugs reports to the Sourceforge bug tracker
            https://sourceforge.net/tracker/?group_id=81968&atid=564599
Discussions of bugs and features can be posted here
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

By analogy with analog gear, clipping would occur at some amplitude above 0 dB, typically +6 to +12 dB.

Regards,

Mike

On Mon, May 13, 2013 at 7:25 PM, Andres Cabrera <mantaraya36@gmail.com> wrote:

How about a new global variable called "clip":

sr = 44100

ksmps = 128

0dbfs = 1.0

clip = 0.5

That way you can force clipping even at a lower amplitude than 0dbfs. This would be very useful for multichannel systems or for systems with very loud loudspeakers (where no external mixer or level is available).

Cheers,
Andrés

On Mon, May 13, 2013 at 10:31 AM, Steven Yi <stevenyi@gmail.com> wrote:

Hi Justin,

I haven't ever spent the time to figure out how these out of range
values can get so loud, but I'll take a guess here.  First, csound
renders internally with floats or doubles.  From here, it 0dbfs is
used to scale the generated value to the range of the output format.
The problem then is the assumption that the output is 16-bit short
values.   I think with Core Audio, the native rendering is 32-bit
floats; the link at [1] mentions:

"In OS X, Core Audio expects audio data to be in native-endian, 32-bit
floating-point, linear PCM format."

My guess is CoreAudio expects -/+1.0 range values, and that it itself
does not enforce that.  Also, the system volume control then would be
just an additional multiply to signals.  After that, any signal would
finally get converted to the HW data format necessary, where your
thoughts about 16-bit (or 24-bit, etc.) would apply.

I imagine if we rendered to file with 16-bit audio, we'd automatically
get clipped sound that in no way could go over the expected 0dbfs set
in Csound. I also imagine this situation is specifically an issue when
rendering in realtime, and may be an issue specific to OSX.

This is all just a guess though, but seems a reasonable assumption to
me at least. I'd welcome any corrections though.

Thanks!
steven


[1] - http://developer.apple.com/library/ios/#documentation/MusicAudio/Conceptual/CoreAudioOverview/WhatisCoreAudio/WhatisCoreAudio.html

On Mon, May 13, 2013 at 7:07 PM, Justin Smith <noisesmith@gmail.com> wrote:
> An analog to emphasize how ridiculous this software mixing behavior is:
>
> imagine a program that specifies color brightness as floating point, and
> some user input results in pixel values that are beyond the range of the
> pixels of the hardware
>
> the brightness of the windows is being controlled in the software
> compositing layer, and the user has turned down the brightness of the
> compositor to a very low level, and left all inputs to the compositors at a
> very high brightness which becomes normal to dim after the compositing is
> applied
>
> the experimental graphics generating program produces pixel values that are
> so large they actually hit the full hardware output capacity of the monitor
> (which is very extreme) and produce an output which injures the user's eyes
>
> where was the problem here?
> a) the experimental graphics program sending arbitrary data to the
> compositor?
> b) the compositor which allows inputs beyond the range the hardware can
> accept but then scales them rather than clipping them?
> c) the user setting the hardware to such an extreme setting that it could
> cause injury?
> d) the hardware maker producing a device capable of causing injury?
>
> in graphics we have the common sense not to point a high powered projector
> directly at our eyes, and the software works directly with the data format
> that the graphics driver receives without arbitrary scaling happening in
> software.
>
>
> On Mon, May 13, 2013 at 9:37 AM, Justin Smith <noisesmith@gmail.com> wrote:
>>
>> So csound can generate values higher than 0dbfs, and when scaled down by
>> OS mixers it is no longer beyond the sound card's range?
>>
>> Since we have no control about how software mixers on the OS behave, I
>> suggest that csound should hard clip output to 0dbfs before sending it to an
>> RT driver as the most reasonable behavior.
>>
>>
>> On Mon, May 13, 2013 at 9:33 AM, Jacob Joaquin <jacobjoaquin@gmail.com>
>> wrote:
>>>
>>> I personally would prefer if it was at 0db by default for a couple
>>> reason. It would be right in line with much of the literature I've read
>>> about how in digital systems, 0db is the highest value you can generate.
>>> Even as a practical matter, I've worked on pieces in the past where
>>> everything sounded great as I rendered them in realtime, and then rendered a
>>> soundfile to share only to have it clipped and distorted.
>>>
>>> Though having a command-line flag to optionally go beyond 0db would be a
>>> nice.
>>>
>>>
>>>
>>> On Mon, May 13, 2013 at 9:15 AM, Steven Yi <stevenyi@gmail.com> wrote:
>>>>
>>>> After being burned a few times too many on samples going way out of
>>>> range, I've gotten in the habit of putting a limiter on the master out
>>>> of my mixer instrument.  I'd rather like to have a built-in limiter by
>>>> default too, but set to some multiple of 0dbfs, perhaps +12db.  I
>>>> think having the extra space would be good so that you can hear if
>>>> something blows up, but without it getting to damaging levels.
>>>> Otherwise, I'm afraid someone might miss an out of range message or
>>>> just keep going with a limit-distorted signal thinking that was a
>>>> result of their instrument design, rather than the built-in limiter
>>>> kicking in.  Having this be adjustable by commandline-flag would be
>>>> good, with options to set the limit level including an off option.
>>>>
>>>> On Mon, May 13, 2013 at 5:49 PM, Justin Smith <noisesmith@gmail.com>
>>>> wrote:
>>>> > Wait, I don't understand?
>>>> >
>>>> > My impression was that when you set 0dbfs that would be the value that
>>>> > would
>>>> > translate to the largest magnitude possible to send to the sound card.
>>>> > How
>>>> > exactly would you output a value higher than the highest possible for
>>>> > the
>>>> > sound card? This seems absurd. If you don't want to use the full
>>>> > dynamic
>>>> > range of your sound card, then don't let your output reach the 0dbfs
>>>> > level,
>>>> > and frankly, if your speaker is too loud the right place to fix that
>>>> > is the
>>>> > amplification system, not the software outputting to it. For maximum
>>>> > audio
>>>> > quality you should be using the full available bit depth and adjusting
>>>> > on
>>>> > the amplifier end.
>>>> >
>>>> >
>>>> > On Mon, May 13, 2013 at 8:45 AM, Michael Gogins
>>>> > <michael.gogins@gmail.com>
>>>> > wrote:
>>>> >>
>>>> >> I have no problem with this as long as the limiter can be turned off
>>>> >> using
>>>> >> a command line option.
>>>> >>
>>>> >> Regards,
>>>> >> Mike
>>>> >>
>>>> >>
>>>> >> On Mon, May 13, 2013 at 11:42 AM, Jacob Joaquin
>>>> >> <jacobjoaquin@gmail.com>
>>>> >> wrote:
>>>> >>>
>>>> >>> I know this issue has come up in the past about limiting the output
>>>> >>> of a
>>>> >>> signal to 0dbfs. I was hoping that in Csound6 that this would be the
>>>> >>> case,
>>>> >>> though my ears just discovered this isn't the case. Very recently I
>>>> >>> had a
>>>> >>> very, *very* loud sound come out of my computer's built-in speakers,
>>>> >>> which I
>>>> >>> didn't realize they were capable of:
>>>> >>>
>>>> >>>   rtevent:   T1252.647 TT1252.647
>>>> >>>
>>>> >>> M:1471186648363761720503832244583935833526348654611550862152130928718211521883619377814242972039341828345952461695023580810974748468255456191775101001117160226807275991094039549552334879063512724258134702669861017454668597260286619400173267937575177772533863677952.00000
>>>> >>>
>>>> >>> Now that Csound6 is primed for realtime live-coding, potentially
>>>> >>> with
>>>> >>> audiences and giant speakers systems, it would be in the best
>>>> >>> interest to do
>>>> >>> everything possible to avoid causing long term hearing damage to
>>>> >>> everyone in
>>>> >>> the auditorium.
>>>> >>>
>>>> >>> And I specifically mean building the limiter directly into the
>>>> >>> Csound
>>>> >>> "out" series of opcodes and are turned on by default. Requiring
>>>> >>> someone to
>>>> >>> invest into a physical limiter/compressor or requiring every single
>>>> >>> instrument isn't practical, nor the safest option.
>>>> >>>
>>>> >>> Best,
>>>> >>> Jake
>>>> >>
>>>> >>
>>>> >>
>>>> >>
>>>> >> --
>>>> >> Michael Gogins
>>>> >> Irreducible Productions
>>>> >> http://www.michael-gogins.com
>>>> >> Michael dot Gogins at gmail dot com
>>>> >
>>>> >
>>>>
>>>>
>>>> Send bugs reports to the Sourceforge bug tracker
>>>>             https://sourceforge.net/tracker/?group_id=81968&atid=564599
>>>> Discussions of bugs and features can be posted here
>>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>>>> csound"
>>>>
>>>
>>>
>>>
>>> --
>>> codehop.com | #code #art #music
>>
>>
>


Send bugs reports to the Sourceforge bug tracker
            https://sourceforge.net/tracker/?group_id=81968&atid=564599
Discussions of bugs and features can be posted here
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

--
Michael Gogins
Irreducible Productions
http://www.michael-gogins.com
Michael dot Gogins at gmail dot com

By analogy with analog gear, clipping would occur at some amplitude above 0 dB, typically +6 to +12 dB.

Regards,

Mike

On Mon, May 13, 2013 at 7:25 PM, Andres Cabrera <mantaraya36@gmail.com> wrote:

How about a new global variable called "clip":

sr = 44100

ksmps = 128

0dbfs = 1.0

clip = 0.5

That way you can force clipping even at a lower amplitude than 0dbfs. This would be very useful for multichannel systems or for systems with very loud loudspeakers (where no external mixer or level is available).

Cheers,
Andrés

On Mon, May 13, 2013 at 10:31 AM, Steven Yi <stevenyi@gmail.com> wrote:

Hi Justin,

I haven't ever spent the time to figure out how these out of range
values can get so loud, but I'll take a guess here.  First, csound
renders internally with floats or doubles.  From here, it 0dbfs is
used to scale the generated value to the range of the output format.
The problem then is the assumption that the output is 16-bit short
values.   I think with Core Audio, the native rendering is 32-bit
floats; the link at [1] mentions:

"In OS X, Core Audio expects audio data to be in native-endian, 32-bit
floating-point, linear PCM format."

My guess is CoreAudio expects -/+1.0 range values, and that it itself
does not enforce that.  Also, the system volume control then would be
just an additional multiply to signals.  After that, any signal would
finally get converted to the HW data format necessary, where your
thoughts about 16-bit (or 24-bit, etc.) would apply.

I imagine if we rendered to file with 16-bit audio, we'd automatically
get clipped sound that in no way could go over the expected 0dbfs set
in Csound. I also imagine this situation is specifically an issue when
rendering in realtime, and may be an issue specific to OSX.

This is all just a guess though, but seems a reasonable assumption to
me at least. I'd welcome any corrections though.

Thanks!
steven


[1] - http://developer.apple.com/library/ios/#documentation/MusicAudio/Conceptual/CoreAudioOverview/WhatisCoreAudio/WhatisCoreAudio.html

On Mon, May 13, 2013 at 7:07 PM, Justin Smith <noisesmith@gmail.com> wrote:
> An analog to emphasize how ridiculous this software mixing behavior is:
>
> imagine a program that specifies color brightness as floating point, and
> some user input results in pixel values that are beyond the range of the
> pixels of the hardware
>
> the brightness of the windows is being controlled in the software
> compositing layer, and the user has turned down the brightness of the
> compositor to a very low level, and left all inputs to the compositors at a
> very high brightness which becomes normal to dim after the compositing is
> applied
>
> the experimental graphics generating program produces pixel values that are
> so large they actually hit the full hardware output capacity of the monitor
> (which is very extreme) and produce an output which injures the user's eyes
>
> where was the problem here?
> a) the experimental graphics program sending arbitrary data to the
> compositor?
> b) the compositor which allows inputs beyond the range the hardware can
> accept but then scales them rather than clipping them?
> c) the user setting the hardware to such an extreme setting that it could
> cause injury?
> d) the hardware maker producing a device capable of causing injury?
>
> in graphics we have the common sense not to point a high powered projector
> directly at our eyes, and the software works directly with the data format
> that the graphics driver receives without arbitrary scaling happening in
> software.
>
>
> On Mon, May 13, 2013 at 9:37 AM, Justin Smith <noisesmith@gmail.com> wrote:
>>
>> So csound can generate values higher than 0dbfs, and when scaled down by
>> OS mixers it is no longer beyond the sound card's range?
>>
>> Since we have no control about how software mixers on the OS behave, I
>> suggest that csound should hard clip output to 0dbfs before sending it to an
>> RT driver as the most reasonable behavior.
>>
>>
>> On Mon, May 13, 2013 at 9:33 AM, Jacob Joaquin <jacobjoaquin@gmail.com>
>> wrote:
>>>
>>> I personally would prefer if it was at 0db by default for a couple
>>> reason. It would be right in line with much of the literature I've read
>>> about how in digital systems, 0db is the highest value you can generate.
>>> Even as a practical matter, I've worked on pieces in the past where
>>> everything sounded great as I rendered them in realtime, and then rendered a
>>> soundfile to share only to have it clipped and distorted.
>>>
>>> Though having a command-line flag to optionally go beyond 0db would be a
>>> nice.
>>>
>>>
>>>
>>> On Mon, May 13, 2013 at 9:15 AM, Steven Yi <stevenyi@gmail.com> wrote:
>>>>
>>>> After being burned a few times too many on samples going way out of
>>>> range, I've gotten in the habit of putting a limiter on the master out
>>>> of my mixer instrument.  I'd rather like to have a built-in limiter by
>>>> default too, but set to some multiple of 0dbfs, perhaps +12db.  I
>>>> think having the extra space would be good so that you can hear if
>>>> something blows up, but without it getting to damaging levels.
>>>> Otherwise, I'm afraid someone might miss an out of range message or
>>>> just keep going with a limit-distorted signal thinking that was a
>>>> result of their instrument design, rather than the built-in limiter
>>>> kicking in.  Having this be adjustable by commandline-flag would be
>>>> good, with options to set the limit level including an off option.
>>>>
>>>> On Mon, May 13, 2013 at 5:49 PM, Justin Smith <noisesmith@gmail.com>
>>>> wrote:
>>>> > Wait, I don't understand?
>>>> >
>>>> > My impression was that when you set 0dbfs that would be the value that
>>>> > would
>>>> > translate to the largest magnitude possible to send to the sound card.
>>>> > How
>>>> > exactly would you output a value higher than the highest possible for
>>>> > the
>>>> > sound card? This seems absurd. If you don't want to use the full
>>>> > dynamic
>>>> > range of your sound card, then don't let your output reach the 0dbfs
>>>> > level,
>>>> > and frankly, if your speaker is too loud the right place to fix that
>>>> > is the
>>>> > amplification system, not the software outputting to it. For maximum
>>>> > audio
>>>> > quality you should be using the full available bit depth and adjusting
>>>> > on
>>>> > the amplifier end.
>>>> >
>>>> >
>>>> > On Mon, May 13, 2013 at 8:45 AM, Michael Gogins
>>>> > <michael.gogins@gmail.com>
>>>> > wrote:
>>>> >>
>>>> >> I have no problem with this as long as the limiter can be turned off
>>>> >> using
>>>> >> a command line option.
>>>> >>
>>>> >> Regards,
>>>> >> Mike
>>>> >>
>>>> >>
>>>> >> On Mon, May 13, 2013 at 11:42 AM, Jacob Joaquin
>>>> >> <jacobjoaquin@gmail.com>
>>>> >> wrote:
>>>> >>>
>>>> >>> I know this issue has come up in the past about limiting the output
>>>> >>> of a
>>>> >>> signal to 0dbfs. I was hoping that in Csound6 that this would be the
>>>> >>> case,
>>>> >>> though my ears just discovered this isn't the case. Very recently I
>>>> >>> had a
>>>> >>> very, *very* loud sound come out of my computer's built-in speakers,
>>>> >>> which I
>>>> >>> didn't realize they were capable of:
>>>> >>>
>>>> >>>   rtevent:   T1252.647 TT1252.647
>>>> >>>
>>>> >>> M:1471186648363761720503832244583935833526348654611550862152130928718211521883619377814242972039341828345952461695023580810974748468255456191775101001117160226807275991094039549552334879063512724258134702669861017454668597260286619400173267937575177772533863677952.00000
>>>> >>>
>>>> >>> Now that Csound6 is primed for realtime live-coding, potentially
>>>> >>> with
>>>> >>> audiences and giant speakers systems, it would be in the best
>>>> >>> interest to do
>>>> >>> everything possible to avoid causing long term hearing damage to
>>>> >>> everyone in
>>>> >>> the auditorium.
>>>> >>>
>>>> >>> And I specifically mean building the limiter directly into the
>>>> >>> Csound
>>>> >>> "out" series of opcodes and are turned on by default. Requiring
>>>> >>> someone to
>>>> >>> invest into a physical limiter/compressor or requiring every single
>>>> >>> instrument isn't practical, nor the safest option.
>>>> >>>
>>>> >>> Best,
>>>> >>> Jake
>>>> >>
>>>> >>
>>>> >>
>>>> >>
>>>> >> --
>>>> >> Michael Gogins
>>>> >> Irreducible Productions
>>>> >> http://www.michael-gogins.com
>>>> >> Michael dot Gogins at gmail dot com
>>>> >
>>>> >
>>>>
>>>>
>>>> Send bugs reports to the Sourceforge bug tracker
>>>>             https://sourceforge.net/tracker/?group_id=81968&atid=564599
>>>> Discussions of bugs and features can be posted here
>>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>>>> csound"
>>>>
>>>
>>>
>>>
>>> --
>>> codehop.com | #code #art #music
>>
>>
>


Send bugs reports to the Sourceforge bug tracker
            https://sourceforge.net/tracker/?group_id=81968&atid=564599
Discussions of bugs and features can be posted here
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

--
Michael Gogins
Irreducible Productions
http://www.michael-gogins.com
Michael dot Gogins at gmail dot com