More than 4 sound channels - how it works?

[drhex]

Originally Posted by meynaf

As you see, nothing like a simple 0.8 ratio.

That ratio was chosen to explain the principle with a minimum of code.

Originally Posted by meynaf

What will your mixing code look like for e.g. two notes played at a period of $358 for one and $328 for the other ?

They relate to each other as 107 to 101, so 107 mixings needed. 3 instructions à 2 bytes each, so ca 600 bytes. Say 1 kb each and 80 routines then. Surely we can spare 80k.

Originally Posted by meynaf

Last question : is a 8ch effectless music taking lots of cpu and huge memory buffers any better than a 4ch music using full set of fx and taking only a small memory footprint with virtually no cpu time ?

In a thread called "More than 4 sound channels - how it works", I'd say the answer is yes.

[meynaf]

Originally Posted by drhex

That ratio was chosen to explain the principle with a minimum of code.

Of course but it's quite irrealistic.

Originally Posted by drhex

They relate to each other as 107 to 101, so 107 mixings needed. 3 instructions à 2 bytes each, so ca 600 bytes. Say 1 kb each and 80 routines then. Surely we can spare 80k.

If you have only 512k for your game it's not sure you can spare 80k.

But let's admit we have them. Now do you think the music (or whatever's gonna be played) will gently not change its pitch for durations that are always multiple of 107 and 101 samples ?

The number of samples to be played if using some timing like the vbl is also apparently required to be a multiple of this size and obviously it won't. 16khz (higher than what this mixing code will handle) is just 320 samples per vbl. So with lower frequencies you're in the range of these 101 or 107 samples. If you have 107 to do but the intended duration is 150, what will you do ?

Originally Posted by drhex

In a thread called "More than 4 sound channels - how it works", I'd say the answer is yes.

But it's about "how it works". Not about "how it could eventually have worked in pure theory". Also not about "building castles in the air about how audio mixing could be done"

This seems to be purely theoretical and has no practical use at all.
So i don't see the point. I want things that have some use in the real world. Normal mixing has some. This one has none.

[drhex]

Originally Posted by meynaf

Now do you think the music (or whatever's gonna be played) will gently not change its pitch for durations that are always multiple of 107 and 101 samples ?

Well, how about not starting the loop at the first instruction, but entering it at 6*(the number of output bytes to skip), so it will generate fewer bytes on the first iteration? Then, one can control the number of generated bytes precisely.

[meynaf]

Originally Posted by drhex

Well, how about not starting the loop at the first instruction, but entering it at 6*(the number of output bytes to skip), so it will generate fewer bytes on the first iteration? Then, one can control the number of generated bytes precisely.

So what's missing now is only someone to actually write the code, huh ?

[Megol]

Originally Posted by meynaf

So what's missing now is only someone to actually write the code, huh ?

Why don't you? Given that it is you that think this thread is about posting code optimized for 68000 only while all others seem to think it is (now) about discussing efficient mixing in general...

And to answer your question to me in an earlier post: 1) I don't have the source codes to any mixing routine* 2) I mostly coded mixing routines for PC optimized for 16+ channels on 80486 and low end 16 bit systems 3) as my code wasn't optimized for a 68000 it is surely irrelevant (even though the concepts and optimizations could be ported to 68000)?

(* Nor for other pre-2000 developments, partially because I was stupid and deleted stuff and partially because of a crash of a system with no backup. Guess that was me being stupid in that case too)

[Megol]

Originally Posted by drhex

Well, how about not starting the loop at the first instruction, but entering it at 6*(the number of output bytes to skip), so it will generate fewer bytes on the first iteration? Then, one can control the number of generated bytes precisely.

Of course and that it a technique used often with generated code. But we are discussing with somebody that seem to think things he hasn't used or heard of is not practical...

[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?

[Mrs Beanbag]

Originally Posted by Megol

Why don't you? Given that it is you that think this thread is about posting code optimized for 68000 only while all others seem to think it is (now) about discussing efficient mixing in general...

well i started this thread so i guess i get the casting vote.

It was originally about how existing implementations work, but since we've pretty much exhausted that, it's fine to talk about improvements or alternatives, and i don't mind if it's for unexpanded A500, A1200, or Amigas with fast RAM or accelerators. As long as it's for 680x0 and our humble four-channel Paula.

It's ok whether you've actually written something or just have an idea. But it is not ok to do petty squabbling and name calling.

Right.

As far as fixed ratios go, musical notes in the Western scale are not in whole number ratios. Hundreds of years ago people used to tune instruments like that, which can sound quite odd to modern ears, now we are used to "twelve tone equal temperament", or 12TET, that renders all the different keys sounding the same. When Johann Sebastian Bach composed The Well-Tempered Clavier, he had in mind an instrument tuned a particular way (Well Temperament) that made each key have a different character. A lot of musical intervals are still customarily described in terms of simple ratios (a pure fifth, for instance, is a 3:2 ratio) but real instruments are no longer tuned that way.

Equal Temperament notes are defined such that every semitone is exactly the same interval, such that each note is calculated by 2^(n/12). This yields a fifth that is very close to pure, but is very slightly off: 2^(7/12) = 1.49830708...

Of course, neither simple ratios nor equal temperament are exactly possible to reproduce on the Amiga anyway.

[meynaf]

Originally Posted by Megol

Why don't you?

Because i'm pretty sure it wouldn't work ?

Originally Posted by Megol

Given that it is you that think this thread is about posting code optimized for 68000 only while all others seem to think it is (now) about discussing efficient mixing in general...

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.

Originally Posted by Megol

And to answer your question to me in an earlier post: 1) I don't have the source codes to any mixing routine* 2) I mostly coded mixing routines for PC optimized for 16+ channels on 80486 and low end 16 bit systems 3) as my code wasn't optimized for a 68000 it is surely irrelevant (even though the concepts and optimizations could be ported to 68000)?

(* Nor for other pre-2000 developments, partially because I was stupid and deleted stuff and partially because of a crash of a system with no backup. Guess that was me being stupid in that case too)

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

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

Originally Posted by Megol

Of course and that it a technique used often with generated code.

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

Originally Posted by Megol

But we are discussing with somebody that seem to think things he hasn't used or heard of is not practical...

Where's the sense in that ?

[Mrs Beanbag]

Originally Posted by meynaf

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

A3 and A5 are presumably the volume multiplication tables... but why are there two of them?

[meynaf]

Originally Posted by Mrs Beanbag

A3 and A5 are presumably the volume multiplication tables... but why are there two of them?

Because the two channels can have a different volume.

[Mrs Beanbag]

Originally Posted by meynaf

Because the two channels can have a different volume.

oh, i thought the upper byte of D0/D4 took care of that already.

Edit: and speaking of volume tables, we really only need to adjust the volume of one channel, because we could set the physical volume of the audio channel to whichever is the louder of the two and then only multiply the other one.

[drhex]

Cool that roxr.b #1,d0 seems to work for halfing the sum whether we're dealing with signed or unsigned values, when one normally has to pick either logic or arithmetic shift.

[drhex]

Originally Posted by Mrs Beanbag

Edit: and speaking of volume tables, we really only need to adjust the volume of one channel, because we could set the physical volume of the audio channel to whichever is the louder of the two and then only multiply the other one.

I'm sure meynaf will now complain that doing so will lead to problems with executing that volume change at the right moment.

[ReadOnlyCat]

Originally Posted by Mrs Beanbag

Of course, neither simple ratios nor equal temperament are exactly possible to reproduce on the Amiga anyway.

I am under the impression that the Nyquist–Shannon theorem says otherwise and that as long as your sample frequency is more than twice higher than the frequency of the note you are playing then the generated signal exhibits that note's frequency even if the samples are not played exactly in sync with it.

This said I might be wrong but I have a hunch that Pandy71 knows more about this than I do and can correct me if needed.

[meynaf]

Originally Posted by Mrs Beanbag

oh, i thought the upper byte of D0/D4 took care of that already.

It could, if we lack address registers (which doesn't appear to be the case).

Originally Posted by Mrs Beanbag

Edit: and speaking of volume tables, we really only need to adjust the volume of one channel, because we could set the physical volume of the audio channel to whichever is the louder of the two and then only multiply the other one.

Dangerous, as Drhex guessed

Anyway, this defeats the signed to unsigned conversion in the volume table and therefore involves sample conversion at startup.

Originally Posted by drhex

Cool that roxr.b #1,d0 seems to work for halfing the sum whether we're dealing with signed or unsigned values, when one normally has to pick either logic or arithmetic shift.

Alas, nope. It works only for unsigned values.
If we mix two signed values being $E0 and $00, the normal signed result should be $F0 for the average. But we would get $70 instead...

So, even though the volume table can include the conversion for the input, some other code has to convert the output back to signed (or we add some eori.b #$80,d0 after the roxr).

Originally Posted by drhex

I'm sure meynaf will now complain that doing so will lead to problems with executing that volume change at the right moment.

Not a problem, if you like sample triggering clicks

[Mrs Beanbag]

Originally Posted by meynaf

It could, if we lack address registers (which doesn't appear to be the case).

But there is no cost in it so why not do it anyway? In fact there is a small saving, because we don't need to offset the table pointers, and the initial value of D0/D4 is already calculated anyway and we don't need to clear it.

Originally Posted by ReadOnlyCat

I am under the impression that the Nyquist–Shannon theorem says otherwise and that as long as your sample frequency is more than twice higher than the frequency of the note you are playing then the generated signal exhibits that note's frequency even if the samples are not played exactly in sync with it.

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.

Edit: yes it is possible to do the following octave in Just Intonation:
C: 360
D: 320 (9:8)
E: 288 (5:4)
F: 270 (4:3)
G: 240 (3:2)
A: 216 (5:3)
B: 192 (15:8)
C: 180 (2:1)

360 is not a C on the Amiga though, it is more like a D#

The first semitone lies on 337.5, however... so best stick to the white notes

[meynaf]

Originally Posted by Mrs Beanbag

But there is no cost in it so why not do it anyway? In fact there is a small saving, because we don't need to offset the table pointers, and the initial value of D0/D4 is already calculated anyway and we don't need to clear it.

Indeed ; it's just that i found it pretty much unimportant.

[NorthWay]

So mixing two channels then both channels are stretched to a fixed frequency?

Would the sound be shyte if you used the frequency of the channel with the highest frequency, stretched only the lower freq channel to match it, and then mixed them? (Saving cycles on stretching one channel.)

[ReadOnlyCat]

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.

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