More than 4 sound channels - how it works?

[ReadOnlyCat]

Originally Posted by Mrs Beanbag

Watch me call a floating point number an integer!

This thread is home to the boldest propositions!

Originally Posted by Mrs Beanbag

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.

Oki gotcha (thanks for your initial reply btw).
This said, it is close enough for many laykitten to not hear the difference if their ear is not trained.

If that is important, one way to work around it would be to have another sample tuned to a multiple of the unreachable frequencies. Maybe more than one would be needed actually.

[pandy71]

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.

Maybe i misunderstand your point - this topic is quite strange to follow - everyone seem to agree and at the same time everyone disagree.
Math/DSP is quite clear, HW limitations are quite clear, outcome is very simple multichannel audio is possible but with mediocre quality as even 8 bit is beyond current Amiga capabilities (unless you are able to apply noisehaping which is extremely difficult as OCS does support only sub Nyquist NS and to go for higher sampling rate you need to use or ECS/AGA or Copper or CPU and as you can imagine CPU power is insufficient to do this in real time on most Amiga).

Btw as not musician - what kind of frequency is most frequently used as sample rate for samples (to cover usable musical scale)?

[daxb]

Originally Posted by pandy71

Btw as not musician - what kind of frequency is most frequently used as sample rate for samples (to cover usable musical scale)?

Difficult to say. I`ve seen many different sample rates. The lack of memory forced to use lower rates. I would guess that most frequently used was 16kHz (C-3). The first years I recorded with the same value, later 22kHz (F-3) but for more then 3 sec. (64kb limit) I went for the next lower note/rate or just to C-3, F-2, C-2. Although, as said nearly every note/rate was used. Below 8kHz (C-2) could be ignored IMO because seldom used.

[Megol]

Just a quick note, stepping can be done with:

move.b (a0), d0   ; read sample
adda.w (a1)+, a0 ; increment sample pointer according to the (sign extended) stepping table

Which (if my reading of http://oldwww.nvg.ntnu.no/amiga/MC68...000timing.HTML is correct) should take 20 clocks.

add.w a0,d1
addx.l d2,d3
move.b (a2,d3.l),d0
...

Seems to take 26 clocks (but is of course a more general routine and need no pre-computed stepping tables).

And it should be possible to mix 6 channels (3 per L/R output) for a total of 8 channels in less than 260 clocks/update, still a bit slow... 14kHz would take 3.6M clocks to render.

[Mrs Beanbag]

"stepping table" would be huge, especially since it is using 16 bit words to store essentially only 1-bit worth of data

[ReadOnlyCat]

Originally Posted by Megol

And it should be possible to mix 6 channels (3 per L/R output) for a total of 8 channels in less than 260 clocks/update, still a bit slow... 14kHz would take 3.6M clocks to render.

Call me a deluded kangaroo but I still think 260 clocks is an outrageously high number.

I have a hunch that adding frequency or volume constraints would not hurt musicians that much and would allow significant speed-ups. One only needs to hear 2 channels music to get convinced that creativity can overcome constraints. Yes, the constraint is different but the principle stays valid: creative people always find ways around constraints that coders did not think about, that is almost in their DNA.

Regarding the up sampling artifacts mentioned by Meynaf, yup these would be audible but to which point? Has anyone tried? (Yes, I know I should, and probably will eventually.)
I wonder to which extent they can be compensated for by mixing precomputed "correcting" samples for the most used up sampling ratios (possibly as a function of the original waveform too)...

[Megol]

Originally Posted by Mrs Beanbag

"stepping table" would be huge, especially since it is using 16 bit words to store essentially only 1-bit worth of data

The requirement would be: playback_frequency/update_frequency words per , table. E.g. 28kHz/50 = 560 words.

But sure one could compress it, something like this would perhaps work?

move.w (a1)+, d1 ; fetch stepping bitmap
; unrolled 16 times
move.b (a0), d0    ; fetch sample
...                       ; volume lookup, mixing ...
add.w d1, d1        ; set X according to next stepping value
subx.w d2, d2       ; D2 = 0 or -1
suba.w d2, a0       ; step...

Which should be ~16.5 clocks per sample for the stepping (volume lookup & mixing not included).

[Thorham]

Originally Posted by ReadOnlyCat

Regarding the up sampling artifacts mentioned by Meynaf, yup these would be audible but to which point? Has anyone tried? (Yes, I know I should, and probably will eventually.)

Any re-sampling done with things like simple averages will not sound fabulous. This is the reason software like SOX uses such heavy re-sampling algorithms (which sound very good, but are MUCH too heavy for 68k in real time).

That said, simple methods are still good enough depending on the application.

[pandy71]

Downsampling can be performed quite easily - just select samples in regular interval... but or you don't have best quality (as you can use only limited bandwidth to fulfill Nyquist criteria) or you accepting unavoidable aliasing (which is so common in Amiga and some people even like it).
Upsampling is very easy - just repeat sample value but still... no best possible quality...
There is always trade-off on such slow machine...

[Mrs Beanbag]

Originally Posted by Megol

The requirement would be: playback_frequency/update_frequency words per , table. E.g. 28kHz/50 = 560 words.

This is not the case unless all the target frequencies are multiples of 50Hz, otherwise the table would not repeat at that point. In fact, consider the obvious case of any frequencies below 50Hz (which is probably not used in music but illustrates the point).

Originally Posted by pandy71

Downsampling can be performed quite easily - just select samples in regular interval... but or you don't have best quality (as you can use only limited bandwidth to fulfill Nyquist criteria) or you accepting unavoidable aliasing (which is so common in Amiga and some people even like it).
Upsampling is very easy - just repeat sample value but still... no best possible quality...
There is always trade-off on such slow machine...

I believe you have got upsampling and downsampling the wrong way round.

I have used a modified version of Lanczos resampling to good effect, for a 2:1 ratio this is fairly easy and quick. All samples could be doubled or quadrupled in length before the module is played, then interpolation is effectively pre-calculated to some degree, if you are willing to use that much RAM.

[drhex]

Originally Posted by Megol

The requirement would be:

move.w (a1)+, d1 ; fetch stepping bitmap
; unrolled 16 times
move.b (a0), d0    ; fetch sample
...                       ; volume lookup, mixing ...
add.w d1, d1        ; set X according to next stepping value
subx.w d2, d2       ; D2 = 0 or -1
suba.w d2, a0       ; step...

Which should be ~16.5 clocks per sample for the stepping (volume lookup & mixing not included).

That will pack the stepping tables nicely, but has only 1.5 cycle advantage over meynaf's "normal mixing code"

add.w a0,d1      ;a0 = fraction of speed   d1 = current fractional position              
addx.l d2,d3      ;d2 = integer of speed,  d3= index into sample         
move.b (a2,d3.l),d0  ; fetch sample

... which requires no stepping tables and where the stepping speed is not restricted to specific values and can be updated at any time for e.g. portamento effects.

[Megol]

Originally Posted by Mrs Beanbag

This is not the case unless all the target frequencies are multiples of 50Hz, otherwise the table would not repeat at that point. In fact, consider the obvious case of any frequencies below 50Hz (which is probably not used in music but illustrates the point).

Using stepping tables is a real example of integer based scaling - there is no fractional precision per se (though it will mostly behave as having the precision of the table generator). There will be artifacts at the update frequency but those are probably so minor that they can be ignored. Have to try it to see.

[Mrs Beanbag]

Originally Posted by Megol

But sure one could compress it, something like this would perhaps work?

move.w (a1)+, d1 ; fetch stepping bitmap
; unrolled 16 times
move.b (a0), d0    ; fetch sample
...                       ; volume lookup, mixing ...
add.w d1, d1        ; set X according to next stepping value
subx.w d2, d2       ; D2 = 0 or -1
suba.w d2, a0       ; step...

Which should be ~16.5 clocks per sample for the stepping (volume lookup & mixing not included).

Just realised this is pretty much exactly what i suggested in this earlier post in this thread:
http://eab.abime.net/showpost.php?p=...&postcount=130

[Megol]

Originally Posted by drhex

That will pack the stepping tables nicely, but has only 1.5 cycle advantage over meynaf's "normal mixing code"

add.w a0,d1      ;a0 = fraction of speed   d1 = current fractional position              
addx.l d2,d3      ;d2 = integer of speed,  d3= index into sample         
move.b (a2,d3.l),d0  ; fetch sample

... which requires no stepping tables and where the stepping speed is not restricted to specific values and can be updated at any time for e.g. portamento effects.

Exactly!

The non-compressed version is a bit faster but still have the same kinds of limitations. It could be useful for some cases though.

[pandy71]

Originally Posted by Mrs Beanbag

I believe you have got upsampling and downsampling the wrong way round.

I have used a modified version of Lanczos resampling to good effect, for a 2:1 ratio this is fairly easy and quick. All samples could be doubled or quadrupled in length before the module is played, then interpolation is effectively pre-calculated to some degree, if you are willing to use that much RAM.

Nope, sample repetition (upsampling) is plain Zero Order Hold https://en.wikipedia.org/wiki/Zero-order_hold , more correctly you should separate samples with zeroes. Add to this lowpass filter to have proper signal processing - both are valid from spectral perspective.
Upsampling/downsampling is more like address operation than data processing. Decimation is quite similar - apply lowpass filter then select samples - asynchronous sample rate conversion is performed as first upsampling then downsampling.
If you prefilter your data before upsampling/downsampling then lowpass is optional. Interpolation is different topic - there is no optimal approach for this especially in time domain, in frequency domain you may apply spectral band replication with sufficient results.

[Mrs Beanbag]

Originally Posted by pandy71

Nope, sample repetition (upsampling) is plain Zero Order Hold https://en.wikipedia.org/wiki/Zero-order_hold

yet again you seem to be disagreeing with something but i've no idea what, it's like you just ignore what i wrote and respond to something from your own imagination.

but it seems the confusion about which way round are upsampling/downsampling is a problem of Amigaland, Protracker calls shortening the sample "upsampling" (by a factor of 2 in this case) whereas in signals processing land upsampling results in a longer sample. Weird.

Lanczos resampling, btw, IS a low-pass filter.

[pandy71]

Originally Posted by Mrs Beanbag

yet again you seem to be disagreeing with something but i've no idea what, it's like you just ignore what i wrote and respond to something from your own imagination.

but it seems the confusion about which way round are upsampling/downsampling is a problem of Amigaland, Protracker calls shortening the sample "upsampling" (by a factor of 2 in this case) whereas in signals processing land upsampling results in a longer sample. Weird.

Lanczos resampling, btw, IS a low-pass filter.

Lol... It was not me writing this:

Originally Posted by Mrs Beanbag

I believe you have got upsampling and downsampling the wrong way round.

Not sure if i get this correctly (upsampling/downsampling) but seem same understanding was expressed by Lyons and by Proakis multiple time.

http://www.dsprelated.com/showarticle/167.php
http://www.dsprelated.com/showarticle/903.php


Yes - Lanczos is a windowed sinc (windowed by Lanczos window) and as every windowed sinc it introduce own problems.

[Mrs Beanbag]

Originally Posted by pandy71

Lol... It was not me writing this:

ok yes it was i who got them the wrong way round, because as i just explained, apparently Protracker got them the wrong way round. What confused me was you talking about Zero Order Hold and Zero Fill, a distinction nobody mentioned(?)

Yes - Lanczos is a windowed sinc (windowed by Lanczos window) and as every windowed sinc it introduce own problems.

Everything introduces its own problems. Windowed sinc seems not to add up to 1 everywhere when you sum over all the windows (i tried it), so i didn't use exactly a windowed sinc but a function composed of sin and cos that did add up to 1, but it is a pretty good low-pass filter anyway.

[ReadOnlyCat]

Originally Posted by pandy71

Nope, sample repetition (upsampling) is plain Zero Order Hold https://en.wikipedia.org/wiki/Zero-order_hold , more correctly you should separate samples with zeroes. Add to this lowpass filter to have proper signal processing - both are valid from spectral perspective.
Upsampling/downsampling is more like address operation than data processing.

The Wikipedia entry is too dense for me to get into just now but are you implying that replacing samples which would have to be doubled during upsampling by zeroes is enough to avoid spectral distortions?

I.e., instead of going from ABCDEFGH to AABCDEEFGH you'd have 0ABCD0EFGH
Or am I completely misunderstanding you (most likely)?

[pandy71]

Originally Posted by ReadOnlyCat

The Wikipedia entry is too dense for me to get into just now but are you implying that replacing samples which would have to be doubled during upsampling by zeroes is enough to avoid spectral distortions?

I.e., instead of going from ABCDEFGH to AABCDEEFGH you'd have 0ABCD0EFGH
Or am I completely misunderstanding you (most likely)?

ABCDEF > A0B0C0D0E0F0 > (lowpass) > AaBbCcDdEeFf but AABBCCDDEEFF is also valid (albeit spectrum after upsampling will be slightly different http://www.dsprelated.com/showarticle/761.php).

Originally Posted by Mrs Beanbag

ok yes it was i who got them the wrong way round, because as i just explained, apparently Protracker got them the wrong way round. What confused me was you talking about Zero Order Hold and Zero Fill, a distinction nobody mentioned(?)

Software guys don't care too much but it is slightly different in frequency domain - from Amiga perspective both are comparable.

Originally Posted by Mrs Beanbag

Everything introduces its own problems. Windowed sinc seems not to add up to 1 everywhere when you sum over all the windows (i tried it), so i didn't use exactly a windowed sinc but a function composed of sin and cos that did add up to 1, but it is a pretty good low-pass filter anyway.

Problem with sinc is that it is suboptimal from human perception perspective as it introduce ringing.