More than 4 sound channels - how it works?

[drhex]

You're right that the handtuned version would be much more complex to handle. But it should be doable. The idea was to go "all in" for speed. The various routines could be auto-generated from code based on an analysis of what the song to be played needs.

Originally Posted by meynaf

You're also taking the risk of having sound distortion. If you change the replay freq, you have to do it exactly at the same time you start the new buffer. So you're dependent on cpu speed and dma speed.

Ok, but wouldn't the general version have that problem as well?

[meynaf]

Originally Posted by drhex

You're right that the handtuned version would be much more complex to handle. But it should be doable. The idea was to go "all in" for speed. The various routines could be auto-generated from code based on an analysis of what the song to be played needs.

If it should be doable, just do it. Else for me it'll remain a simple, nice, wrong theory.

Originally Posted by drhex

Ok, but wouldn't the general version have that problem as well?

Not with normal mixing code, no.

[drhex]

Originally Posted by meynaf

Not with normal mixing code, no.

Well, unless you want to waste cpu cycles by advancing at fractional rates for both virtual voices, you need to change the hardware playback frequency every now and then, even with normal mixing code.

An interrupt is generated when a prepared and latched buffer starts playing, so I suppose it would be ok to change hardware frequency when that interrupt occurs. If the code keeps track of what's in the buffer that is due to be played next, and starts a new buffer everytime there's a switch from one note to the next, then frequency changes should be in sync with the sample data.
I don't see why such a strategy whouldn't work for audio data mixed by handtuned code sections as well. I am assuming then, that those are written so that they can generate a given number of output bytes (not just a multiple of what the inner loop generates)

[meynaf]

Originally Posted by drhex

Well, unless you want to waste cpu cycles by advancing at fractional rates for both virtual voices, you need to change the hardware playback frequency every now and then, even with normal mixing code.

Of course there is an add/addx pair for each voice. So no playback frequency change - which wouldn't be good for quality anyway, f.e. playing 5khz at 6khz probably gives ugly results.

Originally Posted by drhex

An interrupt is generated when a prepared and latched buffer starts playing, so I suppose it would be ok to change hardware frequency when that interrupt occurs.

If your interrupt gets delayed for whatever reason, a few samples may eventually be played at the wrong freq. Same if the interrupt occurs when samples have been fetched by the dma but have not been output yet.

Taking as granted that the audio interrupt will come at exactly the right time, is usually a big mistake.

Originally Posted by drhex

If the code keeps track of what's in the buffer that is due to be played next, and starts a new buffer everytime there's a switch from one note to the next, then frequency changes should be in sync with the sample data.
I don't see why such a strategy whouldn't work for audio data mixed by handtuned code sections as well. I am assuming then, that those are written so that they can generate a given number of output bytes (not just a multiple of what the inner loop generates)

Again, that's just theory. Why not writing the code instead of talking ?
The only way you can prove me that it can work is by actually doing it.

[ReadOnlyCat]

Originally Posted by meynaf

Again, that's just theory. Why not writing the code instead of talking ?
The only way you can prove me that it can work is by actually doing it.

Having a different opinion about a problem does not mean trying to prove you wrong. That is a surprising angle on an otherwise completely theoretical discussion.

Having an interest in the topic does not imply code must follow.

Imagine we are all around a few beers in a pub. No computers, no coding possible, just figuring out what could be done and nothing else.

[drhex]

Originally Posted by meynaf

Of course there is an add/addx pair for each voice.

Aha! Well, then I understand why hardware frequency playback changes will not be an issue.

The trick of sequencing a suitable number of reads from (a1)+ or (a1) (or alternatively inserting extra addq #1,a1 once in a while) can of course be applied to a0 (the other virtual voice) as well, so that a constant hardware playback rate can be used, if one is worried about interrupts that rank higher than audio.

[meynaf]

Originally Posted by ReadOnlyCat

Having a different opinion about a problem does not mean trying to prove you wrong. That is a surprising angle on an otherwise completely theoretical discussion.

I'm tired about completely theoretical discussions. That's talk, talk, and talk again, without producing anything useful.

Originally Posted by ReadOnlyCat

Having an interest in the topic does not imply code must follow.

There it's not just "having an interest".

Originally Posted by ReadOnlyCat

Imagine we are all around a few beers in a pub. No computers, no coding possible, just figuring out what could be done and nothing else.

What's imagined under this kind of circumstances usually doesn't work

Originally Posted by drhex

The trick of sequencing a suitable number of reads from (a1)+ or (a1) (or alternatively inserting extra addq #1,a1 once in a while) can of course be applied to a0 (the other virtual voice) as well, so that a constant hardware playback rate can be used, if one is worried about interrupts that rank higher than audio.

Can you imagine the number of combinations this would give, even for a very limited frequency choice ?

[ReadOnlyCat]

Originally Posted by meynaf

I'm tired about completely theoretical discussions. That's talk, talk, and talk again, without producing anything useful.

Well, that is your angle then, but why should it be ours? I did not sign any coding obligation when posting my first message on this thread.

Also, this is a generalization, I see plenty of people coding on the EAB.

Originally Posted by meynaf

What's imagined under this kind of circumstances usually doesn't work

True enough.
Waiter! Swap these beers with lemonade please!

[meynaf]

Originally Posted by ReadOnlyCat

Well, that is your angle then, but why should it be ours? I did not sign any coding obligation when posting my first message on this thread.

Perhaps you did not sign any coding obligation, but then, you shouldn't be doing anything in the "Coders" sub-forum

So either this thread gets moved elsewhere, or it remains about coding and not pure theory.

[Mrs Beanbag]

how about...

on loading the mod, we downsample all the samples and interpolate them.

Resampling on the fly could be achieved with look-up tables, and 32 bit masks. We have something like this:

; first get A0 and D3 from a look up table based on the note to play
  move.l (A0)+,D0
  moveq.l #31,D1
.loop
  lsl.l D0
  addx.w D3,D2
  move.b (A1,D2),D7
  add.b D7,(A6)+
  dbra D1,.loop

[meynaf]

Originally Posted by Mrs Beanbag

how about...

on loading the mod, we downsample all the samples and interpolate them.

Resampling on the fly could be achieved with look-up tables, and 32 bit masks. We have something like this:

; first get A0 and D3 from a look up table based on the note to play
  move.l (A0)+,D0
  moveq.l #31,D1
.loop
  lsl.l D0
  addx.w D3,D2
  move.b (A1,D2),D7
  add.b D7,(A6)+
  dbra D1,.loop

That's the same timing as regular add+addx, isn't it ?

[Mrs Beanbag]

not exactly, no... you fill the bit mask as per bresenham, so you can get more accurate period tables this way, and uses only 3 data registers rather than 4.

Edit: so can fit two resamplings in same loop:

  move.l (A0)+,D0
  move.l (A1)+,D1

  moveq.l #31,D6
.loop
  lsl.l D0
  addx.w D4,D2
  move.b (A2,D2),D7
  
  lsl.l D1
  addx.w D5,D3
  add.b (A3,D3),D7
  move.b D7,(A6)+
  dbra D6,.loop

Edit2: and also these registers D4, D5 in above example are likely to have limited range 0...7 or so, so could hard code a few different loops for each case.
Edit3: and can also use longword sample indexes D2 & D3.

[pandy71]

Originally Posted by meynaf

So no playback frequency change - which wouldn't be good for quality anyway, f.e. playing 5khz at 6khz probably gives ugly results.

Trying to not misunderstand you - are you able explain this example - i see nothing wrong to play signal sampled with 5kHz at 6kHz sample rate.

[meynaf]

Originally Posted by Mrs Beanbag

not exactly, no... you fill the bit mask as per bresenham, so you can get more accurate period tables this way, and uses only 3 data registers rather than 4.

Edit: so can fit two resamplings in same loop:

I don't see any difference in accurary, and speedwise it remains the same.

For grabbing data regs there are other ways, like this :

 add.w a0,d1
 addx.w d2,d3
 add.w a1,d4
 addx.w d5,d6

Originally Posted by pandy71

Trying to not misunderstand you - are you able explain this example - i see nothing wrong to play signal sampled with 5kHz at 6kHz sample rate.

This is upsampling, not just playing at a different freq.
Isn't there more distortion when you upsample 5khz to 6khz, in comparison to something like 5khz to 15khz ?

[Mrs Beanbag]

Originally Posted by meynaf

I don't see any difference in accurary, and speedwise it remains the same.

Paula works by incrementing a counter, the sample pointer is incremented when it reaches a user specified value (the period), the addx method adds a user specified value to a counter that increments the sample pointer when it overflows. It is not possible (in general) to exactly match the result of one with the other.

Using a Bresenham-like approach however, Paula's frequency tables could be matched exactly.

[ReadOnlyCat]

Originally Posted by meynaf

Perhaps you did not sign any coding obligation, but then, you shouldn't be doing anything in the "Coders" sub-forum

So either this thread gets moved elsewhere, or it remains about coding and not pure theory.

So, so every discussion in the coders sub forum is followed by corresponding code and there is a dedicated "coding idea but no code please" forum?

Drhex has a different hunch than you do, he might be wrong but who cares? Given enough counter arguments he or you will eventually see the light.

Arguing that the matter needs to be settled by code make it sound like a western duel to death at sunset.

[pandy71]

Originally Posted by Mrs Beanbag

Paula works by incrementing a counter, the sample pointer is incremented when it reaches a user specified value (the period), the addx method adds a user specified value to a counter that increments the sample pointer when it overflows. It is not possible (in general) to exactly match the result of one with the other.

Using a Bresenham-like approach however, Paula's frequency tables could be matched exactly.

Now i don't understand this example... perhaps it will be easier to use well known mathematical apparatus http://en.wikipedia.org/wiki/Angular_frequency , http://en.wikipedia.org/wiki/Normali...ncy_%28unit%29 .

With above example it looks more like DDS http://en.wikipedia.org/wiki/Direct_digital_synthesizer than Wavetable http://en.wikipedia.org/wiki/Table-lookup_synthesis but not sure if this can work with CPU (i feel that jitter may be outcome of this so copper should be used instead CPU).

[meynaf]

Originally Posted by Mrs Beanbag

Paula works by incrementing a counter, the sample pointer is incremented when it reaches a user specified value (the period), the addx method adds a user specified value to a counter that increments the sample pointer when it overflows. It is not possible (in general) to exactly match the result of one with the other.

Pretty much unimportant, as the difference isn't hearable.

Originally Posted by Mrs Beanbag

Using a Bresenham-like approach however, Paula's frequency tables could be matched exactly.

And what would this buy you ?
No quality gain (difference not hearable).
No speed gain (as i've shown).

Originally Posted by ReadOnlyCat

So, so every discussion in the coders sub forum is followed by corresponding code and there is a dedicated "coding idea but no code please" forum?

If i understand well, it's just forbidden for me to merely ask someone to try his idea with real code, in order to see by himself why it can't work ?

Originally Posted by ReadOnlyCat

Drhex has a different hunch than you do, he might be wrong but who cares? Given enough counter arguments he or you will eventually see the light.

I've never seen many people actually see the light when given enough counter arguments.
I have given arguments at many places, and they usually get ignored when the other guy can't counter them.
For example, what has Drhex to say for the fact there are too many combinations of possible code even for a very limited set of possible frequencies ? Nothing. I didn't get any reply. And this, because he has no clear idea of what he is talking about.

Originally Posted by ReadOnlyCat

Arguing that the matter needs to be settled by code make it sound like a western duel to death at sunset.

Not exactly. One can prove that something works by actually doing it ; but a proof that it can't work can't be done.
This is why i ask for code.

[drhex]

Originally Posted by meynaf

For example, what has Drhex to say for the fact there are too many combinations of possible code even for a very limited set of possible frequencies ? Nothing. I didn't get any reply. And this, because he has no clear idea of what he is talking about.

I did not consider that it might use upp too much memory to store all the required mixing routines. Spolied with too many GB of ram nowadays.
But with 200kb dedicated and, say 200 bytes per routine, there could be 1000 of them. If you skip disc activity and receiving of serial data while playing (whose interrupts have priority over audio) the occational sample played at wrong period shouldn't cause more noise than is already caused by non-interpolation, and so the hardware can control the frequency of one of the virtual voices.
With every instrument sampled once per octave, there will only be 12 possible playback frequencies, 12*12/2 = less than a hundred mixing routines required.

[meynaf]

Originally Posted by drhex

I did not consider that it might use upp too much memory to store all the required mixing routines. Spolied with too many GB of ram nowadays.
But with 200kb dedicated and, say 200 bytes per routine, there could be 1000 of them. If you skip disc activity and receiving of serial data while playing (whose interrupts have priority over audio) the occational sample played at wrong period shouldn't cause more noise than is already caused by non-interpolation, and so the hardware can control the frequency of one of the virtual voices.
With every instrument sampled once per octave, there will only be 12 possible playback frequencies, 12*12/2 = less than a hundred mixing routines required.

That's still many routines to write and a small choice of possible frequencies (which forbids any effect such as portamento).

Amiga periods for a soundtracker look like this :
$0358,$0328,$02fa,$02d0,$02a6,$0280,$025c,$023a,$021a,$01fc,$01e0,$01c5

As you see, nothing like a simple 0.8 ratio.

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 ?
If you're just skipping pointer updates like in your 0.8 cases, then most routines can eventually end up a lot larger than the expected 200 bytes...

You could perhaps sample for every 12 possible notes ; then the mixing code only has to deal with 2^n ratios (it'll do the octave changes). But you'll very soon be out of mem...

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 ?