Where do I begin ? (implementation platform question)

I have a conceptual idea that I would like to implement as a project but I have no idea what is the best implementation platform suitable for this. A PIC ? or FPGA ? or.. ? I need your help in determining that. Here’s what I am trying to do –

This is about processing and moving spdif digital audio data. I want to extract the actual data samples from the spdif stream and put them in a buffer. While that’s happening I want to send the samples from this buffer as they come (FIFO) to a DAC (digital to analog converter). These samples need to be clocked out to the dac. And this clock would be a VCXO. A Latch Enable signal would also need to be provided to the dac for every sample that’s gets moved to the dac register. Now the input stream could be faster or slower than this vcxo clock. Hence the purpose of the buffer. And when this buffer becomes full or empty a voltage change would be sent to the vcxo to make it go slow or fast as the need be.

If you are thinking this really isn't any different from a spdif receiver that can spit out a clock and data line that goes to a dac then you're right. Except, this would not have a PLL, and the clock sync frequency would be very low – like say 10hz or maybe even lower. Meaning the dac clock will be synced to the input stream only 10 times per second.

Buffer size by my estimate does not have to be more than a few(50) KB. The spdif stream rate would be in the order of ~3Mbps.

I have tried to be brief but if you need any more info please feel free to ask.

This makes no sense : ( SPDIF stream is usually continuous, as far as I'm aware. So, how would the buffer become empty?
Also, if you're dynamically changing the clock to your DAC as the buffer is getting empty, then this is a form of distortion.
Better to either just clock the DAC at the rate at which you're receiving the samples, since the SPDIF stream will have a
fairly accurate clock, or buffer a second or so, and not implement the variable DAC clock that you're considering. In the
unlikely event that the buffer becomes empty, then insert silence.
Are you sure you don't want to do silence insertion or something? That is very different.
You might want to simulate the scheme (Matlab or similar) before implementing.

If I would clock the dac at the rate of the spdif stream then it defeats the whole purpose of this scheme. The whole idea is to break the dependency of the source's clock from the dac clock. So as soon as you talk about more than one clock you have to deal with keeping them in sync. Now if those clocks are kept tightly in sync then what you are saying is kind of true that at that point why not just use the source clock, but if you do that then you inherit all the negative qualities of the source clock and that is why we are trying to break that dependency. Now how do we "break" that dependency ? Using the buffer. The buffer allows the dac clock to not track the source clock too closely and hence filter out most if not all inadequacies of the source clock.
And no silence insertion is ruled out, not an option. If the sample made it across it has to play.

P.S:- actually your thought about just using the spdif stream as a timing event is also another project in my mind. Again same as an spdif receiver but no PLL. This would ofcourse work quite well IF and assuming that the source clock is of very good quality.

That's right - if you use a buffer, then you're not dependent on the source clock. However you can't vary it, that would cause more distortion than just using the input spdif for clocking.
You would have to expect that the buffer size is sufficient for underflow to _never_ occur. If it isn't, then you would need to insert silence. Of course, overflow could be a problem too...

sky_123 said:

However you can't vary it, that would cause more distortion than just using the input spdif for clocking.

Click to expand...

It can varied with a VCXO, right ? A Voltage Controlled Crystal Oscillator allows you to do just that. Why else were you thinking it cant be varied ?

Since the clock sync is at such a low frequency, that modulation is outside of the audible range, plus you get the advantage of removing all jitter above that frequency and random jitter as well from the source clock. Use of PLLs could cause distortion due to their own phase noise and jitter but thats the whole point of this scheme - get rid of the pll.

But anyway, going back to my original question, if this was to be implemented then what form of implementation is most suitable for this ?

Any oscillator (including VCXO) has phase noise too. I think you need to "expect" that the buffer will never empty, and hence no need to implement an algorithm which will vary the DAC frequency. If you expect that the buffer may empty and therefore you wish to vary the DAC frequency, then do you expect that at some stage that the buffer will have more than usual, to make up for the time that the buffer was empty? If so, then why not just have a larger buffer?
If you expect it never to recover, then your DAC clock is forever running slower (or you do silence insertion) to counter that.
Anyway, you could simulate your scheme (and therefore see exactly what improvement the idea makes) using Matlab
because you may find that it could have been solved by a fixed clock and larger buffer.

If this is for hifi purposes, then I think you just need to size an appropriate buffer. If it is for a different
purpose, e.g. audio that is very likely to be lost (e.g. packet loss on a radio network) then those
implementations do insert silence (well actually comfort noise) and all sorts of interesting stuff.

ok so lets say I simulate it in Matlab and go with your approach then what platform would be most suitable for this ? Should I look into using a microcontroller ? or something else ?

Usually DSP or programmable logic, but a high speed microcontroller might be fine for this too
(spdif is not too fast).