Hertz Overload - new demo for AGA Amigas

[pandy71]

Originally Posted by saimo

@pandyMany thanks for the hard work!One thing, though:Exposing the users' equiment to such risks and asking them to take this kind of precautions is a no go: I do understand the theoretical research objectives, but personally I'm after a practical solution to use in contexts like demos and games.By the way, it's years that I no longer have speakers: I moved from place to place several times, and every time I had to get rid of everything, until I just grew tired of that. So now my A1200 is connected to a monitor with unsignificant speakers and for these tests I'm simply using commercial-quality headphones. Also, I tried to sample the A1200 output connecting the machine to the PC, but there's a consistent noise floor that would hamper any kind of software-based measurements.In short: I'm not really the right person to make appropriate tests I hope my tools (which I have just updated and I'll upload after testing them on the A1200) will be of help to others, though.

Well - i can't predict situation where someone convert 24 bit silence (as i made to render dynamics range) and push his amplifier knob to max ruining 200k+$ worth B&W Nautilus speakers.With real Amiga HW speakers are quite safe as there are 2 low pass filters - one that can be switched off (not valid for A1000 and older A500) and second fixed one (reconstruction filter) - normally you have also some 56kHz remains from PWM so i think this warning is just in case.We are old enough to be aware that coffee can be hot so you need be caution when you drink's.No worries then - just don't be Marty. [ Show youtube player ]

Btw - i produce wav files with signed 8 bit integer - not sure how your application will deal with this but i wanted to keep it same as 8svx.

[x-vision]

Originally Posted by saimo

Uploaded updated tools.

Download & information

Changes:
* removed padding bytes from the signal data in the AQA2 files (so, sAQA2 does no longer support the old AQA2 files);
* added rounding to the 16->14-bit conversion code in cWAV16toAQA1;
* made cWAV8toAQA2 accept signal files which contain enough data with respect to the carrier files (before, it required the data ratio to be exactly 2:1).

The audio files were also updated, as I have re-rendered the WAVs from the original 24-bit FLAC (instead of the intermediate 16-bit WAV) and then converted them to AQAx with the updated tools.

Now I'm going to make some tests by massively reducing the amplification of the test song and then by hearing the results on the Amiga.

Great work indeed, congrats!

I just worry it doesn't get much used because of the high cpu demand. Do you know/considered Kippened' work used on "The Martini effect demo"?

https://www.pouet.net/prod.php?post=920727

[saimo]

Originally Posted by pandy71

Well - i can't predict situation where someone convert 24 bit silence (as i made to render dynamics range) and push his amplifier knob to max ruining 200k+$ worth B&W Nautilus speakers.With real Amiga HW speakers are quite safe as there are 2 low pass filters - one that can be switched off (not valid for A1000 and older A500) and second fixed one (reconstruction filter) - normally you have also some 56kHz remains from PWM so i think this warning is just in case.We are old enough to be aware that coffee can be hot so you need be caution when you drink's.No worries then - just don't be Marty. [ Show youtube player ]

LOL

Btw - i produce wav files with signed 8 bit integer - not sure how your application will deal with this but i wanted to keep it same as 8svx.

The converters will screw up, as they expect 8 bit WAVs to be unsigned - I didn't even know that that a signed variant existed. I'll look into that. Also, the converters are no SoX: they just know the basic versions of the format.

Tomorrow I'll make tests with your script.

Now I have just made a few listening tests as follows:
* reduced the Sony music snippet by 20 dB (just to decrease the SNR drastically);
* with Reaper, I converted the waveform to various 8 and 16 bit WAVs, both with and without noise shaping and dithering;
* converted them to AQAx;
* listened to them on the Amiga.

Result: 14 55420 [NS+D] > 8 55420 NS+D > 8 96000 NS+D > 8 96000
where:
* 8 14 = bit depth
* 55420 96000 = frequency
* NS+D = noise shaping + dithering
* > = betten than

Noteworthy:
* 8 55420 NS+D sound less noisy and distorted than 8 96000 NS+D!
* regarding the 14 bit waveforms, I have a hard time noticing any improvement brought by the noise-shaping and dithering;
* the 14 bit waveforms sound immensely better than the 8 bit ones, as I can't hear any noise.

Please note that I made these tests with aching ears (using headphones has always been a pain to me), so I played the files only once or at most twice when I was in doubt; on top of that, I'm deadly tired and my head spins due to sleep deprivation. I mean, these tests are all but reliable.

Here are the files for everyone to make their own tests (and possibly proper measurements):
96000 Hz 32 bit WAV (base file)
55420 Hz 16 bit WAV
55420 Hz 14 bit AQA1
55420 Hz 16 bit noise-shaped&dithered WAV
55420 Hz 14 bit noise-shaped&dithered AQA1
96000 Hz 8 bit WAV
96000 Hz 8 bit AQA0
96000 Hz 8 bit noise-shaped&dithered WAV
96000 Hz 8 bit noise-shaped&dithered AQA0
55420 Hz 8 bit noise-shaped&dithered WAV
55420 Hz 8 bit noise-shaped&dithered AQA0

[saimo]

Originally Posted by x-vision

Great work indeed, congrats!

Thanks!

I just worry it doesn't get much used because of the high cpu demand.

Well, I did this first and foremost to have fun myself. If others find it useful, it will be a bonus
I guess that CPU-driven playback is practically usable only for a non-multitasking player (actually an idea that preceded the demo was to make a simple and dedicated player - no DeliTracker, I mean - to play the music I made for SkillGrid, THE CURE, BOH and this demo plus another piece in "superior" quality).

Do you know/considered Kippened' work used on "The Martini effect demo"? https://www.pouet.net/prod.php?post=920727

No, I didn't know. In the comments, I've found this:

The music routine is approximating an original 16-bit signal in chunks of 512 samples using normalized_8_bit_signal[i] x amiga_channel_volume[chunk]. This gives more bit resolution in low volume parts of the track making the output better than pure-8-bit and without the volume loss of the traditional 14-bit technique. If the best approximation would be an volume of 31.5, then amiga_channel_volume of channel 0 would be set to 30 and of channel 1 to 32 etc. Hopefully giving a next multiplier of 31.5.

If I understand correctly, it's amplitude modulation (the same idea of Karlos, implemented by the AQA2 format), but doubled on the paired channels to double the resolution.

[Karlos]

Originally Posted by saimo

No, I didn't know. In the comments, I've found this:If I understand correctly. it's amplitude modulation (the same idea of Karlos, implemented by the AQA2 format), but doubled on the paired channels to double the resolution.

No such thing as a new idea, I guess I didn't know about this either. Mind you, mine can't make use of the double channel trick as it was intended for pure DMA operation, so you need the other channel to feed the volume modulator.

[saimo]

Originally Posted by Karlos

No such thing as a new idea, I guess I didn't know about this either. Mind you, mine can't make use of the double channel trick as it was intended for pure DMA operation, so you need the other channel to feed the volume modulator.

In fact, I doubt my understanding of that comment is correct: I find it hard to believe that the audio is CPU-driven in the context of that demo.

By the way, reading that comment made me realize that, at least numerically, it is possible to surpass the 16 bit resolution (by just a trifle) - for example, for the right side:
* AUD0DAT: 8 bit data
* AUD3DAT: 8 bit data (just additional bits for the same sample)
* AUD0VOL: 6 bit (+1) volume
* AUD3VOL: 6 bit (+1) volume

The data registers provide 9 bit resolution (with a little DC offset) and the volume registers provide 7 bit (+ something) resolution, for a total of 16 bit (plus something) resolution.
The downside is that, for 16 bits, 32 bits = 4 bytes are required (plus all the usual timing and phase issues).

[saimo]

Originally Posted by saimo

...* volume counters counting upwards: this answers my question about how it was possible that a volume of 1 has some effect also with a period of 50; given that the AHRM uses "volctrrld" (or something like that - I don't have it at hand now), I had assumed they were counting downwards.
Also, now that I know how the volume counters work and that they get reloaded also in CPU-driven operation, I can see that in this case of 14-bit playback with period 50 the error that affects the second sample of each word containing the least significant 6 bits is that it gets sent to the DAC with a delay of 14 clocks, so for such an interval of time the upper byte and the lower one go out of sync....

The quoted thoughts kept on lingering in my mind as they sound just too odd. Wouldn't it be more logical that the volume counter is reset also when the second sample of a word starts? The period does get reloaded (it's even documented in the audio state diagram in the AHRM), so why not the volume? That seems more plausible to me.
If that's the case:
* contrary to what I wrote above, the upper-byte and lower-byte channels stay in sync, but a distortion happens because the volume counter never executes all the 64 cycles (the context here is 14-bit playback with period < 64);
* in theory, it should be possible to compensate the distortion by scaling the lower byte value accordingly (so, going below the 6 bits precision), but I guess that it isn't a matter of just multiplying by period/64 (for the same reason that the 14-bit trick requires calibration).

Even if I was pretty hopeless, as I don't have an oscilloscope or any other appropriate device, I tried to find out visually: I generated a sinus tone at 64489 Hz (= 3546895/55), played it on my A1200, sampled the output on the PC at 64489 x1/x2/x3 and checked whether the resulting waveform showed some sort of pattern that could indicate "first sample of a word OK", "second sample of a word not quite OK"; the result was instead a pretty regular sinusoid where any irregularity was due to the recording phase (there was no way to sync playback and recording start) and real world interferences.

So, is it known/proven whether the volume counter resets when the second sample of a word starts?

By the way, according to the sampling tests, my A1200 has a dynamic range of 117.984 dB: considering the human hearing range, that sounds plausible/correct, right?

Tangentially, another thing that keeps on bugging me: given the volume counter mechanism, volume should not work fine for any period non-multiple of 64, not just for periods < 64... or am I missing something?

(Please bear with me: I'm pretty sure these matters have been discussed elsewhere, but my searches here failed to provide me with the answers.)

[pandy71]

Originally Posted by saimo

Noteworthy:
* 8 55420 NS+D sound less noisy and distored than 8 96000 NS+D!
* regarding the 14 bit waveforms, I have a hard time noticing any improvement brought by the noise-shaping and dithering;
* the 14 bit waveforms sound immensely better than the 8 bit ones, as I can't hear any noise.

Please note that I made these tests with aching ears (using headphones has always been a pain to me), so I played the files only once or at most twice when I was in doubt; on top of that, I'm deadly tired and my head spins due to sleep deprivation. I mean, these tests are all but reliable.

Ok, - this is another version of script - modified way how bandpass sinc filter is applied - currently spectrum between 16Hz and 75% of sample rate/2 is unfiltered i.e. useful audio spectrum stays intact.

Secondly i produce another wav file (ends with "_play.wav") - 24 bit 48000Hz sample rate so it can be listened on general PC to simulate how it should sounds on real Amiga HW - there is also applied inverted Amiga low pass filter.
If your audio on PC sounds different then this must be something related to way how signal is processed trough signal chain in OS.

@setlocal

@REM Where to Find SoX
@set SoX=C:\sox
@set PATH=%PATH%;%SoX%

@set PAL=28375160
@set NTSC=28636363

@rem lipshitz, f-weighted, modified-e-weighted, improved-e-weighted, gesemann, shibata, low-shibata, high-shibata

@set noiseshp=improved-e-weighted

@rem LowPassFilter F=
@rem Amiga 500/2000: 4.42 kHz (100 nF, 360 ?)
@rem A600: 4.42 kHz (100 nF, 360 ?)11
@rem A1200 Rev1d: 27.7 kHz (3.9 nF, 1.5 k?)
@rem A1200 Rev2: 34.4 kHz (6.8 nF, 680 ?)
@rem A4000: 4.52 kHz (47 nF, 750 ?)

@SET LPF=4420

@SET /a CLK=%PAL%/8

@rem set Paula period (DEC)
@SET PERIOD=55

@SET /a AFREQ_I = (((100*%CLK%)/(1*%PERIOD%))+1) / 100
@SET /a AFREQ_F = (((100*%CLK%)/(1*%PERIOD%))+1) %% 100
@SET AFREQ=%AFREQ_I%.%AFREQ_F%

@SET /a APREC_I = (((100*%CLK%)/(8*%PERIOD%))) / 100
@SET /a APREC_F = (((100*%CLK%)/(8*%PERIOD%))) %% 100
@SET APREC=%APREC_I%.%APREC_F%

@SET /a SINCU=%APREC_I% * 3

@SET file=%1
@SET fname=%~n1

@ECHO file=%file%
@ECHO:
@ECHO filename=%fname%
@ECHO:
@ECHO --------------------------
@ECHO:
@ECHO Samplerate=%AFREQ%Hz
@ECHO:
@ECHO --------------------------
@ECHO:
@ECHO Precompensation=%APREC%Hz
@ECHO:
@ECHO --------------------------
@ECHO:
@ECHO Amiga LowPass freq=%LPF%Hz
@ECHO:
@ECHO --------------------------
@ECHO:
@ECHO SINC Upper Freq=%SINCU%Hz
@ECHO:
@ECHO --------------------------
@ECHO:

@pause

@rem SET aproc= 
@rem SET aproc=sinc 16-13.85k treble +6.0206 %LPF% .5 treble +6.0206 %APREC% .5 compand 0.25,1 6:-inf,-90.1,-inf,-90,-75,-70,-70 -3.0103 -90 0.20

@rem SET aproc=sinc 16-%SINCU% treble +6.0206 %LPF% 0.1s treble +6.0206 %APREC% 0.1s gain -n -0.034129
@SET aproc=sinc 16-%SINCU% treble +20 %LPF% 0.25s treble +3.0103 %APREC% 0.25s gain -n -0.034129

@rem set clip=
@rem set clip=gain -n -1.769537
@rem set clip=gain -n -2.110204
@rem set clip=gain -n -2.153742
@rem set clip=gain -n -2.197500

@set clip=gain -n -0.526579

@rem mono
@rem sox --multi-threaded --buffer 524288 --input-buffer 524288 -S -V4 -D -G %file% -e float -b 32 -t f32 "%fname%.f32" remix - rate -v -s -I %AFREQ% %aproc% stats -b 8 stat
@rem sox --multi-threaded --buffer 524288 --input-buffer 524288 -S -V6 -D -c 1 -r 48299 -e float -b 32 -t f32 "%fname%.f32" -c 1 -b 8 -e signed-integer -t s8 "%fname%.s8" %clip% dither -f %noiseshp% -p 8 stats -b 8 stat 
@rem sox --multi-threaded --buffer 524288 --input-buffer 524288 -S -V6 -D -c 1 -r %AFREQ% -b 8 -e signed-integer -t s8 "%fname%.s8" "%fname%.8svx"
@rem sox --multi-threaded --buffer 524288 --input-buffer 524288 -S -V6 -D -c 1 -r %AFREQ% -b 8 -e signed-integer -t s8 "%fname%.s8" "%fname%_%noiseshp%.wav"

@rem sox --multi-threaded --buffer 524288 --input-buffer 524288 -S -V6 -D -c 1 -r %AFREQ% -e float -b 32 -t f32 "%fname%.f32" -n spectrogram -z 96 -q 13 -w Kaiser -y 513 -x 496 -o "%fname%_32.png"
@rem sox --multi-threaded --buffer 524288 --input-buffer 524288 -S -V6 -D -c 1 -r %AFREQ% -e signed-integer -b 8 -t s8 "%fname%.s8" -n spectrogram -z 96 -q 13 -w Kaiser -y 513 -x 496 -o "%fname%_8.png"


@rem stereo
@sox --multi-threaded --buffer 524288 --input-buffer 524288 -S -V4 -D -G %file% -e float -b 32 -t f32 "%fname%.f32" rate -v -s -I %AFREQ% %aproc% stats -b 8 stat
@sox --multi-threaded --buffer 524288 --input-buffer 524288 -S -V6 -D -c 2 -r 48299 -e float -b 32 -t f32 "%fname%.f32" -c 2 -b 8 -e signed-integer -t s8 "%fname%.s8" %clip% dither -f %noiseshp% -p 8 stats -b 8 stat 
@rem sox --multi-threaded --buffer 524288 --input-buffer 524288 -S -V6 -D -c 2 -r %AFREQ% -b 8 -e signed-integer -t s8 "%fname%.s8" "%fname%.8svx"
@sox --multi-threaded --buffer 524288 --input-buffer 524288 -S -V6 -D -c 2 -r %AFREQ% -b 8 -e signed-integer -t s8 "%fname%.s8" "%fname%_%noiseshp%.wav"

@sox --multi-threaded --buffer 524288 --input-buffer 524288 -S -V6 -D -c 2 -r %AFREQ% -e float -b 32 -t f32 "%fname%.f32" -n remix - spectrogram -z 96 -q 13 -w Kaiser -y 513 -x 496 -o "%fname%_32.png"
@sox --multi-threaded --buffer 524288 --input-buffer 524288 -S -V6 -D -c 2 -r %AFREQ% -e signed-integer -b 8 -t s8 "%fname%.s8" -n remix - spectrogram -z 96 -q 13 -w Kaiser -y 513 -x 496 -o "%fname%_8.png"

@sox --multi-threaded --buffer 524288 --input-buffer 524288 -S -V4 -D -G "%fname%_%noiseshp%.wav" -e signed-integer -b 24 "%fname%_%noiseshp%_play.wav" treble -20 %LPF% 0.25s treble -3.0103 %APREC% 0.25s rate -v -s -I 48000 gain -n -0.034129 stats -b 8 stat

@del -q "%fname%.f32"
@del -q "%fname%.s8"

@pause
@endlocal

Btw if someone searching for audio analyzer and audio generator i can highly recommends this piece of jewel - to be honest i never saw before such excellent tool even for big bucks: https://www.roomeqwizard.com/

[Gorf]

Originally Posted by saimo

By the way, according to the sampling tests, my A1200 has a dynamic range of 117.984 dB: considering the human hearing range, that sounds plausible/correct, right?

The way the volume reduction works on real hardware (on-off-switching), I would be suspicious about any volume below max

[pandy71]

Originally Posted by saimo

By the way, according to the sampling tests, my A1200 has a dynamic range of 117.984 dB: considering the human hearing range, that sounds plausible/correct, right?

Then your A1200 will be really good audiophile piece - even if Paula in PLCC package has better distributed power supply and ground, then overall PCB layout is very good and there is no ripple from power lines when other system components are active then i would expect figures closer to 70..80dB dynamics and we not even touching Paula DAC's linearity.On other side PWM should be inherently linear as volume regulator only i have impression that setting time from DAC itself and external current to voltage converter made on relatively slow OPAMP can introduce severe distortions (this why i pursuing possibility play high sample rate audio on Paula - i have plan to modify external Paula circuitry to made it more high quality source)

Originally Posted by saimo

Tangentially, another thing that keeps on bugging me: given the volume counter mechanism, volume shouldn't work perfectly for any period non-multiple of 64, not just for periods < 64... or am I missing something?(Please bear with me: I'm pretty sure these matters have been discussed elsewhere, but my searches here failed to provide me with the answers.)

This is not entirely clear (how PWM volume regulation is implemented) but i assume for periods 128 and lower this should be pretty linear and proper volume regulation implementation but for periods smaller than 128 you may expect aliasing products from 3.58MHz/64 and current sampling rate.

[Karlos]

A bit off topic, are there any computationally inexpensive noise shaping that can be applied to 8 bit quantised data at more pedestrian sample rates?

[pandy71]

Originally Posted by Karlos

A bit off topic, are there any computationally inexpensive noise shaping that can be applied to 8 bit quantised data at more pedestrian sample rates?

If i understand you correctly you are asking if there is way to apply noise shaping to non oversampled audio - this is contradictory to Gerson-Craven noise shaping theorem - you may try to use different color dither.ffmpeg offer some form of noise shaping (shibata curve) for lower sample rates - at least this is in ffmpeg source https://ffmpeg.org/doxygen/7.0/noise...8c_source.html (seem those sampling frequencies are supported 37800, 32000, 22050, 16000, 11025, 8000).But i don't expect spectacular results - to work properly noise shaping need oversampled audio - to push quantization error (as noise) in not audible part of spectrum - this is similar principle as dithering in graphics - low resolution dithering is obvious but when you are going to high resolution - then it start to be linear tone - like on laser printer where there is only black and white (or CMYK in color printers) but dots density create impression of continuous tone.My point with noise shaping on Amiga is that people pushing 2 channels to create pseud 14 bit mode where with the same bandwidth, twice oversampled 8 bit PCM should deliver comparable or better quality especially if noise shaping filter will be optimally designed (Paula will be close to 16 bit).

[Karlos]

I was just curious about the general problem. Since quantisation noise is strongly correlated with the input signal, it's more conspicuous than white noise. Does a basic noise injection pre-quantisation help change the perception of the quantisation noise into something less intrusive?

[saimo]

Originally Posted by pandy71

Ok, - this is another version of script

Just for clarity: I have not tested your scripts yet and my previous report was based on processing performed with Reaper. Today I couldn't find the time to try the scripts, but I'll do that as soon as possible.

And, of course, thanks also for this alternative script!

[Gorf]

Originally Posted by Karlos

A bit off topic, are there any computationally inexpensive noise shaping that can be applied to 8 bit quantised data at more pedestrian sample rates?

What are pedestrian sample rates?

I guess on 28kHz or lower one could try noise shaping into the lower frequency band, like the article on Wikipedia on noise shaping shows. its essentially a low-pass filter and the quantization noise should be shifted to lower frequencies (instead of higher inaudible frequencies as usually) - and part of the noise would go below 20Hz and therefor also be inaudible.

For example, consider the feedback system:
y[n]=x[n]+b* e[n-1]

where b is a constant, n is the cycle number, x[n] is the input sample value, y[n] is the value being quantized, and e[n] is its quantization error:

e[n]=y_quantized[n]-y[n]

https://en.wikipedia.org/wiki/Noise_shaping

if we set b to 0.5 we can use a shift operation and this would not very much onto a normal 16bit to 8bit conversion.

[saimo]

Originally Posted by Gorf

The way the volume reduction works on real hardware (on-off-switching), I would be suspicious about any volume below max

Originally Posted by pandy71

Then your A1200 will be really good audiophile piece - even if Paula in PLCC package has better distributed power supply and ground, then overall PCB layout is very good and there is no ripple from power lines when other system components are active then i would expect figures closer to 70..80dB dynamics and we not even touching Paula DAC's linearity.

Given the above, I repeated the test. The equipment boils down to a simple cable connecting the A1200 RCAs to the PC line in. No gain whatsoever. The waveform is the test tone made of 8 bit samples ranging from -128 to 127 played by sAQA0 at volume 64. Results below (click the pictures to see them in full size).

Overall linear view:


dB view:


Linear view of snippet from the middle of the waveform:



dB view of of snippet from the middle of the waveform:



Measurement with two different tools:



It looks like the range is 1.1144*2 = 2.2288 dB from 120 dB, i.e. 120-2.2288 = 117.7712 dB.
I guess I'm doing something wrong? Remember I'm pretty ignorant

Edit: ah, wait! I know now! I was considering the whole positive-negative range! In absolute, the range is 60-1.1144 = 58.8856 dB. That's it, right?

[Gorf]

Originally Posted by saimo

Given the above, I repeated the test. The equipment boils down to a simple cable connecting the A1200 RCAs to the PC line in. No gain whatsoever. The waveform is the test tone made of 8 bit samples ranging from -128 to 127 played by sAQA0 at volume 64. Results below (click the pictures to see them in full size).

ok -so this is at full volume
how about halve volume or minimum volume - would we see any distortions of the sine wave - probably best seen in spectrum analysis of that part.

Edit: ah, wait! I know now! I was considering the whole positive-negative range! In absolute, the range is 60-1.1144 = 58.8856 dB. That's it, right?

sounds more reasonable

[saimo]

Originally Posted by pandy71

This is not entirely clear (how PWM volume regulation is implemented) but i assume for periods 128 and lower this should be pretty linear and proper volume regulation implementation but for periods smaller than 128 you may expect aliasing products from 3.58MHz/64 and current sampling rate.

Hmmm... I see a problem also with higher periods. For example, let's consider the case of 144 as period and 32 as volume.

If the volume counter resets also for the second sample of a word:
1. a sample starts playing and the volume counter starts from 0;
2. during the first 64 cycles, the volume counter loops once and the sample gets sent to the DAC only during the first 32 cycles (i.e. half of the time);
3. the same repeats in the next 64 cycles;
4. during the next 16 cycles the sample gets sent to the DAC all the time and then...
5. ... the period counter expires, the second sample starts playing, the volume counter restarts from 0...
6. ... and so on.

The resulting on-off pattern is (digits = sample number): 00--00--011--11--122--22--2--...
But, ideally, given that the volume is 32, it should have simply alternated like this: 0-1-2...
Therefore, every time the period expires, there's a volume distortion.

If the volume counter does not reset for the second sample of a word:
1. a sample starts playing and the volume counter starts from 0;
2. during the first 64 cycles, the volume counter loops once and the sample gets sent to the DAC only during the first 32 cycles;
3. the same repeats in the next 64 cycles;
4. during the next 16 cycles the sample gets sent to the DAC all the time and then...
5. ... the period counter expires, the second sample starts playing, the volume counter keeps on counting from 16;
6. during the first 64 cycles, the second sample gets sent to the DAC for 16 cycles (when the volume counter goes from 16 to 31), then the volume counter wraps around after 32 cycles, and the sample gets sent to the DAC for other 16 cycles;
7. the same repeats for the next 64 cycles; 8. in the next 16 cycles the sample gets sent to the DAC and then...
9. ... the period counter expires, the second sample starts playing, the volume counter restarts from 0...10. ... and so on.

The resulting pattern is: 00--00--01--11--12--
There is a phase issue (which is not too bad because I have used multiples of 16, but things are not this smooth with unrelated periods and volumes).

Or is there some magic just before / at the DAC stage that somehow deals with all of this?

(What a pain to make these posts with line breaks not working!)

[pandy71]

Originally Posted by saimo

It looks like the range is 1.1144*2 = 2.2288 dB from 120 dB, i.e. 120-2.2288 = 117.7712 dB.I guess I'm doing something wrong? Remember I'm pretty ignorant Edit: ah, wait! I know now! I was considering the whole positive-negative range! In absolute, the range is 60-1.1144 = 58.8856 dB. That's it, right?

I would do this test (dynamic range) differently generate sinewave (like 1kHz or to use coherent sampling something being even multiple of your sample rate period like for period 128 sine made from 16 points) then start this signal from well defined level as calibration step - for example -6dBS after while just reduce level by 1db in for example 1 seconds steps - observe spectrum analyzer when tone disappear from your spectrogram - this will be your dynamic range (sometimes instead step linear ramp is generated so observing time axis you can easily tell when you not see your tone), SoX is able to produce spectrograms.

[pandy71]

Originally Posted by saimo

Hmmm... I see a problem also with higher periods. For example, let's consider the case of 144 as period and 32 as volume.

It should be averaged over time and if volume adjustment occurs at least twice per sample then everything should be fine.This is job for reconstruction filter.I'm curious how this volume regulation is implemented in Paula - i can imagine various solutions (like feeding to DAC reference voltage from PWM, interrupting analog signal from DAC by switch controlled by PWM or feding data into DAC from some register but data are controlled by PWM - so DAC is switched between register and for example 0 level - all of them seem to be valid).

Originally Posted by saimo

Or is there some magic just before / at the DAC stage that somehow deals with all of this?(What a pain to make these posts with line breaks not working!)

Good question!