strange way to set dma audio
 

Hi,

The "official" safe way to start a new sampleA on voice A is:

1) switch off dma voice A ( move.w #$0001,$dff096 )
2) write sample address ( move.l #sampleA,$dff0a0 )
3) wait the right amount of time ( say X rasterlines )
4) enable the dma voice A ( move.w #$8001,$dff096 )

Now I wonder if it's still safe to invert 1) and 2) like:

1) write sample address ( move.l #sampleA,$dff0a0 )
2) switch off dma voice A ( move.w #$0001,$dff096 )
3) wait the right amount of time ( say X rasterlines )
4) enable the dma voice A ( move.w #$8001,$dff096 )

I think it should be ok but I want to be sure.

Any though?

I see a possible weak point here: writing the pointer is not an atomic operation...

If the period [EDIT: of course I meant..] len counter has finished counting down and the DMA is still active a new sample is taken from the ptr position.
The DMA is turned off immediately, but it is not an instant operation, sample in Paula is played.
Could there possibly be an audio glitch?

Toni should be asked :)

This looks like a way to get a nice random sample triggering click ;)

that's a very good point. So two cases could happen:

1) non atomic write occurs outside of PAULA exact loop point. In this case, the "next instrument" could be played (maybe one1 or two 8bits samples) before dma switch off and switch on again ( so the very first "good" sample will be played back again.
I think this case is ok and doesn't produce noticeable annoying glitch ( with bad luck you will play the very first sample of the right instrument 2 times)

2) non atomic write occurs at the exact PAULA loop point. This case is a real issue, because if 1 or 2 samples are played before DMA is switched off, these two samples could be completely random ( I mean not the very first samples of the right instrument). So if case (2) could happen, then it could produce hearable audio glitch

I agree. Toni, what do you think, is the case (2) possible on an Amiga?

ok I simulated to worst case ever ( highest playing rate with smallest loop len ) and at least it produces audio glitches in WinUAE ( I didn't tested on real amiga ).

I'm still interested by Toni's view on that

I don't think there is anything too special. If AUDxLEN expires between writes (and DMA is on), it can cause side-effects.

right that is what my stress test show in winuae.

Ok I had a nice optimization for next LSP version but I won't use it because of potential audio glitch
thanks!

"DMA wait" stuff is the most annoying feature in Paula audio. It really should have had some way to instantly stop period counting/state machine 2<>3 "pingponging".

another question. For weird reason, I would use the highest bit of a sample start address to encode something. Is it safe on every amiga? ( I guess yes because PAULA sample address is 21 bits only but I want to double check).

Like is it ok on all amiga to do: move.l #sample|(1<<31),$dff0a0

Yes in any existing hardware but some re-implementation might want to support DMA everywhere.

IMHO it would be safer to use bit 0 as a flag because DMA is always word aligned.

that is good idea also! I'll use bit 0 then, thanks!

I'm working on adding the last "big" missing feature in LSP: "instrument without a note". In some modules, a "instrument" is specified in the instrument column without a note. This is tricky case and many players ( esp PC players ) doesn't handle it correctly. What happen is that amiga players generally just write the "repstart/replen" in Paula registers ( so the instrument will really start at the end of the previous instrument loop )

I "think" these amiga players just write the Paula address using a non atomic "move.l" write instruction! So according to this forum thread, my guess is that it "could" ends in audio glitch. And to my knowledge, all amiga players are doing that actually (but I could be wrong, it's so hard to read amiga module player source code.... )

Did I miss something?

PT2.3F ("reference player") doesn't play those I'm 99% sure.

you mean PT2.3F reference player doesn't support "instrument without a note"? I'm rewriting all LSP command encoding right now to support that ... Insane player will run same speed as before, but generic player will be slightly slower.

Do you know if p61 is supporting this feature? ( as p61 is the most used mod player in demos I guess I should at least be p61 feature complete )

Went again through the PT2.3F source... It explicitely checks for an empty note and skips the dma bits, pointer/length, period. Tried several scenarios, never ended up in that part of the code.
P61 does the same (doesn't play), actually easier to see what's going on there if you have a cleaned up source.

that's crazy! you mean the attached .mod I created for myself as a test doesn't work with PT2.3F or p61? ( it actually works as expected when played by OpenMPT on PC)

I'm pretty sure I've seen modules with this "instrument without the note" pattern (I remember it because it seemed strange to me :)),
So a tracker/mplayer that supports it must certainly exist.

Hmm, strange. It actually plays with PT2.3F, but not PT3/4 nor P61. All these play only one sample (#2), while PT2.3F plays both. Guess I must've missed one path (probably that delayed repstart/replen went through somehow).

I'd take PT2.3F as more correct.

for instance this really cool attached .mod use a lot of "sample without note".

That's unexpected , there is plenty of mods using this trick, so they don't play well on p61? To be honest right now LSP 1.03 doesn't support the feature, and if you listen to parcade.mod it sounds pretty well. ( so I guess most of the .mods using this technic aren't noticeable if played with non compatible player)

But something is still confusing to me: if you said PT2.3F replay my stress-test mod correctly, it means player should also write sample address using non atomic write during the play, right? We know it's not "legit". Maybe there is no glitch in this specific case