DSP Xover project (part 2)

[chaparK]

Originally Posted by Shaun

Some questions:

(1) Is this project still subject to the maxium production quantity constraints of the original project?
(2) What is the envisaged building block configuration? Will it be user-configurable?
(3) What kind of GUI will the control software have? (I like the GroundSound interface).

Hi Shaun,

(1) No there's no connection to the previous project, this is a wholly new design intended specifically for loudspeaker applications (which was not the case of the previous project).
(2) There's going to be several 'themes' to build upon. The term of 'theme' here has to be understood as a processing strategy, and the user must select one of these upon creating a preset. Within a theme, you can disable the blocks that you don't require. The supplied strategies are meant to cover all needs in loudspeaker applications, but I'm happy to add more on request if it turns out that users want something that's not achievable.
(3) That's a very open question! It's going to be a real-time GUI with meters, status, signal path and processing blocks organized in logical configuration units, with an emphasis on functionality rather than on the 'look'.

[Shaun]

I agree that "look" should come last. My interest is really the ability to view a final response graph, overlaid on a target response curve.

[chaparK]

Originally Posted by Shaun

I agree that "look" should come last. My interest is really the ability to view a final response graph, overlaid on a target response curve.

Included!

[Shaun]

[dahlberg]

Ok, so there is some latency that's user dependable and if I'm reading this
right it's lower at higher samplingrates. And the adc puts out 24/96 ?

[dahlberg]

I like the user friendliness of the "Lem Dx editor". Just download, its free.
GENERALMUSIC S.p.A.

[qusp]

it depends on what factors causes the delay, perhaps when the buffer memory is half full? I presume there is some sort of fifo memory in this too yes? with the i2s fifo device of Ian's, the delay is shorter with higher speed because getting to the half full state before playback starts, takes less time

[chaparK]

Originally Posted by dahlberg

Ok, so there is some latency that's user dependable and if I'm reading this right it's lower at higher samplingrates. And the adc puts out 24/96 ?

I'll try to be more specific on that one.

First thing, as already mentioned, the system supports 48/96/192 kHz, it's a preset parameter defined by the user.

Second thing is the delay induced by the processing. A trivial example is a simple delay line: if you implement 100ms delay on one channel, then there's 100 ms delay on that channel, that's obvious.

It's less obvious in some other circumstances. If you implement a FIR filter, you might be required to shift in time the impulse response of your filter - otherwise you cannot implement this filter as it would have to process samples from the future... This is referred to in the literature as the 'causality' of the filter. So again, if you time-shift your filter by let's say 100 samples, then there's an inherent 100-sample delay on that channel.
Still about FIR filters. If you're using a convolution in the frequency domain, then the usual way to deal with that is to store in memory a chunk of audio before starting the processing (although there are ways to avoid this but let's keep things as simple). Again in this case, you delay the audio by the amount of samples that you are storing.

Normally you don't need to worry about these delays because they are small and equal for each channel. In your specific case however where you're mixing analogue and digital processing on separate channels, you might want to be aware of what's going on.

Now, if you're happy with digital 'equivalents' of the analogue classics - and these classics are going to be available - then there's no particular delay incurred to worry about.

Originally Posted by qusp

it depends on what factors causes the delay, perhaps when the buffer memory is half full? I presume there is some sort of fifo memory in this too yes? with the i2s fifo device of Ian's, the delay is shorter with higher speed because getting to the half full state before playback starts, takes less time

At the electronic level there's no fifo at all on the signal path. When the sample is available, it gets transferred straight away to the CPUs for processing and it can be spit out on the next sample clock edge.

[qusp]

hmm, so this sounds like its going to be pretty difficult to synchronize with video, as even though small, it seems like it would be a small, but constantly varying delay depending on the complexity of, say the convolution of a varying signal with varying complexity? or does the filter processing time stay constant provided each mechanism can finish before the next clock edge?

is the system fast enough that anything you employ that doesnt incur some delay due to the nature of the filter, can be finished before the next clock tick?

perhaps the best thing to do in that case if you need to know a set time to sync video to, would be to set a known delay on everything and being that the delay calculation is simple enough its always going to be realtime, therefore it should not cause further delay to process while all the other filters complete. does that make sense?

[chaparK]

Originally Posted by qusp

hmm, so this sounds like its going to be pretty difficult to synchronize with video, as even though small, it seems like it would be a small, but constantly varying delay depending on the complexity of, say the convolution of a varying signal with varying complexity? or does the filter processing time stay constant provided each mechanism can finish before the next clock edge?

perhaps the best thing to do in that case if you need to know a set time to sync video to, would be to set a known delay on everything and being that the delay process is going to be realtime, it should not cause further delay to process while all the other filters complete. does that make sense?

Na don't worry. A time-varying delay is not something anyone would like to see as it affects pitch in the best case and causes glitches otherwise.
So please, look deeply into my eyes no time-varying delay.

You set the filtering properties, then all delays remain constant. Also these delays are small and don't affect synchronization with video.