No problem for your setup: the board has over 1s of delay (at 96 kHz) to share between the channels.
I'm interrested too, seems to be a very very good project.
Some questions :
I consider it as a real DIY MiniDSP alternative. I am right ?
You say about pricing that it will be cheap, could you elaborate ?
What about the PSU ?
Thanks
Phil
Some questions :
I consider it as a real DIY MiniDSP alternative. I am right ?
You say about pricing that it will be cheap, could you elaborate ?
What about the PSU ?
Thanks
Phil
Ok, so that will not be a problem
Then, lets just for arguments sake say that I don't think that it will sound
good enough for use in the upper region (my experience so far with other
products of this kind). What is the delaytime through the filter, 3ms as in
some pa-filters or..... ? I'm running a half dsp, half passiv solution as an
evalutionsystem today that's not perfect but it works fairly good anyway.
I will be using the filters analog input (not all digital yet
) and from earlier experience the adc has been the main concern for any shortcomings.
Do you belive that this might be the case with this product ? You have been
asked about what dac's and adc's used earlier and I respect that you don't
want to be specific about it yet, but I belive that you understand my concern.
Keep up the good work
Last edited:
About pricing, I truly hope that you are setting high quality before lowest
possible price, at least concerning adc, dsp and dac's. In my opinion the
world doesn't need another cheap toy. A world class dsp crossover that
would send all passiv/analog filters to history is something else.
To replace opamp's with other sorts or for instance tube based solutions is
something most of us will handle without problems so if you want to keep the
price down maybe you should consider leaving out parts in the analog section.
possible price, at least concerning adc, dsp and dac's. In my opinion the
world doesn't need another cheap toy. A world class dsp crossover that
would send all passiv/analog filters to history is something else
. To replace opamp's with other sorts or for instance tube based solutions is
something most of us will handle without problems so if you want to keep the
price down maybe you should consider leaving out parts in the analog section.
I already asked about balanced, but regretted even asking, its pretty obviously not balanced, there are RCA connectors and 8 opamps. 8 balanced would require 16 outputs, which it clearly doesnt have. I would suggest, as some of us are already thinking, that if you want balanced you should just use the digital outputs. I'm pretty sure since the XO will probably be done without reference to polarity, that it shouldnt matter whether you use a balanced DAC afterwards or not.I'm interrested too, seems to be a very very good project.
Some questions :
I consider it as a real DIY MiniDSP alternative. I am right ?
You say about pricing that it will be cheap, could you elaborate ?
What about the PSU ?
Thanks
Phil
Salut Phil,
I really don't have pricing information so far, but I'm making sure it's going to be affordable. You'll be positively surprised.
PSU requirements are 5V and +/- 12V.
System Input/output delay is 1 sampling clock: that's the delay when you turn off all processing.
Now of course you don't want to turn off all processing. So delay is basically subject to what processing you've enabled on the signal path.
It's going to be cheap and very good quality. If you have specific requirements, keep in mind that the board has in standard SPDIF and I2S for both inputs and outputs and hence can accommodate your own equipment.
In that case you can always use the analogue section for blind tests evaluating your own ADC/DAC
Salut Phil,
I really don't have pricing information so far, but I'm making sure it's going to be affordable. You'll be positively surprised.
PSU requirements are 5V and +/- 12V.
System Input/output delay is 1 sampling clock: that's the delay when you turn off all processing.
Now of course you don't want to turn off all processing. So delay is basically subject to what processing you've enabled on the signal path.
It's going to be cheap and very good quality. If you have specific requirements, keep in mind that the board has in standard SPDIF and I2S for both inputs and outputs and hence can accommodate your own equipment.
In that case you can always use the analogue section for blind tests evaluating your own ADC/DAC
the group delay and latency of the adc/dac will count for most of the delay in the system. A typical sigma delta codec can have 1-2 ms worth of delay from input to output. Provided you used the same adc/dac combo for all channels the delay is immaterial
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).
(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'.
I like the user friendliness of the "Lem Dx editor". Just download, its free.
GENERALMUSIC S.p.A.
GENERALMUSIC S.p.A.
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
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.
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.
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?
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?
Last edited:
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.