More than 4 sound channels - how it works?

[pandy71]

Originally Posted by Mrs Beanbag

I'm not talking about the frequencies that it is possible to reproduce in a sample, which can be anything. But rather, the Amiga's sound hardware can only play notes at ratios of integers, because the period value is an integer, and the above resampling code also specifies the frequency as an integer, so neither can reproduce frequencies that are not ratios of integers, which is the case for equal temperament. The 6-semitone interval, for instance, is the square root of 2, quite famously an irrational number.

It is possible for the Amiga to reproduce all of the classical ratio intervals individually, but it would not be easy to do them all at the same time, although thinking about it, it might work if starting with a base period of 360, which is highly composite.

With sufficiently fast CPU and I/O (maybe clever Copper?) in theory you may be able to receive finer frequency resolution by using similar approach as fractional dividers https://en.wikipedia.org/wiki/Freque...nal-n_dividers but this is not feasible IMHO on normal Amiga due bandwidth limitations (CPU) - incorrectly implemented im almost sure it will introduce jitter https://en.wikipedia.org/wiki/Jitter

But i see no need for this as sampled data require only accurate clock - you can perfectly represent sine 997Hz or sine 1001Hz on Amiga.
Of course there are some tricks in DSP to speed up some things (in sample rate conversion common is CIC https://en.wikipedia.org/wiki/Cascad...%93comb_filter that doesn't require mutiplication) but still Amiga CPU and Amiga architecture are not capable to perform such thing - this can be made by switching whole Amiga idea to FPGA but this will not happen soon...

[Mrs Beanbag]

Originally Posted by ReadOnlyCat

What do you mean by "at the same time"?

To give an example, if you decide to use the period 216 for the note C, you can get various integer ratios out of that. For instance D=192 (9:8), F=162 (4:3), G=144 ( 3:2), but you can't get E (5:4), A (5:3) or B (15:8) because 216 is not divisible by 5 or 15.

So suppose you choose 215 instead, which is divisible by 5, so you can get E=172 and A=129, but still not B, and worse, you can no longer get D, F, or G, because 215 is not divisible by 8, 3 or 2.

(Usually in Amiga period tables, C has a period of 214, which is even worse, because it only has two factors, 2 and 107, and the only ratio that gets you is the octave, but it's too high a note for Paula to play.)

Originally Posted by pandy71

But i see no need for this as sampled data require only accurate clock - you can perfectly represent sine 997Hz or sine 1001Hz on Amiga.

So what values of the period and loop length would you use for this? Because the formula i have for calculating period are
PAL: 3546895 / (frequency * length)
NTSC: 3579545 / (frequency * length)

These don't have very many prime factors:
3546895 = 5 x 11 x 64489
3579545 = 2 x 3 x 41 x 14551
1001 = 7 x 11 x 13
and 997 is prime...

so neither of these frequencies is exactly possible with any combination of period and length, either on NTSC or PAL.

[pandy71]

Originally Posted by Mrs Beanbag

So what values of the period and loop length would you use for this? Because the formula i have for calculating period are
PAL: 3546895 / (frequency * length)
NTSC: 3579545 / (frequency * length)

These don't have very many prime factors:
3546895 = 5 x 11 x 64489
3579545 = 2 x 3 x 41 x 14551
1001 = 7 x 11 x 13
and 997 is prime...

so neither of these frequencies is exactly possible with any combination of period and length, either on NTSC or PAL.

Seem there is some confusion here - allow me to paste some numbers:

0078    120    29557.458333    29829.541667    14778.729167    14914.770833
0079    121    29313.181818    29583.016529    14656.590909    14791.508264
007A    122    29072.909836    29340.532787    14536.454918    14670.266393
007B    123    28836.544715    29101.991870    14418.272358    14550.995935
007C    124    28603.991935    28867.298387    14301.995968    14433.649194
007D    125    28375.160000    28636.360000    14187.580000    14318.180000
007E    126    28149.960317    28409.087302    14074.980159    14204.543651
007F    127    27928.307087    28185.393701    13964.153543    14092.696850
0080    128    27710.117188    27965.195313    13855.058594    13982.597656
0081    129    27495.310078    27748.410853    13747.655039    13874.205426
0082    130    27283.807692    27534.961538    13641.903846    13767.480769
0083    131    27075.534351    27324.770992    13537.767176    13662.385496
0084    132    26870.416667    27117.765152    13435.208333    13558.882576
0085    133    26668.383459    26913.872180    13334.191729    13456.936090
0086    134    26469.365672    26713.022388    13234.682836    13356.511194
0087    135    26273.296296    26515.148148    13136.648148    13257.574074
0088    136    26080.110294    26320.183824    13040.055147    13160.091912
0089    137    25889.744526    26128.065693    12944.872263    13064.032847
008A    138    25702.137681    25938.731884    12851.068841    12969.365942
008B    139    25517.230216    25752.122302    12758.615108    12876.061151
008C    140    25334.964286    25568.178571    12667.482143    12784.089286
008D    141    25155.283688    25386.843972    12577.641844    12693.421986
008E    142    24978.133803    25208.063380    12489.066901    12604.031690
008F    143    24803.461538    25031.783217    12401.730769    12515.891608
0090    144    24631.215278    24857.951389    12315.607639    12428.975694
0091    145    24461.344828    24686.517241    12230.672414    12343.258621
0092    146    24293.801370    24517.431507    12146.900685    12258.715753
0093    147    24128.537415    24350.646259    12064.268707    12175.323129
0094    148    23965.506757    24186.114865    11982.753378    12093.057432
0095    149    23804.664430    24023.791946    11902.332215    12011.895973
0096    150    23645.966667    23863.633333    11822.983333    11931.816667
0097    151    23489.370861    23705.596026    11744.685430    11852.798013
0098    152    23334.835526    23549.638158    11667.417763    11774.819079
0099    153    23182.320261    23395.718954    11591.160131    11697.859477
009A    154    23031.785714    23243.798701    11515.892857    11621.899351
009B    155    22883.193548    23093.838710    11441.596774    11546.919355
009C    156    22736.506410    22945.801282    11368.253205    11472.900641
009D    157    22591.687898    22799.649682    11295.843949    11399.824841
009E    158    22448.702532    22655.348101    11224.351266    11327.674051
009F    159    22307.515723    22512.861635    11153.757862    11256.430818
00A0    160    22168.093750    22372.156250    11084.046875    11186.078125
00A1    161    22030.403727    22233.198758    11015.201863    11116.599379
00A2    162    21894.413580    22095.956790    10947.206790    11047.978395
00A3    163    21760.092025    21960.398773    10880.046012    10980.199387

This is example for frequencies you can reproduce with Paula, first column hexadecimal period in AUDxPER, second decimal AUDxPER, third column sample rate for PAL system, next column sample rate for NTSC, next two columns are maximum usable (Nyquist) frequency correspondingly for PAL and for NTSC.

If you sample sine 997Hz with for example 28603.991935Hz sample rate then this sine will be 997Hz during replaying it with sample rate 28603.991935Hz - there can be any frequency between DC and 14301.995968Hz - this is simple, on other way when you replaying sine with sample rate different than sampling rate then sine frequency will be shifted by ratio between sampling rate and playback rate.

Your remark was related to accuracy or rather frequency resolution for set-able play-out rate of Paula. As Paula is equipped with very simple frequency generator then delta between two nearest values depend from period value (higher period value i.e. lower sampling rate mean higher frequency resolution) and usually is lower than +-122Hz (approx).
In theory at a cost of jitter you may introduce finer frequency resolution - not sure how it can sounds (i assume it can be described by Bessel function).
This can be verified by hooking to Amiga audio output a PC audio card input and record signal (and perform on sampled signal spectral analysis).
Anyway by switching AUDxPER value for every sample (in Amiga case sample pair i assume will be easier as Copper can be used or CPU) a finer frequency resolution can be reached (this assumption is fair if we have sufficient time).
Alternatively maybe HW Paula capabilities can be used (4 byte period table and use one channel to modulate second but this reduce speed by half ).

I assume improved Paula may use NCO http://en.wikipedia.org/wiki/Numeric...led_oscillator instead simple divider and as such significantly higher frequency resolution can be reached (also constant delta limited only by Phase Accumulator accuracy - usually fraction of Hz) - compatibility can be achieved by using LUT (when classical AUDxPER access is used).

[drhex]

The accuracy of human ears to perceive frequencies is about 5 cents, according to wikipedia,
which means that a period change from 346 to 347 should be just barely noticable.

[Mrs Beanbag]

Originally Posted by pandy71

If you sample sine 997Hz with for example 28603.991935Hz sample rate then this sine will be 997Hz during replaying it with sample rate 28603.991935Hz ... Your remark was related to accuracy or rather frequency resolution for set-able play-out rate of Paula.

Yes, very well, but the context is about using Paula or integer-based software resampling to play music modules. Of course any frequency is possible if you are just to record it and play it back but that is not what this thread is about. A tune is made by taking a single sample and playing it back at different rates. If those rates are represented by integers (either as pediod in Paula, or frequency as in software addx method) then notes must be approximated to the nearest integer and neither Just Intonation nor Equal Temperament are reproducible exactly.

But this is of course an academic argument because no normal person will hear the difference. Although someone very pedantic might want to take it into account when writing an emulator.

Although it is possible to hear a difference in quality between the same chord in different tuning systems. And it is not for nothing that so many different systems exist!

[Megol]

Originally Posted by drhex

Megol, in an earlier post you wrote Reduce the number of sample frequencies + use generated code for changing pitch. Did that refer to something like the dedicated-routines-per-ratio I've tried to describe or something else?

Well that was a general comment about optimizing but yes, your method is a variant of that. Another variant would be using a common mixing buffer and then have n routines for n different pitches.
I don't know if it would be practical for something like a fully compatible module player but for e.g. sound effects and/or music with some limitations it is obviously usable.

[Megol]

Originally Posted by meynaf

Of course it's for 68000 only. On anything faster you do not need to sacrifice quality - and it's really everything that's discussed here for quite a while !
But i already said that. Sometimes people just don't read.

AGAIN: many of the optimization methods I listed doesn't reduce quality. And AGAIN: optimization is done to do things faster, not only to make them possible.

So no code to show.
But writing some more code "from scratch" isn't difficult.

Of course, but that wasn't what you asked for?

Normal 8-bit mixing code looks like this :

 add.w a0,d1
 addx.l d2,d3
 move.b (a2,d3.l),d0
 move.b (a3,d0.w),d0
 add.w a1,d5
 addx.l d6,d7
 move.b (a4,d7.l),d4
 add.b (a5,d4.w),d0
 roxr.b #1,d0
 move.b d0,(a6)+

Now you can't tell i've shown no code

I'll note that producing a routine using generated code is much more complex, at least if one haven't got a framework ready to use.
But just so that you can't claim I'm only talking how about something a bit different:

; unrolled loop
...
move.b (a0, d0.w), d1 ; fetch sample
move.w (a1)+, d0       ; fetch next offset from table 
move.w (a2, d1.w), d2 ; apply volume ...
add.w d2, (a3)+          ; mix into buffer

And doesn't work well here but that's another story.

Why wouldn't it for the problem at hand?

I get the impression we are somehow talking past each other...

[drhex]

Originally Posted by Megol

; unrolled loop
...
move.b (a0, d0.w), d1 ; fetch sample
move.w (a1)+, d0       ; fetch next offset from table 
move.w (a2, d1.w), d2 ; apply volume ...
add.w d2, (a3)+          ; mix into buffer

Am I missing something basic here, or shouldn't those two last instructions operate on bytes instead of words?

[meynaf]

Originally Posted by Megol

AGAIN: many of the optimization methods I listed doesn't reduce quality. And AGAIN: optimization is done to do things faster, not only to make them possible.

I'm sorry i have to tell you that only using a small set of possible frequencies IS reducing the quality - as you're asking the musicians for some additionnal constraints.

About doing things faster, has the gain been quantified ?

Originally Posted by Megol

Of course, but that wasn't what you asked for?

I asked Drhex to produce code because this is the best way to see if something can work or not.
I posted code so that we have some reference to compare with.
Now what ?

Originally Posted by Megol

I'll note that producing a routine using generated code is much more complex, at least if one haven't got a framework ready to use.
But just so that you can't claim I'm only talking how about something a bit different:

; unrolled loop
...
move.b (a0, d0.w), d1 ; fetch sample
move.w (a1)+, d0       ; fetch next offset from table 
move.w (a2, d1.w), d2 ; apply volume ...
add.w d2, (a3)+          ; mix into buffer

Yes, this is a way 8-to-16 bit mixing can be done. Even though your move.w (a1)+,d0 might have the same timing as add+addx (8 vs 4+4 clocks)...

Originally Posted by Megol

Why wouldn't it for the problem at hand?

Because there is actually no problem at hand. Mixing for the mere sake of mixing is useless ; we should be doing that for a specific application. Usually the best optimizations take into account for which application we're doing the stuff...
For games the classical 3mus+1sfx (or 2mus+2sfx, some games do this) are the best bet. Mixed music (like tfmx 7v) are for menus. SFX are usually of a single period, btw.
For a music player targeting formats like protracker, no trick will do : we need to have the ability to mix anything.
So i still fail to see any application that can use this frequency limitation trick.
Maybe here the talk is purely academic, but in that case i'll just leave because that doesn't interest me.

Originally Posted by Megol

I get the impression we are somehow talking past each other...

That's very possible.

[meynaf]

Originally Posted by drhex

Am I missing something basic here, or shouldn't those two last instructions operate on bytes instead of words?

Here this is 8 bit data as input and 16 bit data as output.

[drhex]

Originally Posted by meynaf

Here this is 8 bit data as input and 16 bit data as output.

7 to 16 bit then, as the "apply volume" line will invite the Guru if d1 contains an odd value.

[meynaf]

Originally Posted by drhex

7 to 16 bit then, as the "apply volume" line will invite the Guru if d1 contains an odd value.

Not sure it was really the intent to use 7 bit input

One could multiply d1 by 2 before the access. On 68000 this kinda sucks.
On 020+ we can write move.w (a2,d1.w*2),d2 instead.

[drhex]

Originally Posted by meynaf

On 68000 this kinda sucks

Getting a little off topic here, but I just thought of a way to make that lookup suck a little less on 68000. To fix the code you'd need a moveq #0,d1 at the beginning to clear out the overflow from the previous doubling, and an add.w d1,d1 to fix the index.

Let's say the loop is unrolled 4 times. Then, one could have the moveq in only the first copy, and compensate by having 8 copies of the lookuptable at consecutive adresses.

Always fun to trade ram for speed

[pandy71]

Originally Posted by Mrs Beanbag

Yes, very well, but the context is about using Paula or integer-based software resampling to play music modules. Of course any frequency is possible if you are just to record it and play it back but that is not what this thread is about. A tune is made by taking a single sample and playing it back at different rates. If those rates are represented by integers (either as pediod in Paula, or frequency as in software addx method) then notes must be approximated to the nearest integer and neither Just Intonation nor Equal Temperament are reproducible exactly.

But this is of course an academic argument because no normal person will hear the difference. Although someone very pedantic might want to take it into account when writing an emulator.

Although it is possible to hear a difference in quality between the same chord in different tuning systems. And it is not for nothing that so many different systems exist!

Once again - you don't need to sample real signal with accurate frequency linked to some music notations...(clear example is 44100Hz sample rate from CD - this is directly related to video signal not to any musical scale) - piano signal C1 sampled at Amiga C1 (samplerate need to fulfill Whittaker–Nyquist–Kotelnikov–Shannon) and played back with Amiga C1 will have correct timbre like piano and it can be related to any musical scale - problem is how accurate is relation between particular Amiga notations but i assume this can be slightly overworked by preparing samples before using it on Amiga in a way to minimized such error - to simplify - absolute frequency accuracy is not important and relative frequency relation is well know and can be slightly workaround-ed if there is not accurate enough.

From my observations it quite clear that people ignore this Amiga uniqueness and they try to use for example samples from different audio hw with bad sample rates - classical example is 22050Hz i.e. half of the 44100Hz - perfectly working in PC world but completely wrong in Amiga world where 22050Hz can't be correctly set and you must use 22030.403727Hz so sample rate conversion must be integral part for using PC sample on Amiga.

[Mrs Beanbag]

Originally Posted by pandy71

Once again - you don't need to sample real signal with accurate frequency linked to some music notations...

I never said that you did, i don't know why you keep pointing this out.

It is not the absolute frequency of a note that matters, only the ratio between the different notes that you want your playroutine to be able to reproduce. Unless you want a different sample for each note on the scale, you will have to be content with an approximation because Paula's period register is an integer value, and all software resampling code mentioned so far also uses an integer value. In fact irrational ratios such as square root of two is impossible on any computer ever, because it has infinite number of digits and can never be computed exactly in the lifetime of the universe.

[Megol]

Originally Posted by drhex

7 to 16 bit then, as the "apply volume" line will invite the Guru if d1 contains an odd value.

Doh!
Well one can use the same technique for 8 bit mixing instead and avoid that :/ Or mixing 3 channels at a time to lower the lookup overheads. Doing a 8bit lookup and a 16bit add is of course possible too but then the whole idea of keeping the mixing buffer at a higher precision makes no sense.

[Megol]

Originally Posted by Mrs Beanbag

I never said that you did, i don't know why you keep pointing this out.

It is not the absolute frequency of a note that matters, only the ratio between the different notes that you want your playroutine to be able to reproduce. Unless you want a different sample for each note on the scale, you will have to be content with an approximation because Paula's period register is an integer value, and all software resampling code mentioned so far also uses an integer value. In fact irrational ratios such as square root of two is impossible on any computer ever, because it has infinite number of digits and can never be computed exactly in the lifetime of the universe.

I wouldn't call a fixed point number an integer. Yes there are fundamental limits in this universe but are those relevant?

[Mrs Beanbag]

Originally Posted by Megol

I wouldn't call a fixed point number an integer.

Watch me call a floating point number an integer! A fixed point number is only non-integer on a semantic technicality... there is no actual point in the hardware or the asm. It's just integer arithmetic but shifted. But... the point is, that any integer, fixed point, or floating point number of finite precision, can only approximate irrational numbers, or most rational numbers.

Yes there are fundamental limits in this universe but are those relevant?

It's relevant to the point i was making... which was merely that you cannot exactly reproduce Just Intonation or Equal Temperament or most other tuning systems, using either direct Paula playback or any software method thus far described. I don't know why this has caused so much confusion. It's not a very important point but it seems to keep getting missed.

[Megol]

Originally Posted by Mrs Beanbag

Watch me call a floating point number an integer! A fixed point number is only non-integer on a semantic technicality... there is no actual point in the hardware or the asm. It's just integer arithmetic but shifted. But... the point is, that any integer, fixed point, or floating point number of finite precision, can only approximate irrational numbers, or most rational numbers.

Integers for me are whole numbers, fixed point is an approximation of real numbers just as floating point is one.

It's relevant to the point i was making... which was merely that you cannot exactly reproduce Just Intonation or Equal Temperament or most other tuning systems, using either direct Paula playback or any software method thus far described. I don't know why this has caused so much confusion. It's not a very important point but it seems to keep getting missed.

I actually think I understand your point - it's just that I don't think it relevant. No one can't get a mathematically perfect scaling for all ratios, but is there actually a real world case where it is a problem as in being detectable? I don't think so.

[Mrs Beanbag]

Originally Posted by Megol

Integers for me are whole numbers, fixed point is an approximation of real numbers just as floating point is one.

"Fixed-point arithmetic" is really a programming technique or trick to get non-integer arithmetic using only integer registers and operations. But it doesn't matter.

I actually think I understand your point - it's just that I don't think it relevant. No one can't get a mathematically perfect scaling for all ratios, but is there actually a real world case where it is a problem as in being detectable? I don't think so.

honestly i don't even remember why i brought it up now, and can't be bothered to re-read the thread to find out.