Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.sys.apple2.programmer > #4383 > unrolled thread

WAV file playback

Back to article view | Back to comp.sys.apple2.programmer

Contents

  WAV file playback "Frank M." <frank_o_rama@hotmail.com> - 2018-03-19 12:15 -0700
    Re: WAV file playback Chris Vavruska <vavruska@gmail.com> - 2018-03-19 18:28 -0700
      Re: WAV file playback "Frank M." <frank_o_rama@hotmail.com> - 2018-03-19 19:43 -0700
        Re: WAV file playback Michael J. Mahon <mjmahon@aol.com> - 2018-03-20 01:55 -0500
          Re: WAV file playback "Frank M." <frank_o_rama@hotmail.com> - 2018-03-20 14:49 -0700
            Re: WAV file playback Michael J. Mahon <mjmahon@aol.com> - 2018-03-21 00:23 -0500
              Re: WAV file playback Tom Porter <laseractiveguy@gmail.com> - 2018-03-21 07:36 -0700
                Re: WAV file playback Michael J. Mahon <mjmahon@aol.com> - 2018-03-21 10:13 -0500
                  Re: WAV file playback "Frank M." <frank_o_rama@hotmail.com> - 2018-03-22 22:27 -0700
                    Re: WAV file playback James Davis <JPD.Enterprises@outlook.com> - 2018-03-24 12:35 -0700
                      Re: WAV file playback "Frank M." <frank_o_rama@hotmail.com> - 2018-03-24 19:44 -0700
                        Re: WAV file playback James Davis <JPD.Enterprises@outlook.com> - 2018-03-25 09:22 -0700
                          Re: WAV file playback "Frank M." <frank_o_rama@hotmail.com> - 2018-03-25 10:08 -0700
    Re: WAV file playback Tom Porter <laseractiveguy@gmail.com> - 2018-03-24 06:05 -0700
      Re: WAV file playback "Frank M." <frank_o_rama@hotmail.com> - 2018-03-24 11:50 -0700
        Re: WAV file playback Michael J. Mahon <mjmahon@aol.com> - 2018-03-24 20:18 -0500
          Re: WAV file playback "Frank M." <frank_o_rama@hotmail.com> - 2018-03-24 19:29 -0700
            Re: WAV file playback Michael J. Mahon <mjmahon@aol.com> - 2018-03-24 21:53 -0500
              Re: WAV file playback "Frank M." <frank_o_rama@hotmail.com> - 2018-03-24 21:49 -0700
                Re: WAV file playback "Frank M." <frank_o_rama@hotmail.com> - 2018-03-24 22:25 -0700
                  Re: WAV file playback Michael J. Mahon <mjmahon@aol.com> - 2018-03-25 09:44 -0500
            Re: WAV file playback Michael J. Mahon <mjmahon@aol.com> - 2018-03-24 22:43 -0500
              Re: WAV file playback "Frank M." <frank_o_rama@hotmail.com> - 2018-03-24 21:43 -0700
                Re: WAV file playback Michael J. Mahon <mjmahon@aol.com> - 2018-03-25 09:42 -0500
      Re: WAV file playback "Frank M." <frank_o_rama@hotmail.com> - 2018-03-24 11:56 -0700
    WAV file playback Michael Pohoreski <michael.pohoreski@gmail.com> - 2018-04-21 21:01 -0700
      Re: WAV file playback Michael J. Mahon <mjmahon@aol.com> - 2018-04-22 01:54 -0500
        Re: WAV file playback Michael Pohoreski <michael.pohoreski@gmail.com> - 2018-04-22 22:33 -0700
          Re: WAV file playback Michael J. Mahon <mjmahon@aol.com> - 2018-04-23 12:19 -0500
        Re: WAV file playback Michael Pohoreski <michael.pohoreski@gmail.com> - 2018-04-22 22:53 -0700
          Re: WAV file playback "Frank M." <frank_o_rama@hotmail.com> - 2018-04-23 08:42 -0700
          Re: WAV file playback Michael J. Mahon <mjmahon@aol.com> - 2018-04-23 12:19 -0500
            Re: WAV file playback Michael Pohoreski <michael.pohoreski@gmail.com> - 2018-04-23 22:38 -0700

Page 2 of 2 — ← Prev page 1 [2]

#4455

Frank M. <frank_o_rama@hotmail.com> wrote:
> 
> Got it running! Sounds almost exactly like the Audacity version with
> amplify converted to maximum. Runs at 6615 Hz sample rate with the WAIT
> delay set to 4. Did some cycle balancing between 0s and 1s, too.
> 
> Thanks for your help Michael!
> 
> Frank

You’re very welcome—have fun!
> 
>  ORG $300 ; CALL 768
>  LDX #$00
>  STX $FF ; Previous reading
>  STX GetByte+1 ; Start Address (Low Byte)
>  LDY #$08
>  STY GetByte+2 ; Start Address (High Byte) $0800
>  JMP GetByte ; Start reading bytes
> SamePage PHA
>  LDA #4 ; Playback Speed
>  JSR $FCA8 ; WAIT based on accumulator value
>  PLA
>  EOR $FF ; has reading zero-crossed since last sample?
>  BMI Changed ; Yes
>  BPL NoChange ; No
> Changed EOR $FF ; flip original bit back
>  STA $FF ; update previous reading variable to new reading
>  STA $C030 ; click the speaker
>  JMP GetByte
> NoChange CMP $44,X ; to even out 0/1 timing
>  CMP (00,X)
> GetByte LDA $D1D1,X ; Start Address **SELF-MODIFIED!
>  INX
>  BNE SamePage1 ; finish current page
>  INC GetByte+2 ; move on to next page
>  LDA GetByte+2
>  CMP #$96 ; Stop Address (high byte only) $9600
>  BNE SamePage ; not done, keep going
>  RTS ; We're done with all pages, exit
> SamePage1 CMP ($00,X) ; even out GetByte cycle count
>  NOP
>  JMP SamePage
> 
> 
> 
> 
> CALL-151
> 300:A2 00 86 FF 8E 2B 03 A0
> 308:08 8C 2C 03 4C 2A 03 48
> 310:A9 04 20 A8 FC 68 45 FF
> 318:30 02 10 0A 45 FF 85 FF
> 320:8D 30 C0 4C 2A 03 D5 44
> 328:C1 00 BD 00 96 E8 D0 0B
> 330:EE 2C 03 AD 2C 03 C9 96
> 338:D0 D5 60 C1 00 EA 4C 0F
> 340:03
> 
> 
> 



-- 
-michael - NadaNet 3.1 and AppleCrate II:  http://michaeljmahon.com

[toc] | [prev] | [next] | [standalone]

#4450

Frank M. <frank_o_rama@hotmail.com> wrote:
> 
> Hmmm... My experimentation with the cassette port output shows the
> opposite. If you hit 'pause' while feeding in audio, the bit can get
> stuck either high OR low, depending on if it crossed the high or low
> threshold before being stopped. (Sather - Understanding the IIe - pages
> 7-8 and 7-9 has more on this). If it was doing a traditional ADC sample
> it would just be zero.

Your experiment suggests that the op amp has som hysteresis, perhaps to
minimize output flipping by noise when no input is present. 

> Also, all of these playback engines I've seen use a STA instruction to
> toggle $C030. From what I understand STA actually accesses the location
> twice. Would an LDA be more appropriate? Or is the program author
> assuming the second access approximates the negative component of
> whatever audio wave they're trying to reconstruct? If the ear can't
> detect polarity than what is the difference between the speaker cone
> going +/- vs being togged + twice? Sort of reminds me of how a bridge
> rectifier works to create all positive voltage, but at twice the
> frequency. Is that a way to essentially bump the sample rate 2x?
> 
> F

A good reason to prefer STA to LDA is that it preserves the value of the
accumulator. 

The speaker takes substantial time to reach equilibrium after a toggle—so a
double access just a microsecond apart will be practically inaudible, since
the speaker cone will have almost no time to respond. 

Think in terms of the square wave driving the speaker. For 1-bit sampled
sounds, toggles occur at an audio rate—at the zero crossings. For, say,
DAC522, the toggles occur twice every 46 cycles, creating a square wave
with varying duty cycles. Since the speaker can’t (fully) respond at this
ultrasonic rate, it moves toward a proportional position determined by the
duty cycle. Since 32 different pulse widths are used, the effect is of a
DAC with 5 bits, a sample rate of 11kHz, and a pulse rate of 22kHz. 

> On Saturday, March 24, 2018 at 6:18:52 PM UTC-7, mjm...@aol.com wrote:
>> 
>> Zero crossings do not toggle a flip flop. There is no flip flop. The high
>> bit is simply a reading of whether the cassette input is above zero or
>> below zero. 
>> 
>>> The real benefit of being able to use WAVs, in my mind, would be being
>>> able to edit sounds in something like Audacity, then importing them to
>>> the A2 to use in a multi-tasked way. If you compute your final player's
>>> sample rate (including the cycles your code is doing it's other loops),
>>> you could align beats onto individual playback pages (or half-pages).
>>> That way the necessary stuttering (as all code requires 100% of CPU)
>>> during multi-tasked playback would at least sound musically synchronized.
>>> 
>>> f
>>> 
>> Audacity works well for this when paired with a short program to truncate
>> the samples to their high bit. (The ear is not sensitive to polarity, and
>> the speaker and cassette outputs do not provide a way to control polarity
>> of output.)
>> 
>> 
>> -- 
>> -michael - NadaNet 3.1 and AppleCrate II:  http://michaeljmahon.com
> 
> 



-- 
-michael - NadaNet 3.1 and AppleCrate II:  http://michaeljmahon.com

[toc] | [prev] | [next] | [standalone]

#4451

On Saturday, March 24, 2018 at 8:43:11 PM UTC-7, mjm...@aol.com wrote:
> Your experiment suggests that the op amp has som hysteresis, perhaps to
> minimize output flipping by noise when no input is present. 
> 

Right. That makes sense.


Just did a quick test program which unfortunately isn't producing anything like the 8-bit WAV I loaded into $800. Do I need to incorporate that EOR code to detect if we did a zero-cross vs the last sample? (Also, it's toggling on zero, which it probably shouldn't).

f


 ORG $300 ; CALL 768
 LDX #$00
 STX GetByte+1 ; Start Address (Low Byte)
 LDY #$08
 STY GetByte+2 ; Start Address (High Byte) $0800
 JMP GetByte ; Start reading bytes
SamePage PHA
 LDA #4 ; Playback Speed
 JSR $FCA8 ; WAIT based on accumulator value
 PLA
 ASL ; Shift high bit into carry
 NOP
 BCS Delay ; if carry set, don't click (negative)
 STA $C030 ; Click speaker (found a positive)
 BCC GetByte
Delay CMP ($00,X) ; to synchronize 0/1 timing
GetByte LDA $D1D1,X ; Start Address **SELF-MODIFIED!
 INX
 BNE SamePage1 ; finish current page
 INC GetByte+2 ; move on to next page
 LDA GetByte+2
 CMP #$96 ; Stop Address (high byte only) $9600
 BNE SamePage ; not done, keep going
 RTS ; We're done with all pages, exit
SamePage1 CMP ($00,X) ; even out GetByte cycle count
 NOP
 JMP SamePage

[toc] | [prev] | [next] | [standalone]

#4454

Frank M. <frank_o_rama@hotmail.com> wrote:
> On Saturday, March 24, 2018 at 8:43:11 PM UTC-7, mjm...@aol.com wrote:
>> Your experiment suggests that the op amp has som hysteresis, perhaps to
>> minimize output flipping by noise when no input is present. 
>> 
> 
> Right. That makes sense.
> 
> 
> Just did a quick test program which unfortunately isn't producing
> anything like the 8-bit WAV I loaded into $800. Do I need to incorporate
> that EOR code to detect if we did a zero-cross vs the last sample? (Also,
> it's toggling on zero, which it probably shouldn't).
> 
> f

Since the speaker and cassette outputs can only be toggled, not set, it is
important to toggle them only when the input sample changes—so, yes, the
EOR is necessary (or some equivalent two part loop). 

> 
>  ORG $300 ; CALL 768
>  LDX #$00
>  STX GetByte+1 ; Start Address (Low Byte)
>  LDY #$08
>  STY GetByte+2 ; Start Address (High Byte) $0800
>  JMP GetByte ; Start reading bytes
> SamePage PHA
>  LDA #4 ; Playback Speed
>  JSR $FCA8 ; WAIT based on accumulator value
>  PLA
>  ASL ; Shift high bit into carry
>  NOP
>  BCS Delay ; if carry set, don't click (negative)
>  STA $C030 ; Click speaker (found a positive)
>  BCC GetByte
> Delay CMP ($00,X) ; to synchronize 0/1 timing
> GetByte LDA $D1D1,X ; Start Address **SELF-MODIFIED!
>  INX
>  BNE SamePage1 ; finish current page
>  INC GetByte+2 ; move on to next page
>  LDA GetByte+2
>  CMP #$96 ; Stop Address (high byte only) $9600
>  BNE SamePage ; not done, keep going
>  RTS ; We're done with all pages, exit
> SamePage1 CMP ($00,X) ; even out GetByte cycle count
>  NOP
>  JMP SamePage
> 
> 



-- 
-michael - NadaNet 3.1 and AppleCrate II:  http://michaeljmahon.com

[toc] | [prev] | [next] | [standalone]

#4444

1 page = 256 bytes = 2,048 1-bit samples = 0.24 seconds at an 8,500Hz sample rate

[toc] | [prev] | [next] | [standalone]

#4511

> I calculated the following... 
> 1,020,500 CPU cycles per second / 11,025 hz = roughly 92.5 cycles per sample 

Your calculation is close -- but you are off by factor of 1/2.

Remember, you need to toggle the speaker *peak-to-peak.*

- - -

11,025 Hz requires = 17,030 * 29.97 / 11,025 = 46.293 cycles between speaker toggling.

The 11,025 Hz square wave sounds like:
http://www.szynalski.com/tone-generator/#11025,squ,v0.25

# 11,025 Hz, 6502 source:

            ORG $300

Loop        LDA $C000   ; 4         += 4   = 7      -39
            BMI Done    ; 2         += 2   = 9      -37
            LDY #6      ; 2         += 2   = 11     -35
Delay1      DEY         ; 6*2       += 12  = 23     -23
            BNE Delay1  ; 5*3 + 2   += 17  = 40     -6
            NOP         ; 2         += 2   = 42     -4
Squeeker    STA $C030   ; 4         += 4   = 46     =0
            JMP Loop    ; 3         += 3   = 3      -43
Done        STA $C010
            RTS

# 11,025 Hz, 6502 code:

0300:AD 00 C0 30 0C A0 06 88
0308:D0 FD EA 8D 30 C0 4C 00
0310:03 8D 10 C0 60 


- - - 


220 Hz requires = 17,030 * 29.97 / 220 Hz = 2,319.950 cycles between speaker toggling.

The 220 Hz square wave sounds like this:
http://www.szynalski.com/tone-generator/#2200,squ,v0.25

# 200 Hz, 6502 source:

            ORG $300

Loop        LDA $C000   ; 4         += 4   = 7
            BMI Done    ; 2         += 2   = 9
            LDY #0      ; 2         += 2   = 11
Delay1      DEY         ; 256*2     += 512 = 523
            BNE Delay1  ; 255*3 + 2 += 767 = 1,290
            LDX #205    ; 2         += 2   = 1,292
Delay2      DEX         ; 205*2     += 408 = 1,700
            BNE Delay2  ; 204*3 + 2 += 614 = 2,314
Squeeker    STA $C030   ; 4         += 4   = 2,320
            JMP Loop    ; 3         += 3   = 3
Done        STA $C010
            RTS

# 200 Hz, 6502 binary:

0300:AD 00 C0 30 10 A0 00 88
0308:D0 FD A2 CD CA D0 FD 8D
0310:30 C0 4C 00 03 8D 10 C0
0318:60 

If you keep your browser window open, and play the 6502 code at the same time you will minimal "beats".


- - -


100 Hz requires = 17,030 * 29.97 / 100  = 5,103.891 cycles between speaker toggling.

The 100 Hz square wave sounds like this:
http://www.szynalski.com/tone-generator/#100,squ,v0.25

# 100 Hz, 6502 source:

            ORG $300

Loop        LDA $C000   ; 4         += 4   = 7      -5097
            BMI Done    ; 2         += 2   = 9      -5095
            LDY #0      ; 2         += 2   = 11     -5093
Delay1      DEY         ; 256*2     += 512 = 523    -4581
            BNE Delay1  ; 255*3 + 2 += 767 = 1,2900 -3814
Delay2      DEY         ; 256*2     += 512 = 1,802  -3302
            BNE Delay2  ; 255*3 + 2 += 767 = 2,569  -2535
Delay3      DEY         ; 256*2     += 512 = 3,081  -2023
            BNE Delay3  ; 255*3 + 2 += 767 = 3,848  -1256
            LDX #249    ; 2         += 2   = 3,850  -1254
Delay4      DEX         ; 249*2     += 498 = 4,348  -756
            BNE Delay4  ; 248*3 + 2 += 746 = 5,094  -10
            BEQ Delay5  ; 3         += 3   = 5,097  -7
Delay5      BEQ Delay6  ; 3         += 3   = 5,100  -4
Delay6      STA $C030   ; 4         += 4   = 5,104  =0
            JMP Loop    ; 3         += 3   = 3      -5101
Done        STA $C010
            RTS

# 100 Hz, 6502 binary:

0300:AD 00 C0 30 1A A0 00 88
0308:D0 FD 88 D0 FD 88 D0 FD
0310:A2 F9 CA D0 FD F0 00 F0
0318:00 8D 30 C0 4C 00 03 8D
0320:10 C0 60 


Michael

[toc] | [prev] | [next] | [standalone]

#4512

Michael Pohoreski <michael.pohoreski@gmail.com> wrote:
>> I calculated the following... 
>> 1,020,500 CPU cycles per second / 11,025 hz = roughly 92.5 cycles per sample 
> 
> Your calculation is close -- but you are off by factor of 1/2.
> 
> Remember, you need to toggle the speaker *peak-to-peak.*
> 
> - - -
> 
> 11,025 Hz requires = 17,030 * 29.97 / 11,025 = 46.293 cycles between speaker toggling.
> 

I think the OP’s meaning was that at a sample rate of 11.025 KHz, each
sample must be played in (ideally) 92.5 Apple II cycles. 

Of course, only integral numbers of cycles are possible, and the sample
rate cannot alternate between 92 and 93 cycles, since the jitter would
introduce spurious frequencies surrounding 5.5125 KHz. 

The best non-distorting choice is then 92 cycles per sample. I found this
convenient in DAC522, since 92 is an even number, and I wanted to generate
two speaker pulses (four toggles) for each sample. This raises the pulse
frequency to 22.05 KHz, which is less annoying to most people “of an age”
and also much easier to filter, since the correct output of an 11.05 KHz
sampled system is limited to 0 Hz to 5.5125 KHz. 

(In the absence of “brick wall” filters, the practical top frequency is
closer to 5 KHz.)

-- 
-michael - NadaNet 3.1 and AppleCrate II:  http://michaeljmahon.com

[toc] | [prev] | [next] | [standalone]

#4513

On Saturday, April 21, 2018 at 11:54:51 PM UTC-7, mjm...@aol.com wrote:
> Michael Pohoreski wrote:
> > 11,025 Hz requires = 17,030 * 29.97 / 11,025 = 46.293 cycles between speaker toggling.
> > 
> I think the OP’s meaning was that at a sample rate of 11.025 KHz, each
> sample must be played in (ideally) 92.5 Apple II cycles. 

Right. I just wanted to clarify that a "sample" means two speaker toggles since it wasn't explicitly clear. =P

> Of course, only integral numbers of cycles are possible, and the sample
> rate cannot alternate between 92 and 93 cycles, since the jitter would
> introduce spurious frequencies surrounding 5.5125 KHz. 

I'm assuming this related to following calculations?

92 cycles = 5547.707609 Hz
93 cycles = 5488.054839 Hz


> The best non-distorting choice is then 92 cycles per sample.

Interesting. How did you determine that?


> I found this convenient in DAC522, since 92 is an even number, 
> and I wanted to generate
> two speaker pulses (four toggles) for each sample. 

What was the duty cycle you used for 4 pulses?

> This raises the pulse
> frequency to 22.05 KHz, which is less annoying to most people “of an age”

I must be getting old, because I can't hear anything past ~14 KHz ... :-/

> (In the absence of “brick wall” filters, the practical top frequency is
> closer to 5 KHz.)

How did you determine that?

Cheers
Michael

[toc] | [prev] | [next] | [standalone]

#4517

Michael Pohoreski <michael.pohoreski@gmail.com> wrote:
> On Saturday, April 21, 2018 at 11:54:51 PM UTC-7, mjm...@aol.com wrote:
>> Michael Pohoreski wrote:
>>> 11,025 Hz requires = 17,030 * 29.97 / 11,025 = 46.293 cycles between speaker toggling.
>>> 
>> I think the OP’s meaning was that at a sample rate of 11.025 KHz, each
>> sample must be played in (ideally) 92.5 Apple II cycles. 
> 
> Right. I just wanted to clarify that a "sample" means two speaker toggles
> since it wasn't explicitly clear. =P

Right. 

>> Of course, only integral numbers of cycles are possible, and the sample
>> rate cannot alternate between 92 and 93 cycles, since the jitter would
>> introduce spurious frequencies surrounding 5.5125 KHz. 
> 
> I'm assuming this related to following calculations?
> 
> 92 cycles = 5547.707609 Hz
> 93 cycles = 5488.054839 Hz

Simpler—see my other reply. 

>> The best non-distorting choice is then 92 cycles per sample.
> 
> Interesting. How did you determine that?

It’s just the closest even number, and I prefer even numbers because I
prefer double pulse rates. ;-)

>> I found this convenient in DAC522, since 92 is an even number, 
>> and I wanted to generate
>> two speaker pulses (four toggles) for each sample. 
> 
> What was the duty cycle you used for 4 pulses?

I generate 32 distinct pulse widths, determined by the 5 most significant
bits of the sample. The pulse widths vary from 6 to 37 cycles with a
46-cycle period. (DAC522 refers to 5 significant bits and a 22 KHz pulse
rate.)

>> This raises the pulse
>> frequency to 22.05 KHz, which is less annoying to most people “of an age”
> 
> I must be getting old, because I can't hear anything past ~14 KHz ... :-/

Age will do that for most people—well, age and loud music. ;-)  I’m
currently about 30 dB down at 3.5 KHz...

>> (In the absence of “brick wall” filters, the practical top frequency is
>> closer to 5 KHz.)
> 
> How did you determine that?

The “reconstruction filter” following a D-to-A converter must provide a lot
of attenuation at and above the Nyquist frequency of about 5.5 KHz, and
since very sharp (brick wall) filters are not practical, there’s usually a
rolloff before 5 KHz.

> Cheers
> Michael
> 



-- 
-michael - NadaNet 3.1 and AppleCrate II:  http://michaeljmahon.com

[toc] | [prev] | [next] | [standalone]

#4514

On Saturday, April 21, 2018 at 11:54:51 PM UTC-7, mjm...@aol.com wrote:
> rate cannot alternate between 92 and 93 cycles, since the jitter would
> introduce spurious frequencies surrounding 5.5125 KHz. 

Is this 5512.5 Hz derived from 92.5 cycles?

Hmm, I'm using the formula: 

  Hz = 17,030 * 29.97 / cycles.
     = 510,389.1 / 92.5 
     = 5517.72 Hz.

Or are you using a NTSC rate of 29.94 Hz for the formula?

   Hz = 509,906.25 / cycles
      = 17,030 * 29.94 / cycles

It doesn't look like 29.9695 for NTSC's field rate is the correct Hz?

   Hz = 17,030 * 29.9695 / 92.5
      = 510,380.585 / 92.5
      = 5517.62 Hz

[toc] | [prev] | [next] | [standalone]

#4515

I ended up with a 6615hz sample rate for the player. I thought the A2 does 1,020,500 cycles per second? 1020500/6615/2 = 77.1 cycles per sample.

FWIW, I don't actually think using WAV files is the best way to import 1-bit audio. If you use the cassette input instead, you can shape the input waveform in real time so that it doesn't sound horrible. I use the "visualizer" program I recently posted to get things sounding good, then use the COMPUTE! recorder program to record the bitstream. You can do all this in Audacity, but it's a longer workflow to test the audio quality, make EQ tweaks, test again, export, then convert the resulting WAV down to 1-bit.

Another downside; if you load an 8-bit WAV into main memory you only have 5 seconds or so of playback time.

F

[toc] | [prev] | [next] | [standalone]

#4516

Michael Pohoreski <michael.pohoreski@gmail.com> wrote:
> On Saturday, April 21, 2018 at 11:54:51 PM UTC-7, mjm...@aol.com wrote:
>> rate cannot alternate between 92 and 93 cycles, since the jitter would
>> introduce spurious frequencies surrounding 5.5125 KHz. 
> 
> Is this 5512.5 Hz derived from 92.5 cycles?
> 
> Hmm, I'm using the formula: 
> 
>   Hz = 17,030 * 29.97 / cycles.
>      = 510,389.1 / 92.5 
>      = 5517.72 Hz.
> 
> Or are you using a NTSC rate of 29.94 Hz for the formula?
> 
>    Hz = 509,906.25 / cycles
>       = 17,030 * 29.94 / cycles
> 
> It doesn't look like 29.9695 for NTSC's field rate is the correct Hz?
> 
>    Hz = 17,030 * 29.9695 / 92.5
>       = 510,380.585 / 92.5
>       = 5517.62 Hz
> 
> 
> 

Much simpler. ;-)

5.5125 KHz is derived from the (somewhat) standard 11.025 KHz audio
sampling frequency, which is 1/4 of the standard 44.1 KHz CD sampling
rate—what Apple once referred to a AM radio quality. 

So the highest frequency that can be transmitted by a stream of 11.025 KHz
samples is the Nyquist frequency: half the sample rate. Any higher
frequencies would be aliased to lower frequencies. 

I was simply observing that the noise introduced by playing uniformly
sampled signals at a non-uniform playback rate will be aliased back into
the audible range, and therefore non-uniform playback rates should be
avoided if possible. 

A uniform sample playback rate which is about 0.5% fast is generally
imperceptible (except for those unfortunate folks with perfect pitch). 

-- 
-michael - NadaNet 3.1 and AppleCrate II:  http://michaeljmahon.com

[toc] | [prev] | [next] | [standalone]

#4524

Thanks for the explanation W.R.T. 11025 Hz / 2 = 5,512.5 Hz, Michael!

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.sys.apple2.programmer

csiph-web