New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Speaker output DC blocking #275

Closed
wants to merge 5 commits into
base: master
from

Conversation

Projects
None yet
3 participants
@rmacri
Contributor

rmacri commented Apr 12, 2015

The Apple speaker code correctly drives the soundcard at +32767/-32768 for its two states, leaving the sound card with a large DC offset. I've noticed this cause loud clicks when my system is busy and AppleWin underruns its audio, as well as clicks when I change volume on the soundcard, both due to the DC offset. I guess my card is DC coupled. Recently I also noticed my connected Yamaha amp does not like the DC offset (eg: affects sound playing in Winamp).
So I've implemented a simple DC blocking integrator/capacitor. This has no affect on regular Apple audio as it adjustments are small and operate over the order of a second. Comments have detailed explanation.

rmacri added some commits Apr 9, 2015

Merge pull request #1 from AppleWin/master
merging from applewin/master
Added DC blocking for speaker which greatly reduces loud buffer under…
…run clicks and avoids upsetting amplifiers when the PC sound card is DC coupled
@rmacri

This comment has been minimized.

Show comment
Hide comment
@rmacri

rmacri Apr 19, 2015

Contributor

Addendum - I have found this change creates clicks with floppy drive access - will have to check I've properly filtered all access to the sound buffer, seems I've missed a case..

Contributor

rmacri commented Apr 19, 2015

Addendum - I have found this change creates clicks with floppy drive access - will have to check I've properly filtered all access to the sound buffer, seems I've missed a case..

@rmacri

This comment has been minimized.

Show comment
Hide comment
@rmacri

rmacri Apr 19, 2015

Contributor

clicks fixed - as suspected, the sound buffer padding code was directly copying the speaker state to the sound buffer instead of via DCFilter().

Contributor

rmacri commented Apr 19, 2015

clicks fixed - as suspected, the sound buffer padding code was directly copying the speaker state to the sound buffer instead of via DCFilter().

@tomcw

This comment has been minimized.

Show comment
Hide comment
@tomcw

tomcw May 18, 2015

Contributor

Hi Riccardo,

This has insignificant impact for the usual Apple buzzes, bleeps and PWM as 'sample_in' is swinging +/- so fast that the 's_dcfilterstate' has little time to accumulate significantly in either direction.

How about for sampled sounds?

There is a remainder buffer which is used to store the remaining (up to) 23 samples at 1MHz which contribute to the next 44.1kHz sample. (NB. 23.191 x 44.1kHz = 1.023MHz.) When there's a speaker toggle, then this is likely to occur somewhere in this remainder buffer, and the next 44.1kHz sample will be the average of these 23 values.

Some question relating to this remainder buffer:

  1. The functions that fill this buffer (ReinitRemainderBuffer() and UpdateRemainderBuffer()) are just filling with the current g_nSpeakerData value, not the value from DCFilter(g_nSpeakerData). Is this right?
    • This looks fine for the non-toggle case, since all values will be the same (so the average is just this value), then DCFilter(value) attenuates this value.
    • For the toggle-case then...
  2. Is the s_dcfilterstate accounted for when calculating this average?
    • What happens when this buffer contains a speaker toggle?
    • In this case, the buffer's average value may remain (eg) positive even after the toggle, eg. 22x 0x7FFF and 1x 0x8000. Average = 0x74DD.
      • With a low s_dcfilterstate then the output of DCFilter(0x74DD) is a slightly lower positive value, then the next 44.1kHz sample will be negative. (This seems OK.)
      • With a high s_dcfilterstate (eg. 0x7FFF) then the output of DCFilter(0x74DD) is a small negative value (eg. 0xF4DE).
    • This negative value generates a click, whereas in the original case there would be no click (until the next 44.1kHz sample).
    • NB. In the case for s_dcfilterstate = 0x7FFF, without a toggle, then it will have taken 32767 / 44.1 / 1000 = 0.743 secs (or 743 calls to UpdateSpkr() from the main loop) to accumulate to 0x7FFF.

Anyway, given all the above, I think this patch is fine.

Contributor

tomcw commented May 18, 2015

Hi Riccardo,

This has insignificant impact for the usual Apple buzzes, bleeps and PWM as 'sample_in' is swinging +/- so fast that the 's_dcfilterstate' has little time to accumulate significantly in either direction.

How about for sampled sounds?

There is a remainder buffer which is used to store the remaining (up to) 23 samples at 1MHz which contribute to the next 44.1kHz sample. (NB. 23.191 x 44.1kHz = 1.023MHz.) When there's a speaker toggle, then this is likely to occur somewhere in this remainder buffer, and the next 44.1kHz sample will be the average of these 23 values.

Some question relating to this remainder buffer:

  1. The functions that fill this buffer (ReinitRemainderBuffer() and UpdateRemainderBuffer()) are just filling with the current g_nSpeakerData value, not the value from DCFilter(g_nSpeakerData). Is this right?
    • This looks fine for the non-toggle case, since all values will be the same (so the average is just this value), then DCFilter(value) attenuates this value.
    • For the toggle-case then...
  2. Is the s_dcfilterstate accounted for when calculating this average?
    • What happens when this buffer contains a speaker toggle?
    • In this case, the buffer's average value may remain (eg) positive even after the toggle, eg. 22x 0x7FFF and 1x 0x8000. Average = 0x74DD.
      • With a low s_dcfilterstate then the output of DCFilter(0x74DD) is a slightly lower positive value, then the next 44.1kHz sample will be negative. (This seems OK.)
      • With a high s_dcfilterstate (eg. 0x7FFF) then the output of DCFilter(0x74DD) is a small negative value (eg. 0xF4DE).
    • This negative value generates a click, whereas in the original case there would be no click (until the next 44.1kHz sample).
    • NB. In the case for s_dcfilterstate = 0x7FFF, without a toggle, then it will have taken 32767 / 44.1 / 1000 = 0.743 secs (or 743 calls to UpdateSpkr() from the main loop) to accumulate to 0x7FFF.

Anyway, given all the above, I think this patch is fine.

@rmacri

This comment has been minimized.

Show comment
Hide comment
@rmacri

rmacri May 19, 2015

Contributor

Hi Tom, thanks for the detailed analysis. Right after the initial pull
request I found clicks during floppy access and found I'd missed a case.
I hope I updated it properly. I've got the filter inserted in 4 places:

Line 468 - filling sound buffer from the sample mean
Line 483 - UpdateSpkr
Line 857 - Spkr_SubmitWaveBuffer (padding)
Line 865 - same, the second buffer, if it needs it

My idea was to let the speaker state go into the averaging in their raw
form, with the DC offset being applied on the way into the Windows sound
buffer. This models a kind of reality where whilst the little speaker
might get fed with DC, the cone+air itself acts as a high pass filter.

The filter does include a clamp ie:

if (s_output > 32767)
{
// offset so next sample will start decaying to 0
:
to prevent a long delay in it switching "state". Kind of like a clamp
diode I guess.

Your analysis seems right, and there could be a click/transient when PWM
begins (suddenly the average is 0 but there's this DC offset still).
This could probably happen in reality if the Apple was hooked up to an amp.

I'll do some A-B testing with the likes of Music Construction Set and
record the soundcard mix output, in a few days. Will let you see the
results.

Regards, Riccardo

On 19/05/2015 7:13 AM, TomCh wrote:

Hi Riccardo,

This has insignificant impact for the usual Apple buzzes, bleeps and
PWM as 'sample_in' is swinging +/- so fast that the
's_dcfilterstate' has little time to accumulate significantly in
either direction.

How about for sampled sounds?

There is a remainder buffer which is used to store the remaining (up to)
23 samples at 1MHz which contribute to the next 44.1kHz sample. (NB.
23.191 x 44.1kHz = 1.023MHz.) When there's a speaker toggle, then this
is likely to occur somewhere in this remainder buffer, and the next
44.1kHz sample will be the average of these 23 values.

Some question relating to this remainder buffer:

  1. The functions that fill this buffer (|ReinitRemainderBuffer()| and
    |UpdateRemainderBuffer()|) are just filling with the current
    |g_nSpeakerData| value, not the value from
    |DCFilter(g_nSpeakerData)|. Is this right?
    • This looks fine for the non-toggle case, since all values will
      be the same (so the average is just this value), then
      |DCFilter(value)| attenuates this value.
    • For the toggle-case then...
  2. Is the |s_dcfilterstate| accounted for when calculating this average?
    • What happens when this buffer contains a speaker toggle?
    • In this case, the buffer's average value may remain (eg)
      positive even after the toggle, eg. 22x 0x7FFF and 1x 0x8000.
      Average = 0x74DD.
      o With a low |s_dcfilterstate| then the output of
      |DCFilter(0x74DD)| is a slightly lower positive value, then
      the next 44.1kHz sample will be negative. (This seems OK.)
      o With a high |s_dcfilterstate| (eg. 0x7FFF) then the output
      of |DCFilter(0x74DD)| is a small negative value (eg. 0xF4DE).
    • This negative value generates a click, whereas in the original
      case there would be no click (until the next 44.1kHz sample).
    • NB. In the case for |s_dcfilterstate = 0x7FFF|, without a
      toggle
      , then it will have taken 32767 / 44.1 / 1000 = 0.743
      secs (or 743 calls to |UpdateSpkr()| from the main loop) to
      accumulate to 0x7FFF.

Anyway, given all the above, I think this patch is fine.


Reply to this email directly or view it on GitHub
#275 (comment).

Contributor

rmacri commented May 19, 2015

Hi Tom, thanks for the detailed analysis. Right after the initial pull
request I found clicks during floppy access and found I'd missed a case.
I hope I updated it properly. I've got the filter inserted in 4 places:

Line 468 - filling sound buffer from the sample mean
Line 483 - UpdateSpkr
Line 857 - Spkr_SubmitWaveBuffer (padding)
Line 865 - same, the second buffer, if it needs it

My idea was to let the speaker state go into the averaging in their raw
form, with the DC offset being applied on the way into the Windows sound
buffer. This models a kind of reality where whilst the little speaker
might get fed with DC, the cone+air itself acts as a high pass filter.

The filter does include a clamp ie:

if (s_output > 32767)
{
// offset so next sample will start decaying to 0
:
to prevent a long delay in it switching "state". Kind of like a clamp
diode I guess.

Your analysis seems right, and there could be a click/transient when PWM
begins (suddenly the average is 0 but there's this DC offset still).
This could probably happen in reality if the Apple was hooked up to an amp.

I'll do some A-B testing with the likes of Music Construction Set and
record the soundcard mix output, in a few days. Will let you see the
results.

Regards, Riccardo

On 19/05/2015 7:13 AM, TomCh wrote:

Hi Riccardo,

This has insignificant impact for the usual Apple buzzes, bleeps and
PWM as 'sample_in' is swinging +/- so fast that the
's_dcfilterstate' has little time to accumulate significantly in
either direction.

How about for sampled sounds?

There is a remainder buffer which is used to store the remaining (up to)
23 samples at 1MHz which contribute to the next 44.1kHz sample. (NB.
23.191 x 44.1kHz = 1.023MHz.) When there's a speaker toggle, then this
is likely to occur somewhere in this remainder buffer, and the next
44.1kHz sample will be the average of these 23 values.

Some question relating to this remainder buffer:

  1. The functions that fill this buffer (|ReinitRemainderBuffer()| and
    |UpdateRemainderBuffer()|) are just filling with the current
    |g_nSpeakerData| value, not the value from
    |DCFilter(g_nSpeakerData)|. Is this right?
    • This looks fine for the non-toggle case, since all values will
      be the same (so the average is just this value), then
      |DCFilter(value)| attenuates this value.
    • For the toggle-case then...
  2. Is the |s_dcfilterstate| accounted for when calculating this average?
    • What happens when this buffer contains a speaker toggle?
    • In this case, the buffer's average value may remain (eg)
      positive even after the toggle, eg. 22x 0x7FFF and 1x 0x8000.
      Average = 0x74DD.
      o With a low |s_dcfilterstate| then the output of
      |DCFilter(0x74DD)| is a slightly lower positive value, then
      the next 44.1kHz sample will be negative. (This seems OK.)
      o With a high |s_dcfilterstate| (eg. 0x7FFF) then the output
      of |DCFilter(0x74DD)| is a small negative value (eg. 0xF4DE).
    • This negative value generates a click, whereas in the original
      case there would be no click (until the next 44.1kHz sample).
    • NB. In the case for |s_dcfilterstate = 0x7FFF|, without a
      toggle
      , then it will have taken 32767 / 44.1 / 1000 = 0.743
      secs (or 743 calls to |UpdateSpkr()| from the main loop) to
      accumulate to 0x7FFF.

Anyway, given all the above, I think this patch is fine.


Reply to this email directly or view it on GitHub
#275 (comment).

@tomcw

This comment has been minimized.

Show comment
Hide comment
@tomcw

tomcw May 19, 2015

Contributor

FYI, one positive difference with this patch vs the latest release of AppleWin 1.25.0.4, is that with the current release you get a click when stopping at a Visual Studio debugger breakpoint (and another click on a restart). But with the patch there's silence.

EG. Break to the AppleSoft prompt and wait 1 sec to let the filter accumulate to 0x7FFF (ie. so that the DirectSound ring-buffer is just outputting 0x0000's).

Contributor

tomcw commented May 19, 2015

FYI, one positive difference with this patch vs the latest release of AppleWin 1.25.0.4, is that with the current release you get a click when stopping at a Visual Studio debugger breakpoint (and another click on a restart). But with the patch there's silence.

EG. Break to the AppleSoft prompt and wait 1 sec to let the filter accumulate to 0x7FFF (ie. so that the DirectSound ring-buffer is just outputting 0x0000's).

@rmacri

This comment has been minimized.

Show comment
Hide comment
@rmacri

rmacri May 25, 2015

Contributor

Hi, I've made a recording of AppleWin 1.25.0.3 which I downloaded
December last year vs. my current patched version with the DC Filter.

The recording here has the older AppleWin version first followed by the
newer version. These were recorded via the "Mix Out" record capability
at 48kHz and the input of the sound card seems AC coupled.

https://dl.dropboxusercontent.com/u/58517106/MCS_TEST.wav

In my view the original version sounds less alias-y and when the first
bass note kicks in, the new version definitely has an issue with it.

There's a lot more DC offset in the waveform than I expected.

I'm guessing the DC filter is operating near the limit and the onset of
the bass note triggers the clamp.

I can think of two workarounds:

  1. re-do the DC filter so it only acts when the speaker is silent,
    gently ramping down the output to zero but letting it swing full scale
    as soon as the speaker is toggled again. Instead of an offset, use a
    multiply, eg sample = sample * attenuator instead of sample = sample +
    offset. SpkrToggle could reset the attenuator.

  2. make the DC filter an option.

I'm keen to give 1) a try, interested what you think of the samples.

Regards
Riccardo

On 20/05/2015 6:16 AM, TomCh wrote:

FYI, one positive difference with this patch vs the latest release of
AppleWin 1.25.0.4, is that with the current release you get a click when
stopping at a Visual Studio debugger breakpoint (and another click on a
restart). But with the patch there's silence.

EG. Break to the AppleSoft prompt and wait 1 sec to let the filter
accumulate to 0x7FFF (ie. so that the DirectSound ring-buffer is just
outputting 0x0000's).


Reply to this email directly or view it on GitHub
#275 (comment).

Contributor

rmacri commented May 25, 2015

Hi, I've made a recording of AppleWin 1.25.0.3 which I downloaded
December last year vs. my current patched version with the DC Filter.

The recording here has the older AppleWin version first followed by the
newer version. These were recorded via the "Mix Out" record capability
at 48kHz and the input of the sound card seems AC coupled.

https://dl.dropboxusercontent.com/u/58517106/MCS_TEST.wav

In my view the original version sounds less alias-y and when the first
bass note kicks in, the new version definitely has an issue with it.

There's a lot more DC offset in the waveform than I expected.

I'm guessing the DC filter is operating near the limit and the onset of
the bass note triggers the clamp.

I can think of two workarounds:

  1. re-do the DC filter so it only acts when the speaker is silent,
    gently ramping down the output to zero but letting it swing full scale
    as soon as the speaker is toggled again. Instead of an offset, use a
    multiply, eg sample = sample * attenuator instead of sample = sample +
    offset. SpkrToggle could reset the attenuator.

  2. make the DC filter an option.

I'm keen to give 1) a try, interested what you think of the samples.

Regards
Riccardo

On 20/05/2015 6:16 AM, TomCh wrote:

FYI, one positive difference with this patch vs the latest release of
AppleWin 1.25.0.4, is that with the current release you get a click when
stopping at a Visual Studio debugger breakpoint (and another click on a
restart). But with the patch there's silence.

EG. Break to the AppleSoft prompt and wait 1 sec to let the filter
accumulate to 0x7FFF (ie. so that the DirectSound ring-buffer is just
outputting 0x0000's).


Reply to this email directly or view it on GitHub
#275 (comment).

@rmacri

This comment has been minimized.

Show comment
Hide comment
@rmacri

rmacri May 25, 2015

Contributor

Just pushed a much better DC filter implementation using the attenuator
approach, much simpler and does not affect any playing audio. I dont
think I have to update the pull request do I?
Regards

On 20/05/2015 6:16 AM, TomCh wrote:

FYI, one positive difference with this patch vs the latest release of
AppleWin 1.25.0.4, is that with the current release you get a click when
stopping at a Visual Studio debugger breakpoint (and another click on a
restart). But with the patch there's silence.

EG. Break to the AppleSoft prompt and wait 1 sec to let the filter
accumulate to 0x7FFF (ie. so that the DirectSound ring-buffer is just
outputting 0x0000's).


Reply to this email directly or view it on GitHub
#275 (comment).

Contributor

rmacri commented May 25, 2015

Just pushed a much better DC filter implementation using the attenuator
approach, much simpler and does not affect any playing audio. I dont
think I have to update the pull request do I?
Regards

On 20/05/2015 6:16 AM, TomCh wrote:

FYI, one positive difference with this patch vs the latest release of
AppleWin 1.25.0.4, is that with the current release you get a click when
stopping at a Visual Studio debugger breakpoint (and another click on a
restart). But with the patch there's silence.

EG. Break to the AppleSoft prompt and wait 1 sec to let the filter
accumulate to 0x7FFF (ie. so that the DirectSound ring-buffer is just
outputting 0x0000's).


Reply to this email directly or view it on GitHub
#275 (comment).

@rmacri

This comment has been minimized.

Show comment
Hide comment
@rmacri

rmacri Jun 1, 2015

Contributor

Just a note that I removed the audio download as the new code obsoletes it.

Contributor

rmacri commented Jun 1, 2015

Just a note that I removed the audio download as the new code obsoletes it.

@tomcw

This comment has been minimized.

Show comment
Hide comment
@tomcw

tomcw Jun 2, 2015

Contributor

A delay before attenuation starts seems like a good idea. I hope to test & review this update soon. Thanks.

Contributor

tomcw commented Jun 2, 2015

A delay before attenuation starts seems like a good idea. I hope to test & review this update soon. Thanks.

@Michaelangel007 Michaelangel007 added this to the 1.27 milestone Sep 12, 2016

@Michaelangel007

This comment has been minimized.

Show comment
Hide comment
@Michaelangel007

Michaelangel007 Sep 12, 2016

Contributor

Reminder and Punting to 1.27.

Contributor

Michaelangel007 commented Sep 12, 2016

Reminder and Punting to 1.27.

@rmacri

This comment has been minimized.

Show comment
Hide comment
@rmacri

rmacri Sep 14, 2016

Contributor

Yep I'm still here for any questions on it.

As I last checked in, the most recent implementation where it "fades to
0" after some hundreds of milliseconds of non speaker use is a lot
simpler than the "blocking capacitor" approach and prevents any impact
on programs doing PWM type sounds whilst still protecting DC coupled
amps connected to the PC.

On 12/09/2016 12:49 PM, Michaelangel007 wrote:

Reminder and Punting to 1.27.


You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#275 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AK4DRrRhp2l0JMxHn5Yru6tOV-h0PrYRks5qpMu4gaJpZM4D-06V.

Contributor

rmacri commented Sep 14, 2016

Yep I'm still here for any questions on it.

As I last checked in, the most recent implementation where it "fades to
0" after some hundreds of milliseconds of non speaker use is a lot
simpler than the "blocking capacitor" approach and prevents any impact
on programs doing PWM type sounds whilst still protecting DC coupled
amps connected to the PC.

On 12/09/2016 12:49 PM, Michaelangel007 wrote:

Reminder and Punting to 1.27.


You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#275 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AK4DRrRhp2l0JMxHn5Yru6tOV-h0PrYRks5qpMu4gaJpZM4D-06V.

@tomcw

This comment has been minimized.

Show comment
Hide comment
@tomcw

tomcw Oct 22, 2016

Contributor

From this link: What is "DC-coupled"?...

In terms of analog circuitry, electronics that are DC–coupled have their components connected directly together without any coupling capacitors. As capacitors tend to remove certain frequencies, coupling the circuitry without capacitors in-line allows the full spectrum of sound frequencies to pass through unfettered. This can be advantageous as many capacitors severely limit the passage of low frequencies, resulting in poor low-frequency response. Manufacturers such as Solid State Logic often use DC-coupled circuitry for this reason. As capacitors wear out over time, many devices will experience a decline in performance. By building equipment without capacitors in the circuit, a manufacturer ensures that will have the same frequency response and essentially sound the same years after its initial purchase. To illustrate this point, we’ll use a SSL DC-coupled XL 9000 K console as an example. Since no capacitors that can fail are in the signal path, channel 1 will sound the same as channel 32 (or any other channel, for that matter) year in and year out. DC-coupled equipment maintains a linear-phase relationship across all channels, further illustrating the advantage of this method of creating circuits. DC-coupled circuitry also tends to be utilized in audiophile and high-end recording equipment, as it tends to provide the “purest” sound.

Capacitors, of course, still play a large role in the construction of electronic equipment. In applications where DC voltage may damage the circuit, capacitors are placed in the signal path as a means of protecting transistors from being burned up by the DC current. Capacitors essentially condition the incoming signal by rejecting unwanted DC voltage. DC voltage is also typically undesirable in audio signals as it can cause distortion later in the signal path.

Contributor

tomcw commented Oct 22, 2016

From this link: What is "DC-coupled"?...

In terms of analog circuitry, electronics that are DC–coupled have their components connected directly together without any coupling capacitors. As capacitors tend to remove certain frequencies, coupling the circuitry without capacitors in-line allows the full spectrum of sound frequencies to pass through unfettered. This can be advantageous as many capacitors severely limit the passage of low frequencies, resulting in poor low-frequency response. Manufacturers such as Solid State Logic often use DC-coupled circuitry for this reason. As capacitors wear out over time, many devices will experience a decline in performance. By building equipment without capacitors in the circuit, a manufacturer ensures that will have the same frequency response and essentially sound the same years after its initial purchase. To illustrate this point, we’ll use a SSL DC-coupled XL 9000 K console as an example. Since no capacitors that can fail are in the signal path, channel 1 will sound the same as channel 32 (or any other channel, for that matter) year in and year out. DC-coupled equipment maintains a linear-phase relationship across all channels, further illustrating the advantage of this method of creating circuits. DC-coupled circuitry also tends to be utilized in audiophile and high-end recording equipment, as it tends to provide the “purest” sound.

Capacitors, of course, still play a large role in the construction of electronic equipment. In applications where DC voltage may damage the circuit, capacitors are placed in the signal path as a means of protecting transistors from being burned up by the DC current. Capacitors essentially condition the incoming signal by rejecting unwanted DC voltage. DC voltage is also typically undesirable in audio signals as it can cause distortion later in the signal path.

@tomcw tomcw self-assigned this Oct 22, 2016

@rmacri

This comment has been minimized.

Show comment
Hide comment
@rmacri

rmacri Oct 28, 2016

Contributor

Back when I wrote this, I'm pretty sure I issued an updated pull. request

The initial version of my Applewin code DID use an accumulator to
simulate a capacitor. Tom correctly pointed out this could impact high
speed toggling as used in Music Construction Set and other PWM sound
effects.

My latest AppleWin commit has a much simpler approach - an attenuator.

When the Apple is silent for a period (second?), an attenuator applied
to the samples is slowly ramped up, effectively removing DC offset. The
moment the Apple toggles the speaker, the attenuator is reset, allowing
the full drive and the attenuator timer is reset. Note this is done to
the samples, not touching the sound hardware.

This means absolutely no impact on PWM.

Hope this version made it into the release, have not had time to check
but want to do so.

Riccardo

On 23/10/2016 4:21 AM, TomCh wrote:

From this link: What is "DC-coupled"?
http://www.sweetwater.com/insync/dc-coupled/...

In terms of analog circuitry, electronics that are DC–coupled have their
components connected directly together without any coupling capacitors.
As capacitors tend to remove certain frequencies, coupling the circuitry
without capacitors in-line allows the full spectrum of sound frequencies
to pass through unfettered. This can be advantageous as many capacitors
severely limit the passage of low frequencies, resulting in poor
low-frequency response. Manufacturers such as Solid State Logic often
use DC-coupled circuitry for this reason. As capacitors wear out over
time, many devices will experience a decline in performance. By building
equipment without capacitors in the circuit, a manufacturer ensures that
will have the same frequency response and essentially sound the same
years after its initial purchase. To illustrate this point, we’ll use a
SSL DC-coupled XL 9000 K console as an example. Since no capacitors that
can fail are in the signal path, channel 1 will sound the same as
channel 32 (or any other channel, for that matter) year in and year out.
DC-coupled equipment maintains a linear-phase relationship across all
channels, further illustrating the advantage of this method of creating
circuits. DC-coupled circuitry also tends to be utilized in audiophile
and high-end recording equipment, as it tends to provide the “purest”
sound.

Capacitors, of course, still play a large role in the construction of
electronic equipment. In applications where DC voltage may damage the
circuit, capacitors are placed in the signal path as a means of
protecting transistors from being burned up by the DC current.
Capacitors essentially condition the incoming signal by rejecting
unwanted DC voltage. DC voltage is also typically undesirable in audio
signals as it can cause distortion later in the signal path.


You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#275 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AK4DRgvl3kfkGQ3H4TtJbofoiJygt2Kqks5q2mIzgaJpZM4D-06V.

Contributor

rmacri commented Oct 28, 2016

Back when I wrote this, I'm pretty sure I issued an updated pull. request

The initial version of my Applewin code DID use an accumulator to
simulate a capacitor. Tom correctly pointed out this could impact high
speed toggling as used in Music Construction Set and other PWM sound
effects.

My latest AppleWin commit has a much simpler approach - an attenuator.

When the Apple is silent for a period (second?), an attenuator applied
to the samples is slowly ramped up, effectively removing DC offset. The
moment the Apple toggles the speaker, the attenuator is reset, allowing
the full drive and the attenuator timer is reset. Note this is done to
the samples, not touching the sound hardware.

This means absolutely no impact on PWM.

Hope this version made it into the release, have not had time to check
but want to do so.

Riccardo

On 23/10/2016 4:21 AM, TomCh wrote:

From this link: What is "DC-coupled"?
http://www.sweetwater.com/insync/dc-coupled/...

In terms of analog circuitry, electronics that are DC–coupled have their
components connected directly together without any coupling capacitors.
As capacitors tend to remove certain frequencies, coupling the circuitry
without capacitors in-line allows the full spectrum of sound frequencies
to pass through unfettered. This can be advantageous as many capacitors
severely limit the passage of low frequencies, resulting in poor
low-frequency response. Manufacturers such as Solid State Logic often
use DC-coupled circuitry for this reason. As capacitors wear out over
time, many devices will experience a decline in performance. By building
equipment without capacitors in the circuit, a manufacturer ensures that
will have the same frequency response and essentially sound the same
years after its initial purchase. To illustrate this point, we’ll use a
SSL DC-coupled XL 9000 K console as an example. Since no capacitors that
can fail are in the signal path, channel 1 will sound the same as
channel 32 (or any other channel, for that matter) year in and year out.
DC-coupled equipment maintains a linear-phase relationship across all
channels, further illustrating the advantage of this method of creating
circuits. DC-coupled circuitry also tends to be utilized in audiophile
and high-end recording equipment, as it tends to provide the “purest”
sound.

Capacitors, of course, still play a large role in the construction of
electronic equipment. In applications where DC voltage may damage the
circuit, capacitors are placed in the signal path as a means of
protecting transistors from being burned up by the DC current.
Capacitors essentially condition the incoming signal by rejecting
unwanted DC voltage. DC voltage is also typically undesirable in audio
signals as it can cause distortion later in the signal path.


You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#275 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AK4DRgvl3kfkGQ3H4TtJbofoiJygt2Kqks5q2mIzgaJpZM4D-06V.

@tomcw

This comment has been minimized.

Show comment
Hide comment
@tomcw

tomcw Oct 28, 2016

Contributor

Hi Riccardo,

Hope this version made it into the release,

It didn't unfortunately. But I'm prioritising processing all the outstanding pull-requests.

Anyway, thanks for checking back in about this, and helping me remember the current status.

Contributor

tomcw commented Oct 28, 2016

Hi Riccardo,

Hope this version made it into the release,

It didn't unfortunately. But I'm prioritising processing all the outstanding pull-requests.

Anyway, thanks for checking back in about this, and helping me remember the current status.

@rmacri

This comment has been minimized.

Show comment
Hide comment
@rmacri

rmacri Oct 28, 2016

Contributor

Thanks. I also appreciate the effort you put into AppleWin.
Let me know if anything comes up.

I don't wish to spam, but the 10 part video/blog series (so far) where
Ken Shirriff and co bring a 1970s Xerox Alto back to life is of great
interest to vintage computer fans. Very detailed and there's also a C#
Alto emulator which I must find time to try.

On 28/10/2016 8:05 PM, TomCh wrote:

Hi Riccardo,

Hope this version made it into the release,

It didn't unfortunately. But I'm prioritising processing all the
outstanding pull-requests.

Anyway, thanks for checking back in about this, and helping me remember
the current status.


You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#275 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AK4DRutigE4GEeII2LofgnYqNmVW5xXIks5q4dcKgaJpZM4D-06V.

Contributor

rmacri commented Oct 28, 2016

Thanks. I also appreciate the effort you put into AppleWin.
Let me know if anything comes up.

I don't wish to spam, but the 10 part video/blog series (so far) where
Ken Shirriff and co bring a 1970s Xerox Alto back to life is of great
interest to vintage computer fans. Very detailed and there's also a C#
Alto emulator which I must find time to try.

On 28/10/2016 8:05 PM, TomCh wrote:

Hi Riccardo,

Hope this version made it into the release,

It didn't unfortunately. But I'm prioritising processing all the
outstanding pull-requests.

Anyway, thanks for checking back in about this, and helping me remember
the current status.


You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#275 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AK4DRutigE4GEeII2LofgnYqNmVW5xXIks5q4dcKgaJpZM4D-06V.

tomcw added a commit that referenced this pull request Dec 20, 2017

@tomcw

This comment has been minimized.

Show comment
Hide comment
@tomcw

tomcw Dec 20, 2017

Contributor

Hi Riccardo,

I finally got round to merging and testing this PR!
Sorry it took so long.

New build 1.26.3.6 here.

Closing.

Contributor

tomcw commented Dec 20, 2017

Hi Riccardo,

I finally got round to merging and testing this PR!
Sorry it took so long.

New build 1.26.3.6 here.

Closing.

@tomcw tomcw closed this Dec 20, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment