Slow DSP investigation with DFB1

[Badwolf]

If it is the song I’ve created than yeah, when I load it in DFB mode it does output crackles during wav load, something it does not do in regular mode. It may pass the wav file through the DSP during load which might create those artifacts.

I do however get the song to play but it is more related to audio sample rate. Perhaps you should open the audio settings window and reaffirm settings. Also, the files are 44.1KHz and Cubase requires a hardware sale rate generator to go up from 33Khz

Hi Whomper,

I'm afraid it's the first time I've ever laid eyes on Cubase Audio, so I don't quite know what I'm meant to be checking in the settings window!

It does complain about the lack of a 44k1 dongle, but can it play back (albeit slowly) with the onboard 33kHz signal, or will that stop playback entirely?

Cheers,

BW

[whomper]

Hi Whomper,

I'm afraid it's the first time I've ever laid eyes on Cubase Audio, so I don't quite know what I'm meant to be checking in the settings window!

It does complain about the lack of a 44k1 dongle, but can it play back (albeit slowly) with the onboard 33kHz signal, or will that stop playback entirely?

Cheers,

BW

Im away from my Falcon for a few days so can co-test with you. In principle it should play a filter with different sampling rate but I don’t know how the Atari Cubase Audio behaves.

You may want to try half sampling rate and in the settings UI reaffirm the rate just in case. I noticed Cubase is sometimes picky about it.

[dml]

Seems like this test really needs a simple demo track that's intended to work correctly on a plain setup without the dongle. With audio stuff especially, it can be very difficult to tell if there is a fault or if something just is not configured exactly right. Even just hearing clicks and dropouts can be confusing if you don't know exactly what to expect, if it's normal or not!

BW: I've been out of action for a couple of weeks with some health issues - so have not been doing much of anything - have not made any progress with the DSP / DMA / interrupt tests I mentioned before. I'll get to it at some point but it will need to sit a while longer. I do have a spare F030 mainboard which needs some attention so I could do some tests/experiments with that - I could put a DFB1 on it as a test rig and flash a GAL or two over the holidays :)

[Badwolf]

Thanks @whomper & @dml.

I too have been a bit quiet of late. Norovirus making its way through my household didn't help!

I'm currently trying to clear the decks a bit to get the 'proper' Falcon out to be able to form a baseline for Cubase. That means finishing off, or at least sufficiently advancing, three projects that are taking up the bench space in the shed.

@pakman has also kindly sent me an experimental GAL build which I want to try too.

Hopefully I can make some headway before xmas too.

BW

[charon030]

I'm not sure whether you are aware of this analysis, on how the issue can be resolved for the CT2? At least I think it resolves the issue mentioned in this thread.

https://mikrosk.github.io/ct2/NOTES.html#dsp-irq-signal

Didier seems to have connected a wire from DSACK0 at the GAL U44 output to the DSACK0 signal between CPU and FPU on the CT2. So instead of replacing the GAL generating the DTACK in a 68000-bus cycle style, they just generate their own DSACK with the help of a 7405.

[dml]

I'm not sure whether you are aware of this analysis, on how the issue can be resolved for the CT2? At least I think it resolves the issue mentioned in this thread.

https://mikrosk.github.io/ct2/NOTES.html#dsp-irq-signal

Didier seems to have connected a wire from DSACK0 at the GAL U44 output to the DSACK0 signal between CPU and FPU on the CT2. So instead of replacing the GAL generating the DTACK in a 68000-bus cycle style, they just generate their own DSACK with the help of a 7405.

Interesting - had not seen that page of Mikro's. Although I don't have a CT2 so that is a factor :)


at the risk of a tangent... quoting from the page...

"Centek found using the DSP IRQ (which triggers an exeption on the 68030) bad programming practice (not optimal)."

I think this is only true in the simplest sense. Sending individual bytes/words or small packets using this interrupt mechanism is of course very inefficient. The CPU interrupt overhead and latency for the IRQ converting into work means it will always be faster to use a synchronous, manual transfer directly over the port, as written there...

However there are many situations where direct control over the port is not practical or itself is inefficient because the next transfer can't be easily predicted and can't be synchronised without waiting. If anything is bad programming practice in the world of realtime applications, it is waiting :)

This is especially true for something like a DAW with realtime mixed/processed audio streaming onwards to a device - the sample rate is dictating the rate of consumption of data from the host CPU, the number of sources may be varying (sample banks? voices?) and so the DSP must notify the CPU when it needs or can accept new data, rather than the CPU polling or pushing data when convenient. This requires an IRQ to notify. (there is also the other mechanism - the DMA frame IRQ but it is specific to DMA, which has its own set of constraints/issues)

The overhead of the IRQ then gets absorbed into the block transfer itself - which can be in the interrupt or after returning from the notify. The IRQ does not need to serve each individual bit of data.

An application of this kind running in a single-tasking environment will also aim to avoid the CPU getting tied up in blocking waits so it can continue to serve other works such as UI refresh. Less of an issue in a threaded environment but at the time these machines were all single-cored so IRQ still beats time slicing for low latency.

In other words - it did have an important role to play in professional audio software at a minimum and probably why Atari made sure the signals were provided one way or another.


The part which remains unclear - which existing applications/demos etc. actually used the DSP IRQ for host interrupts? Might be an interesting experiment to nerf the IRQ line in an otherwise unmodified system and see which Audio software will still run. I would be surprised if CBA or Atari's realtime signal processing demo will operate correctly without it but I don't know for sure.

For me at least, it remains a valid hardware feature on the Falcon and where it makes sense to do so I will probably be using it :P

[stephen_usher]

It has always been that interrupts should be used for "infrequent" events of unknown timing but polling for predictable, possibly timing critical, events.

Polling need not be blocking, it could be part of a loop sequence polling multiple items, but in a predictable manner.

Anyway, this is by the by as the DFB1 needs to be able to service software which runs on the standard hardware.

[mikro]

The part which remains unclear - which existing applications/demos etc. actually used the DSP IRQ for host interrupts?

It's on the page as well: MP2 <= 0.994, Aniplayer (when playing Cinepak [cvid], Apple/QuickTime Video [rpza], Microsoft Video 1 [msvc/cram8] AVI/MOV files in ‘Without GEM’ mode), MegaPlayer 1.15+, Quincy, ...

I personally tested it against MegaPlayer, both software and hardware fix.

Btw don't take those "not optimal" quotes too seriously -- Phenix (CT2) software devs were kids from the demoscene, they had no clue.

[viking272]

Is this an issue that affects all DFB1 and DFB1Xs? (Edit: re-read a few more posts and it looks to be both board varieties)
Is it a newish issue or has it always been there?

[exxos]

Is this an issue that affects all DFB1 and DFB1Xs? (Edit: re-read a few more posts and it looks to be both board varieties)
Is it a newish issue or has it always been there?

The issue will be with both as they share the same base code.

I haven't been following it all in detail myself as busy with the 536.. But the issue has been there since day one.. When I tried acetracker, it all worked fine for me. But others saying it doesn't work now, and now revealed that for some reason the DSP is running slower than it should.

AFAIK, we don't know the exact mechanism why this happens yet. But so far sounds like screwy Falcon GAL logic. It also seems other boosters may have the same issue as well.

So may not be a matter of simply debugging the DFB1 code base, it's a matter of debugging the Falcon GAL logic as to why it even happens in the first place.. not so simple when it gets to debugging what Atari did :roll: