Re: [PD] headroom in Pd

2014-01-01 Thread Dan Wilcox
I know. My response was tongue in cheek as I knew this ahead of time but, so 
far, it hasn't been a problem with the music that I make ...

On Jan 1, 2014, at 2:08 AM, pd-list-requ...@iem.at wrote:

 From: Simon Wise simonzw...@gmail.com
 Subject: Re: [PD] headroom in Pd
 Date: January 1, 2014 at 12:50:55 AM GMT+1
 To: pd-list@iem.at
 
 
 On 31/12/13 08:30, Dan Wilcox wrote:
 Ouch. I guess alot of us don't have serious projects :D (Out of curiosity, 
 does Max do soft clipping also?)
 
 the point was that OSX was messing with the sound between the software, 
 presumably any software, and the audio output ... which may perhaps be called 
 a feature while listening to songs in iTunes but is a big worry if you are 
 trying to use the system seriously as a musician. It is a problem that comes 
 up on this list from time to time, I don't recall any reply saying it could 
 be bypassed or turned off.
 
 Simon


Dan Wilcox
@danomatika
danomatika.com
robotcowboy.com





___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list


Re: [PD] headroom in Pd

2014-01-01 Thread Martin Peach

On 2013-12-31 19:32, Chris Clepper wrote:

It's very, very easy to avoid any sort of clipping processing by using
hardware with drivers that don't have any!  Avid, Apogee, MOTU, RME, and
many others have bit transparent OSX CoreAudio drivers.

Also, any DAC worth it's using can reconstruct far beyond 0dBFS without
distortion, so hearing volume increase past -1..1 in software is not
surprising.  I recall the ADI 1955 and equivalent TI part putting out
+12dBFS or something ridiculous, but those ain't Wolfson low power
headphone codecs neither!



A DAC can only go to 0dBFS by definition. If it appears to go beyond 
that then something is scaling the input to be less than full scale at 
full scale.
For instance a 24-bit DAC could be sent 16 16-bit full-scale streams and 
not clip. Only if 16-bits is considered full scale does that make it 
+12dBFS.


Martin


___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list


Re: [PD] headroom in Pd

2014-01-01 Thread Chris Clepper
Nope, the DAC can freely construct intersample peaks as it sees fit and
those can easily exceed 0 dBFS.  It has been common practice in the
industry for more than a decade to reconstruct clipped samples well above 0
dBFS - partially to make up for shitty mixing and mastering prevalent in
music, and also because it's the right way to do it.

16 bits full scale and 24 bits full scale are the same 0dBFS signal.  The
bits are added at the bottom not the top.



On Wed, Jan 1, 2014 at 1:34 PM, Martin Peach martin.pe...@sympatico.cawrote:

 On 2013-12-31 19:32, Chris Clepper wrote:

 It's very, very easy to avoid any sort of clipping processing by using
 hardware with drivers that don't have any!  Avid, Apogee, MOTU, RME, and
 many others have bit transparent OSX CoreAudio drivers.

 Also, any DAC worth it's using can reconstruct far beyond 0dBFS without
 distortion, so hearing volume increase past -1..1 in software is not
 surprising.  I recall the ADI 1955 and equivalent TI part putting out
 +12dBFS or something ridiculous, but those ain't Wolfson low power
 headphone codecs neither!


 A DAC can only go to 0dBFS by definition. If it appears to go beyond that
 then something is scaling the input to be less than full scale at full
 scale.
 For instance a 24-bit DAC could be sent 16 16-bit full-scale streams and
 not clip. Only if 16-bits is considered full scale does that make it
 +12dBFS.

 Martin



 ___
 Pd-list@iem.at mailing list
 UNSUBSCRIBE and account-management - http://lists.puredata.info/
 listinfo/pd-list

___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list


Re: [PD] headroom in Pd

2014-01-01 Thread IOhannes m zmölnig
On 2014-01-01 19:50, Chris Clepper wrote:
 Nope, the DAC can freely construct intersample peaks as it sees fit and
 those can easily exceed 0 dBFS.  It has been common practice in the
 industry for more than a decade to reconstruct clipped samples well above 0
 dBFS - partially to make up for shitty mixing and mastering prevalent in
 music, and also because it's the right way to do it.

+1


nevertheless you cannot send digital values to the DAC that exceed
0dBFS. the intersample peaks are *purely* analog.
FS stands for full scale and refers to the full range of the digianl
fix-point values. thus - by definition - 0dBFS only refers to digital
values, and can never be exceeded. however on the analog side, the
nominal 0dB can easily be exceeded in the reconstruction.

btw, zexy's [limiter~] tries to take intersample peaks into account by
upsampling the signal prior to limiting,...
so if you use it to limit between -1..+1, then the reconstructed analog
signal should not exceed the nominal analog output range.
(for practical reasons, upsampling is limited, so in some borderline
cases you could still construct a signal that exceeds the 0dB analog)

gfmadsr
IOhannes



signature.asc
Description: OpenPGP digital signature
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list


Re: [PD] headroom in Pd

2014-01-01 Thread Martin Peach
I can see how a filter circuit following a DAC can swing more than the 
DAC for example if two successive samples are full-scale, but there's no 
way a DAC can output beyond its own full scale except momentarily while 
it's settling to a value inside its range.

The scaling has to be done before the DAC.

You just can't reconstruct a clipped signal unless the clipping is very 
mild or the signal is very simple, like a sine wave. What if the signal 
is +12dBFS white noise?


I meant that if you take 16 bits to be full-scale but you have a 24-bit 
DAC you _could_ use the 16 LSBs of the DAC as full scale, then you have 
a lot of headroom but your signal to noise ratio is not as good, and 
maybe something like this is happening in the default MacOS headphone 
driver.


Martin


On 2014-01-01 13:50, Chris Clepper wrote:

Nope, the DAC can freely construct intersample peaks as it sees fit and
those can easily exceed 0 dBFS.  It has been common practice in the
industry for more than a decade to reconstruct clipped samples well
above 0 dBFS - partially to make up for shitty mixing and mastering
prevalent in music, and also because it's the right way to do it.

16 bits full scale and 24 bits full scale are the same 0dBFS signal.
  The bits are added at the bottom not the top.



On Wed, Jan 1, 2014 at 1:34 PM, Martin Peach martin.pe...@sympatico.ca
mailto:martin.pe...@sympatico.ca wrote:

On 2013-12-31 19:32, Chris Clepper wrote:

It's very, very easy to avoid any sort of clipping processing by
using
hardware with drivers that don't have any!  Avid, Apogee, MOTU,
RME, and
many others have bit transparent OSX CoreAudio drivers.

Also, any DAC worth it's using can reconstruct far beyond 0dBFS
without
distortion, so hearing volume increase past -1..1 in software is not
surprising.  I recall the ADI 1955 and equivalent TI part
putting out
+12dBFS or something ridiculous, but those ain't Wolfson low power
headphone codecs neither!


A DAC can only go to 0dBFS by definition. If it appears to go beyond
that then something is scaling the input to be less than full scale
at full scale.
For instance a 24-bit DAC could be sent 16 16-bit full-scale streams
and not clip. Only if 16-bits is considered full scale does that
make it +12dBFS.

Martin



_
Pd-list@iem.at mailto:Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -
http://lists.puredata.info/__listinfo/pd-list
http://lists.puredata.info/listinfo/pd-list




___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list




___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list


Re: [PD] headroom in Pd

2014-01-01 Thread Chris Clepper
Yes, of course the signal out of the DAC is purely analog.  The signal is
referenced to 0dBFS on the digital side and also something like dBu or dBv
on the analog side (although it varies from part to part).  I should have
been clearer in stating this.  :)

But the main point is that there are signals beyond all 1s in the data sent
to the DAC if clipping exists.  This is confusing to many because the
digital math as commonly taught typically only refers to 'inside the box'.
 I leave this exception out of any workshop or uni course because of the
confusion, but it should be known more widely.

Sounds like the zexy [limiter~] is better than many commercial plugins that
don't upsample!  As we know, the hard clip can create some very nasty
aliasing artifacts and when done in the box there is no way to undo that
damage.

Best practice is still to keep the peaks away from full scale even if using
a very good DAC that can del with clipping well.

On Wed, Jan 1, 2014 at 2:03 PM, IOhannes m zmölnig zmoel...@iem.at wrote:

 On 2014-01-01 19:50, Chris Clepper wrote:
  Nope, the DAC can freely construct intersample peaks as it sees fit and
  those can easily exceed 0 dBFS.  It has been common practice in the
  industry for more than a decade to reconstruct clipped samples well
 above 0
  dBFS - partially to make up for shitty mixing and mastering prevalent in
  music, and also because it's the right way to do it.

 +1


 nevertheless you cannot send digital values to the DAC that exceed
 0dBFS. the intersample peaks are *purely* analog.
 FS stands for full scale and refers to the full range of the digianl
 fix-point values. thus - by definition - 0dBFS only refers to digital
 values, and can never be exceeded. however on the analog side, the
 nominal 0dB can easily be exceeded in the reconstruction.

 btw, zexy's [limiter~] tries to take intersample peaks into account by
 upsampling the signal prior to limiting,...
 so if you use it to limit between -1..+1, then the reconstructed analog
 signal should not exceed the nominal analog output range.
 (for practical reasons, upsampling is limited, so in some borderline
 cases you could still construct a signal that exceeds the 0dB analog)

 gfmadsr
 IOhannes


 ___
 Pd-list@iem.at mailing list
 UNSUBSCRIBE and account-management -
 http://lists.puredata.info/listinfo/pd-list


___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list


Re: [PD] headroom in Pd

2014-01-01 Thread Chris Clepper
On Wed, Jan 1, 2014 at 2:03 PM, Martin Peach martin.pe...@sympatico.cawrote:

 I can see how a filter circuit following a DAC can swing more than the DAC
 for example if two successive samples are full-scale, but there's no way a
 DAC can output beyond its own full scale except momentarily while it's
 settling to a value inside its range.
 The scaling has to be done before the DAC.

 You just can't reconstruct a clipped signal unless the clipping is very
 mild or the signal is very simple, like a sine wave. What if the signal is
 +12dBFS white noise?


The DAC can't really discriminate based on the aural complexity of a
signal.  A peak with N successive clipped samples has a reconstructed value
above full scale and the DAC will attempt to produce that signal.  Since
all of the info above full scale is lost, the reconstruction is just a
guess whether the input is a sine or kick drum or random noise.  The sine
wave has a pretty clearly correct reconstruction while a percussive sound
might not.  A common side effect of doing extreme declipping using
something like iZotope in the box is a softening of transients.  Not
surprising.

I haven't looked too deeply into how various DACs go about their process,
but some of the higher end parts have pretty decent DSP on board or even
allow external SHARC chips to do the work. I do know people that make high
end mastering converters who know quite a lot about this.

There are limits - The Stooges 'Raw Power' CD is so clipped that even high
end DACs with lots of DSP have no hope there!



 I meant that if you take 16 bits to be full-scale but you have a 24-bit
 DAC you _could_ use the 16 LSBs of the DAC as full scale, then you have a
 lot of headroom but your signal to noise ratio is not as good, and maybe
 something like this is happening in the default MacOS headphone driver.


It's not clear what is happening in the Apple codec driver, but the Core
Audio doc linked earlier gives a pretty good idea that they are doing a
'soft clipping' algorithm perhaps much like zexy's [limiter~].  I have seen
some Wolfson codec datasheets that mention doing the soft clip in the
hardware and those parts were aimed at mobile phones and the like.  The
intent is to prevent hard clipping from reaching the puny internal speakers
in such devices and not an aesthetic choice.



 Martin



 On 2014-01-01 13:50, Chris Clepper wrote:

 Nope, the DAC can freely construct intersample peaks as it sees fit and
 those can easily exceed 0 dBFS.  It has been common practice in the
 industry for more than a decade to reconstruct clipped samples well
 above 0 dBFS - partially to make up for shitty mixing and mastering
 prevalent in music, and also because it's the right way to do it.

 16 bits full scale and 24 bits full scale are the same 0dBFS signal.
   The bits are added at the bottom not the top.



 On Wed, Jan 1, 2014 at 1:34 PM, Martin Peach martin.pe...@sympatico.ca
 mailto:martin.pe...@sympatico.ca wrote:

 On 2013-12-31 19:32, Chris Clepper wrote:

 It's very, very easy to avoid any sort of clipping processing by
 using
 hardware with drivers that don't have any!  Avid, Apogee, MOTU,
 RME, and
 many others have bit transparent OSX CoreAudio drivers.

 Also, any DAC worth it's using can reconstruct far beyond 0dBFS
 without
 distortion, so hearing volume increase past -1..1 in software is
 not
 surprising.  I recall the ADI 1955 and equivalent TI part
 putting out
 +12dBFS or something ridiculous, but those ain't Wolfson low power
 headphone codecs neither!


 A DAC can only go to 0dBFS by definition. If it appears to go beyond
 that then something is scaling the input to be less than full scale
 at full scale.
 For instance a 24-bit DAC could be sent 16 16-bit full-scale streams
 and not clip. Only if 16-bits is considered full scale does that
 make it +12dBFS.

 Martin



 _
 Pd-list@iem.at mailto:Pd-list@iem.at mailing list
 UNSUBSCRIBE and account-management -
 http://lists.puredata.info/__listinfo/pd-list
 http://lists.puredata.info/listinfo/pd-list





 ___
 Pd-list@iem.at mailing list
 UNSUBSCRIBE and account-management - http://lists.puredata.info/
 listinfo/pd-list



___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list


Re: [PD] headroom in Pd

2013-12-31 Thread Simon Wise

On 31/12/13 08:30, Dan Wilcox wrote:

Ouch. I guess alot of us don't have serious projects :D (Out of curiosity, does 
Max do soft clipping also?)


the point was that OSX was messing with the sound between the software, 
presumably any software, and the audio output ... which may perhaps be called a 
feature while listening to songs in iTunes but is a big worry if you are trying 
to use the system seriously as a musician. It is a problem that comes up on this 
list from time to time, I don't recall any reply saying it could be bypassed or 
turned off.



Simon

___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list


Re: [PD] headroom in Pd

2013-12-31 Thread Chris Clepper
It's very, very easy to avoid any sort of clipping processing by using
hardware with drivers that don't have any!  Avid, Apogee, MOTU, RME, and
many others have bit transparent OSX CoreAudio drivers.

Also, any DAC worth it's using can reconstruct far beyond 0dBFS without
distortion, so hearing volume increase past -1..1 in software is not
surprising.  I recall the ADI 1955 and equivalent TI part putting out
+12dBFS or something ridiculous, but those ain't Wolfson low power
headphone codecs neither!



On Tue, Dec 31, 2013 at 6:50 PM, Simon Wise simonzw...@gmail.com wrote:

 On 31/12/13 08:30, Dan Wilcox wrote:

 Ouch. I guess alot of us don't have serious projects :D (Out of
 curiosity, does Max do soft clipping also?)


 the point was that OSX was messing with the sound between the software,
 presumably any software, and the audio output ... which may perhaps be
 called a feature while listening to songs in iTunes but is a big worry if
 you are trying to use the system seriously as a musician. It is a problem
 that comes up on this list from time to time, I don't recall any reply
 saying it could be bypassed or turned off.


 Simon


 ___
 Pd-list@iem.at mailing list
 UNSUBSCRIBE and account-management - http://lists.puredata.info/
 listinfo/pd-list

___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list


Re: [PD] headroom in Pd

2013-12-31 Thread Simon Wise

On 01/01/14 11:32, Chris Clepper wrote:

It's very, very easy to avoid any sort of clipping processing by using
hardware with drivers that don't have any!  Avid, Apogee, MOTU, RME, and
many others have bit transparent OSX CoreAudio drivers.

Also, any DAC worth it's using can reconstruct far beyond 0dBFS without
distortion, so hearing volume increase past -1..1 in software is not
surprising.  I recall the ADI 1955 and equivalent TI part putting out
+12dBFS or something ridiculous, but those ain't Wolfson low power
headphone codecs neither!



So it is the driver for the built-in audio output that is adding the 
feature/problem? I rarely use OSX these days, just an old setup with a G4 mac 
mini and a MOTU that hasn't been updated for years but still does its job nicely.



Simon

___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list


Re: [PD] headroom in Pd

2013-12-31 Thread Chris Clepper
It's not even clear if there is some sort of soft clipping at play in
Alexandre's case, but some of the Apple hardware has used such either in
the CoreAudio driver or in the hardware codec itself.  As I recall the main
reasoning was to prevent hard clipping from damaging the tiny laptop
speakers and some models it was bypassed when headphones are plugged in.

Personally, I test all mixes and masters in iTunes using the headphone out
of a Mac Mini.  If it sounds bad there I don't blame the driver though.


On Tue, Dec 31, 2013 at 8:00 PM, Simon Wise simonzw...@gmail.com wrote:

 On 01/01/14 11:32, Chris Clepper wrote:

 It's very, very easy to avoid any sort of clipping processing by using
 hardware with drivers that don't have any!  Avid, Apogee, MOTU, RME, and
 many others have bit transparent OSX CoreAudio drivers.

 Also, any DAC worth it's using can reconstruct far beyond 0dBFS without
 distortion, so hearing volume increase past -1..1 in software is not
 surprising.  I recall the ADI 1955 and equivalent TI part putting out
 +12dBFS or something ridiculous, but those ain't Wolfson low power
 headphone codecs neither!



 So it is the driver for the built-in audio output that is adding the
 feature/problem? I rarely use OSX these days, just an old setup with a G4
 mac mini and a MOTU that hasn't been updated for years but still does its
 job nicely.


 Simon

___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list


Re: [PD] headroom in Pd

2013-12-31 Thread Alexandre Torres Porres
I have rem's multiface ii by the way, it says it handles a headrom of 13 db
or something, don't really know what it means. It'llbe a while 'til I check
anyway, I'm at a very nice beach in Brasil andI just dipped myself into the
atlantic ocean

LoveTo You All!!!


2013/12/31 Chris Clepper cgclep...@gmail.com

 It's very, very easy to avoid any sort of clipping processing by using
 hardware with drivers that don't have any!  Avid, Apogee, MOTU, RME, and
 many others have bit transparent OSX CoreAudio drivers.

 Also, any DAC worth it's using can reconstruct far beyond 0dBFS without
 distortion, so hearing volume increase past -1..1 in software is not
 surprising.  I recall the ADI 1955 and equivalent TI part putting out
 +12dBFS or something ridiculous, but those ain't Wolfson low power
 headphone codecs neither!



 On Tue, Dec 31, 2013 at 6:50 PM, Simon Wise simonzw...@gmail.com wrote:

 On 31/12/13 08:30, Dan Wilcox wrote:

 Ouch. I guess alot of us don't have serious projects :D (Out of
 curiosity, does Max do soft clipping also?)


 the point was that OSX was messing with the sound between the software,
 presumably any software, and the audio output ... which may perhaps be
 called a feature while listening to songs in iTunes but is a big worry if
 you are trying to use the system seriously as a musician. It is a problem
 that comes up on this list from time to time, I don't recall any reply
 saying it could be bypassed or turned off.


 Simon


 ___
 Pd-list@iem.at mailing list
 UNSUBSCRIBE and account-management - http://lists.puredata.info/
 listinfo/pd-list



 ___
 Pd-list@iem.at mailing list
 UNSUBSCRIBE and account-management -
 http://lists.puredata.info/listinfo/pd-list


___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list


Re: [PD] headroom in Pd

2013-12-30 Thread Dan Wilcox
Ouch. I guess alot of us don't have serious projects :D (Out of curiosity, does 
Max do soft clipping also?)

On Dec 29, 2013, at 10:20 PM, pd-list-requ...@iem.at wrote:

 From: Miller Puckette m...@ucsd.edu
 Subject: Re: [PD] headroom in Pd
 Date: December 29, 2013 at 6:42:00 PM GMT+1
 To: Martin Peach martin.pe...@sympatico.ca
 Cc: IOhannes m zmölnig zmoel...@iem.at, pd-list@iem.at
 
 
 This is frightening - if I were a musician reading this I'd be frightened
 to ever use Appe software in a serious project.


Dan Wilcox
@danomatika
danomatika.com
robotcowboy.com





___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list


Re: [PD] headroom in Pd

2013-12-29 Thread Alexandre Torres Porres
here's the deal, if I have a square wave in Pd running at 1 -1 peak to
peak, then you say that should be my maximum output, right?

Thing is that if I give it an extra boost (say, multiply it by 2) I
can clearly listen an increase in loudness. Hence, something in my
system is allowing some headroom to be output.

I got a macbook air from 2010 running 10.7.5... if Pd is not
responsible for this, maybe my hardware + Mac OS is?

here's the patch, try yourselves and tell me what you get please.

Cheers


#N canvas 653 26 257 182 10;
#X obj 79 97 dac~;
#X obj 85 41 square~ 440;
#X floatatom 125 72 5 0 0 0 - - -;
#X obj 85 70 *~;
#X connect 1 0 3 0;
#X connect 2 0 3 1;
#X connect 3 0 0 0;
#X connect 3 0 0 1;

2013/12/21, IOhannes m zmölnig zmoel...@iem.at:
 On 2013-12-21 14:58, peiman khosravi wrote:
 However, it's probably wise to clip the signal before sending it to dac~.
 Entirely for health and safety reasons!

 this really depends...a clipping sine will have loads of high
 frequencies that might be equally damaging to your audience.

 if you want to be safe, use math to make sure that your signal won't
 exceed -1..+1 before sending to the [dac~].

 or use a limiter (zexy has a handy one).

 fgmrdsa
 IOhannes



___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list


Re: [PD] headroom in Pd

2013-12-29 Thread Martin Peach


On 2013-12-29 10:08, Alexandre Torres Porres wrote:

here's the deal, if I have a square wave in Pd running at 1 -1 peak to
peak, then you say that should be my maximum output, right?

Thing is that if I give it an extra boost (say, multiply it by 2) I
can clearly listen an increase in loudness. Hence, something in my
system is allowing some headroom to be output.

I got a macbook air from 2010 running 10.7.5... if Pd is not
responsible for this, maybe my hardware + Mac OS is?



Yes it's a Mac-specific issue. On Win7 I get no difference above 1.0.
The Apple audio driver is responsible for clipping values outside of 
[-1.0..1.0] as they arrive from possibly multiple applications. The docs 
state that clipping can be done in a soft way, so I suspect that the 
default driver (for the headphone output) is doing some sort of 
compression. Possibly if you use an external interface this won't happen 
(?).


(see for example 
https://developer.apple.com/library/mac/documentation/DeviceDrivers/Conceptual/WritingAudioDrivers/ImplementDriver/ImplementDriver.html#//apple_ref/doc/uid/TP3732-BAJCBIAF

)
Martin



here's the patch, try yourselves and tell me what you get please.

Cheers


#N canvas 653 26 257 182 10;
#X obj 79 97 dac~;
#X obj 85 41 square~ 440;
#X floatatom 125 72 5 0 0 0 - - -;
#X obj 85 70 *~;
#X connect 1 0 3 0;
#X connect 2 0 3 1;
#X connect 3 0 0 0;
#X connect 3 0 0 1;

2013/12/21, IOhannes m zmölnig zmoel...@iem.at:

On 2013-12-21 14:58, peiman khosravi wrote:

However, it's probably wise to clip the signal before sending it to dac~.
Entirely for health and safety reasons!


this really depends...a clipping sine will have loads of high
frequencies that might be equally damaging to your audience.

if you want to be safe, use math to make sure that your signal won't
exceed -1..+1 before sending to the [dac~].

or use a limiter (zexy has a handy one).

fgmrdsa
IOhannes




___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list





___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list


Re: [PD] headroom in Pd

2013-12-29 Thread Miller Puckette
This is frightening - if I were a musician reading this I'd be frightened
to ever use Appe software in a serious project.

(Of course, we do't know what happens in Windows under the hood either.  The
only way you can truly know what you're getting is to use an open-source
OS.

cheers
Miller

On Sun, Dec 29, 2013 at 12:12:04PM -0500, Martin Peach wrote:
 
 On 2013-12-29 10:08, Alexandre Torres Porres wrote:
 here's the deal, if I have a square wave in Pd running at 1 -1 peak to
 peak, then you say that should be my maximum output, right?
 
 Thing is that if I give it an extra boost (say, multiply it by 2) I
 can clearly listen an increase in loudness. Hence, something in my
 system is allowing some headroom to be output.
 
 I got a macbook air from 2010 running 10.7.5... if Pd is not
 responsible for this, maybe my hardware + Mac OS is?
 
 
 Yes it's a Mac-specific issue. On Win7 I get no difference above 1.0.
 The Apple audio driver is responsible for clipping values outside
 of [-1.0..1.0] as they arrive from possibly multiple applications.
 The docs state that clipping can be done in a soft way, so I
 suspect that the default driver (for the headphone output) is doing
 some sort of compression. Possibly if you use an external interface
 this won't happen (?).
 
 (see for example 
 https://developer.apple.com/library/mac/documentation/DeviceDrivers/Conceptual/WritingAudioDrivers/ImplementDriver/ImplementDriver.html#//apple_ref/doc/uid/TP3732-BAJCBIAF
 )
 Martin
 
 
 here's the patch, try yourselves and tell me what you get please.
 
 Cheers
 
 
 #N canvas 653 26 257 182 10;
 #X obj 79 97 dac~;
 #X obj 85 41 square~ 440;
 #X floatatom 125 72 5 0 0 0 - - -;
 #X obj 85 70 *~;
 #X connect 1 0 3 0;
 #X connect 2 0 3 1;
 #X connect 3 0 0 0;
 #X connect 3 0 0 1;
 
 2013/12/21, IOhannes m zmölnig zmoel...@iem.at:
 On 2013-12-21 14:58, peiman khosravi wrote:
 However, it's probably wise to clip the signal before sending it to dac~.
 Entirely for health and safety reasons!
 
 this really depends...a clipping sine will have loads of high
 frequencies that might be equally damaging to your audience.
 
 if you want to be safe, use math to make sure that your signal won't
 exceed -1..+1 before sending to the [dac~].
 
 or use a limiter (zexy has a handy one).
 
 fgmrdsa
 IOhannes
 
 
 
 ___
 Pd-list@iem.at mailing list
 UNSUBSCRIBE and account-management - 
 http://lists.puredata.info/listinfo/pd-list
 
 
 
 
 ___
 Pd-list@iem.at mailing list
 UNSUBSCRIBE and account-management - 
 http://lists.puredata.info/listinfo/pd-list

___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list


Re: [PD] headroom in Pd

2013-12-21 Thread IOhannes m zmölnig
On 2013-12-20 23:34, Martin Peach wrote:
 On 2013-12-20 16:55, Alexandre Torres Porres wrote:
 Hi there, where can I find info about headroom and clipping on Pd. Or
 can anyone tell me quickly how it goes?

 Does it always really clip over a maximum of 1, or is there some
 headroom? Does it depend on the audiocard or something?
 
 The soundcard will always clip above +1 and below -1, and sometimes even

yes, but the output of Pd (what you send to [dac~]) is not necessarily
sent directly to the soundcard: e.g when using jack, the samples will be
passed as floating point values to the next client: so samples exceeding
-1..+1 need not clip at all.
you can confirm this by connecting the output of Pd to the input of Pd
via jack, and send a [osc~ 440]*10 ...

but when you connect this output to the system output, you will get
clipping.

afaik, you get something similar on OSX, where the (portaudio) API will
take floating point samples, and the signal gets sent through a limiter
to prevent obvious clipping.

so the bottom line is: hardware always has a physical range limit (that
is mapped to -1..+1).
but Pd is software and some audio APIs can handle sample values in
floating point format just fine. with these, you most likely don't get
any *immediate* problems if the range exceeds -1..+1.
however, how excessive samples are handled is highly depending on the
audio API and eventually other components in the signal chain.
so if you do want to output signals that are outside -1..+1, you are on
your own (from Pd's perspective).


 within those limits (if the interpolated waveform between samples goes
 over the limit).

well, the reconstruction filters in the DAC won't necessarily clip in
this case.


gfamdsr
IOhannes



signature.asc
Description: OpenPGP digital signature
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list


Re: [PD] headroom in Pd

2013-12-21 Thread peiman khosravi
However, it's probably wise to clip the signal before sending it to dac~.
Entirely for health and safety reasons!




*www.peimankhosravi.co.uk http://www.peimankhosravi.co.uk || RSS Feed
http://peimankhosravi.co.uk/miscposts.rss || Concert News
http://spectralkimia.wordpress.com/*


On 21 December 2013 13:48, IOhannes m zmölnig zmoel...@iem.at wrote:

 On 2013-12-20 23:34, Martin Peach wrote:
  On 2013-12-20 16:55, Alexandre Torres Porres wrote:
  Hi there, where can I find info about headroom and clipping on Pd. Or
  can anyone tell me quickly how it goes?
 
  Does it always really clip over a maximum of 1, or is there some
  headroom? Does it depend on the audiocard or something?
 
  The soundcard will always clip above +1 and below -1, and sometimes even

 yes, but the output of Pd (what you send to [dac~]) is not necessarily
 sent directly to the soundcard: e.g when using jack, the samples will be
 passed as floating point values to the next client: so samples exceeding
 -1..+1 need not clip at all.
 you can confirm this by connecting the output of Pd to the input of Pd
 via jack, and send a [osc~ 440]*10 ...

 but when you connect this output to the system output, you will get
 clipping.

 afaik, you get something similar on OSX, where the (portaudio) API will
 take floating point samples, and the signal gets sent through a limiter
 to prevent obvious clipping.

 so the bottom line is: hardware always has a physical range limit (that
 is mapped to -1..+1).
 but Pd is software and some audio APIs can handle sample values in
 floating point format just fine. with these, you most likely don't get
 any *immediate* problems if the range exceeds -1..+1.
 however, how excessive samples are handled is highly depending on the
 audio API and eventually other components in the signal chain.
 so if you do want to output signals that are outside -1..+1, you are on
 your own (from Pd's perspective).


  within those limits (if the interpolated waveform between samples goes
  over the limit).

 well, the reconstruction filters in the DAC won't necessarily clip in
 this case.


 gfamdsr
 IOhannes


 ___
 Pd-list@iem.at mailing list
 UNSUBSCRIBE and account-management -
 http://lists.puredata.info/listinfo/pd-list


___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list


Re: [PD] headroom in Pd

2013-12-21 Thread IOhannes m zmölnig
On 2013-12-21 14:58, peiman khosravi wrote:
 However, it's probably wise to clip the signal before sending it to dac~.
 Entirely for health and safety reasons!

this really depends...a clipping sine will have loads of high
frequencies that might be equally damaging to your audience.

if you want to be safe, use math to make sure that your signal won't
exceed -1..+1 before sending to the [dac~].

or use a limiter (zexy has a handy one).

fgmrdsa
IOhannes



signature.asc
Description: OpenPGP digital signature
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list


[PD] headroom in Pd

2013-12-20 Thread Alexandre Torres Porres
Hi there, where can I find info about headroom and clipping on Pd. Or can
anyone tell me quickly how it goes?

Does it always really clip over a maximum of 1, or is there some headroom?
Does it depend on the audiocard or something?

thanks
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list


Re: [PD] headroom in Pd

2013-12-20 Thread Martin Peach

On 2013-12-20 16:55, Alexandre Torres Porres wrote:

Hi there, where can I find info about headroom and clipping on Pd. Or
can anyone tell me quickly how it goes?

Does it always really clip over a maximum of 1, or is there some
headroom? Does it depend on the audiocard or something?


The soundcard will always clip above +1 and below -1, and sometimes even 
within those limits (if the interpolated waveform between samples goes 
over the limit).
Pd will not clip internally, so you can calculate with larger numbers as 
long as you scale them back down before listening to them.


Martin


___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list