DSP Xover project (part 2) - Page 6 - diyAudio
Go Back   Home > Forums > Source & Line > Digital Line Level

Digital Line Level DACs, Digital Crossovers, Equalizers, etc.

Please consider donating to help us continue to serve you.

Ads on/off / Custom Title / More PMs / More album space / Advanced printing & mass image saving
Reply
 
Thread Tools Search this Thread
Old 11th July 2012, 04:25 PM   #51
chaparK is offline chaparK  Luxembourg
diyAudio Member
 
Join Date: Apr 2010
Location: Luxembourg
Quote:
Originally Posted by Shaun View Post
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'.
  Reply With Quote
Old 11th July 2012, 04:34 PM   #52
Shaun is offline Shaun  South Africa
diyAudio Member
 
Shaun's Avatar
 
Join Date: Aug 2001
Location: Cape Town, South Africa
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.
__________________
Shaun Onverwacht
|||||||||| DON'T PANIC ||||||||||
  Reply With Quote
Old 11th July 2012, 04:37 PM   #53
chaparK is offline chaparK  Luxembourg
diyAudio Member
 
Join Date: Apr 2010
Location: Luxembourg
Quote:
Originally Posted by Shaun View Post
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!
  Reply With Quote
Old 11th July 2012, 04:38 PM   #54
Shaun is offline Shaun  South Africa
diyAudio Member
 
Shaun's Avatar
 
Join Date: Aug 2001
Location: Cape Town, South Africa
__________________
Shaun Onverwacht
|||||||||| DON'T PANIC ||||||||||
  Reply With Quote
Old 11th July 2012, 05:03 PM   #55
diyAudio Member
 
Join Date: Jan 2005
Location: Sweden
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 ?
  Reply With Quote
Old 11th July 2012, 06:42 PM   #56
diyAudio Member
 
Join Date: Jan 2005
Location: Sweden
I like the user friendliness of the "Lem Dx editor". Just download, its free.
GENERALMUSIC S.p.A.
  Reply With Quote
Old 11th July 2012, 06:57 PM   #57
qusp is offline qusp  Australia
diyAudio Member
 
qusp's Avatar
 
Join Date: Oct 2009
Location: Brisbane, Australia
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
  Reply With Quote
Old 11th July 2012, 07:30 PM   #58
chaparK is offline chaparK  Luxembourg
diyAudio Member
 
Join Date: Apr 2010
Location: Luxembourg
Quote:
Originally Posted by dahlberg View Post
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.

Quote:
Originally Posted by qusp View Post
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.
  Reply With Quote
Old 11th July 2012, 08:26 PM   #59
qusp is offline qusp  Australia
diyAudio Member
 
qusp's Avatar
 
Join Date: Oct 2009
Location: Brisbane, Australia
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?

Last edited by qusp; 11th July 2012 at 08:30 PM.
  Reply With Quote
Old 11th July 2012, 08:39 PM   #60
chaparK is offline chaparK  Luxembourg
diyAudio Member
 
Join Date: Apr 2010
Location: Luxembourg
Quote:
Originally Posted by qusp View Post
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.
  Reply With Quote

Reply


Hide this!Advertise here!
Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are Off
Pingbacks are Off
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
DSP Xover project chaparK Digital Line Level 141 3rd July 2011 10:16 AM
Help Please for simple active Xover project dcathro Analog Line Level 4 9th September 2010 05:47 AM
Violet DSP Evolution - an Open Baffle Project cuibono Multi-Way 211 18th May 2010 02:26 AM
Software digital DSP ... Xover/filters/EQ ?? JinMTVT Digital Source 2 8th October 2004 06:02 AM
DSP card & proper xover for heathkit 859A speaker cabinet x. onasis Multi-Way 6 22nd April 2003 07:39 PM


New To Site? Need Help?

All times are GMT. The time now is 07:49 AM.


vBulletin Optimisation provided by vB Optimise (Pro) - vBulletin Mods & Addons Copyright © 2014 DragonByte Technologies Ltd.
Copyright 1999-2014 diyAudio

Content Relevant URLs by vBSEO 3.3.2