I am joining others here and I am definitely interested...
Cheers!
Thanks for your expression of interest.
More information to follow.
No I don't think so.
I'll just start offering the product when it's working to specs and when the boards are available. I'll keep you informed but target date is 1st October for the Windows release. Maybe earlier
have to admit I didnt think of this before, but it would seem that bitperfect transfer to the DSP is not possible with your board, it didnt sink in before, but you only have one clock, I suppose this can be solved by using external clock, but how is the data clocked out of the DSP, will having 2 audio clocks for the 2 integers 22.1x and 24x for the dacs be enough, or will the data have already been resampled to suit 24x for everything? obviously the DSP resamples to a higher bitrate and bitdepth for processing, but can it still be based on 22.1x?
this is IMO one of the big failings of the miniDSP and it would be nice to avoid if possible. sorry if i've missed something
this is IMO one of the big failings of the miniDSP and it would be nice to avoid if possible. sorry if i've missed something
There's one central clock, and from this clock is derived the internal DSP working sampling frequency, which can be 48, 96 or 192 kHz.
What's coming in from the digital domain goes through a sample rate converter in order to adapt the input rate to the DSP rate. There's no worry to have about that because sample rate converters exhibit extremely low THD+N - well below the level of your ouptut DAC's THD+N, whatever DAC it is.
Now, let's imagine that we follow you and decide to use the clock derived from the input stream. Then there are 3 major problems:
1. If you don't want to resample the input stream, then you must resample the processing - so that in the end you're only shifting the resampling elsewhere.
Imagine you specify a delay which is 41 sampling periods at 44.1 kHz, but the input stream is 48kHz. That's 44.625 clock periods at 48 kHz, we agree right? Shall the DSP 'resample' that delay to 44 or to 45 sampling clocks?
Imagine now the case of a FIR filter designed by yourself and consisting in 342 coefficients at 44.1 kHz. But the input stream happens to be 96 kHz. Well then the DSP requires 744.489 coefficients derived from the original 342 through ... resampling of the original FIR.
What I mean is that there's going to be resampling anyway if one wants to support various sampling frequencies.
2. If we want to support natively N standard audio rates (say N = 7 for 32, 44.1, 48, 88.2, 96, 176.4 and 196 kHz) then the DSP must store N coefficient sets for each of the supported sampling frequency. These coefficients are resampled versions of an original model as with seen in point 1.
3. The next problem is that we must detect the input rate in order to decide what coefficient set to apply. With SPDIF that's alright, we could use the PLL lock status and wait until the clock settles, then extract the sampling frequency. But how would we do that for I2S inputs?
And now, what if there's a bug in the system: the input is 44.1 kHz but the system has detected 196 kHz
and picked the wrong coefficient set, the net result being that we blew your new ribbon tweeters 
...In short, you shouldn't worry about resampling the audio: the THD+N of resamplers is much lower than what your DAC can do, and resampling is here around anyway if you wish to support various sampling rates.
Last edited:
Can the board also be programmed with Symphony Studio for those who want to learn some DSP programming?
This would be much better then buying some generic evaluation board... And hopefully a bit cheaper also
There's a JTAG header on board. It's your responsibility to provide the hardware between the DSP board and your computer.
The peripherals (ADC/DAC, SPDIF outs etc) are configured by the micro-controller. So you will need to handle that portion of code as well, as I suppose you would want to hear your processing.
Provided these conditions above, yes you can use Symphony Studio and write your own code.
Cool!
Is that true also for Sigma Studio (in case your board is based on Analog Devices)?
Cheers!
Is that true also for Sigma Studio (in case your board is based on Analog Devices)?
Cheers!
Hmm... That board is based on Freescale's dual-core 500 MIPS DSP56725, not any of Analogue Devices' chips.
I should have that one (and only) brain cell engaged before typing...
Even more interested now...
hmm.. as I thought
1. If you don't want to resample the input stream, then you must resample the processing - so that in the end you're only shifting the resampling elsewhere.
Imagine you specify a delay which is 41 sampling periods at 44.1 kHz, but the input stream is 48kHz. That's 44.625 clock periods at 48 kHz, we agree right? Shall the DSP 'resample' that delay to 44 or to 45 sampling clocks?
Imagine now the case of a FIR filter designed by yourself and consisting in 342 coefficients at 44.1 kHz. But the input stream happens to be 96 kHz. Well then the DSP requires 744.489 coefficients derived from the original 342 through ... resampling of the original FIR.
so its not possible to have N different FIRs? i'm not overly savvy (understatement) in that area. I guess I just assumed the FIR would be based on the samplerate, not the other way around. actually more accurately, I presumed the filter itself and that process did not have any reference at all to the output clock, being resolution independent and acting on a sample by sample basis in processor memory; only when it came to spitting it out did the result spat out onto each clock tick. thats not based on any knowledge just how I figured it would work
yeah but thats not insurmountable is it, given the below points are well taken care of?
not a problem, both of my i2s sources have 2 clocks (one has 3, one 12mHz TCXO for USB) there is a header from which the chosen speed for MCK can be pulled. it will set logic high or low depending. its a mechanism used for both selecting the clock, as well as displaying the samplerate on a display
yeah well if that happened with my source too it would suck, but it doesntAnd now, what if there's a bug in the system: the input is 44.1 kHz but the system has detected 196 kHz
maybe I shouldnt, but I do
Last edited:
Ok mate we'll find a way to please you on that issue by allowing to use an external clock
It's not easy to keep you satisfied you know I'll made the hardware change to make this possible but software management will come later with a second release. Note that with this change it's your responsibility to supply a clean clock (I2S).Thanks for your interest!
I don't have any measurement at that point. I need to meet a long time buddy, ask him to forgive me for not contacting him for so long and maybe ask him if he still has his AudioP
Analogue volume control is taken care of with CS3318 (or CS3308), obviously separate from DSP.
Ok mate we'll find a way to please you on that issue by allowing to use an external clock
thanks!, thats cool, I wont be till the second release anyway I wouldnt think, as i'm on mac OS Lion, i'll use linux or win in emulation if I have to, but I would really prefer not to. depends on how that impacts the timing. All in all i'm in no rush
No, not easy to please I know, I like to upgrade to systems that are better than or comparable + more convenient than what I already have =) I think you'll find there will be more than me who will appreciate the ability to maintain synchronous dual masterclock and I would expect more sales because of it.
clean clocks? not a problem, i'm using a clock + clock buffer that totals less than a pS
Last edited:
