Asynchronous I2S FIFO project, an ultimate weapon to fight the jitter

[AR2]

Originally Posted by iancanada

[COLOR=black][FONT=Verdana]Si570 driver will partly open frequency control to third party external controller from a UART.
Ian

Could that be Hifidunio? Right now Hifidunio displays the frequency, but if I understand this well, it would be possible to display and adjust as well?

[iancanada]

Originally Posted by AR2

Could that be Hifidunio? Right now Hifidunio displays the frequency, but if I understand this well, it would be possible to display and adjust as well?

Yes, Hifidunio is a good solution of external control. In this case, Hifidunio can have its own Fmclk and Fs combination. No any problem display the FIFO status and frequencies, as well as take over the frequency switching control within the window time.

Ian

[hochopeper]

Thanks for the protocol definition Ian, I will start my own DAC controller design shortly and this info will be invaluable. I want my controller to be network accessible so I've decided to start fresh with mine. For additional integration, I might end up using my network facing controller as the playback device and integrate the playback software with the control software. More details will become evident as I start working on it I'll hopefully get started on that in the next week or two, in readiness for GBIII

One issue that has only just dawned on me is that in the Dual XO manual you refer to J12 on the FIFO board being available to be used for mute signal. You really have thought of everything already! Is anyone using this already? I haven't seen anyone asking or discussing it. However, the FIFO manual that I have saved here doesn't describe the behaviour of this output port. Maybe I'm looking at the wrong manual? What is the behaviour of this pin? Is it active high or active low, does it need an external pull up? Can this be run through isolator if i2c is not used to the dac? I was going to implement a similar mute function in my controller but if you've already done the hard work, this really might be better implemented by the FIFO directly for lower latency.


Chris

[hochopeper]

Looking at photos/manual now I can't see J12 on the FIFO board, is it on the underside Ian?

[AR2]

Originally Posted by hochopeper

Thanks for the protocol definition Ian, I will start my own DAC controller design shortly and this info will be invaluable. I want my controller to be network accessible so I've decided to start fresh with mine. For additional integration, I might end up using my network facing controller as the playback device and integrate the playback software with the control software. More details will become evident as I start working on it I'll hopefully get started on that in the next week or two, in readiness for GBIII

One issue that has only just dawned on me is that in the Dual XO manual you refer to J12 on the FIFO board being available to be used for mute signal. You really have thought of everything already! Is anyone using this already? I haven't seen anyone asking or discussing it. However, the FIFO manual that I have saved here doesn't describe the behaviour of this output port. Maybe I'm looking at the wrong manual? What is the behaviour of this pin? Is it active high or active low, does it need an external pull up? Can this be run through isolator if i2c is not used to the dac? I was going to implement a similar mute function in my controller but if you've already done the hard work, this really might be better implemented by the FIFO directly for lower latency.


Chris

That is exactly what I was thinking - player and controller in one.

[hochopeper]

Originally Posted by AR2

That is exactly what I was thinking - player and controller in one.

The challenge for you there is that to have GPIO or I2C for the ESS dac it is simplest to have an ARM based computer. I am not sure if your and qusp's LH Titan USB boards report usb power requirements in a way that will allow it to communicate with a usb port that provides less than the full 500mA USB spec. (qusp and I had trouble with his Titan one day when trying to run it from my iMac ... though that might have been a separate issue) I used to also have this issue where my WaveIO board is concerned, though Lucian has released new firmware for it in the last week or so that will allow it to communicate as a device powered not host powered. When I have something working I think qusp will be keen to try it out so I'll take it to his place and do a trial run

Worst case is it will do all of the control and playback can be via whatever you currently use, not a show-stopper!

[AR2]

Originally Posted by hochopeper

The challenge for you there is that to have GPIO or I2C for the ESS dac it is simplest to have an ARM based computer. I am not sure if your and qusp's LH Titan USB boards report usb power requirements in a way that will allow it to communicate with a usb port that provides less than the full 500mA USB spec. (qusp and I had trouble with his Titan one day when trying to run it from my iMac ... though that might have been a separate issue) I used to also have this issue where my WaveIO board is concerned, though Lucian has released new firmware for it in the last week or so that will allow it to communicate as a device powered not host powered. When I have something working I think qusp will be keen to try it out so I'll take it to his place and do a trial run

Worst case is it will do all of the control and playback can be via whatever you currently use, not a show-stopper!

If I understand you well, my LH Titan is powered separately from the USB, with power sources, one 5V and the second one 7.5V clock supply. In another word it does not draw any power from USB.
Looking forward to your progress.

[qusp]

yeah I was using USB for the 5v at the time and it reports 500ma, so if it was plugged into a hub on my mac that had nothing else plugged in it would load, if there was something else already on that hub it wouldnt. I couldnt work it out initially, because it shouldnt be that high power. I also discovered that the USB socket is terrible, creates really bad contact so would work only intermittently, I thought it was something else in my setup for ages, because combined with the above it behaved like a bad wire connection.... it had to have the usb cable levered up to force contact. replaced the connector now though, wasnt the cable, tried heaps

[slartibartfasst]

Hello, I'm not sure if this is the right thread for this question, but it seemed like the best so...

Does the backdoor I2S input on the SPDIF board pass the data stream directly to the I2S output or does it route the signal through the DIX9211?

I ask because the Tx on the DIX9211 appears to be limited to 216Khz whereas the USB-I2S interface I'm planning on using (Amanero) is capable of passing data in excess of that figure.

By the way, having slowly started to integrate these boards into a DAC, the SPDIF input board is a fantastic piece of equipment on its own, independent of the FIFO. The improvement over a PCM2707 (as a receiver - USB or optical SPDIF) solution previously used is immediately apparent (even using the PCM2707 as an optical transmitter). It seems the DIX9211 is in another league from the PCM2707, even with the DAC's (ESS9018) DPLL in place (as opposed to synchronous clocking).

Along with a digital volume control, having a switchable input turned my implementation into a minimalist digital pre-amp without using any uControllers; the box just boots up and is ready to go. Very convenient.

Thanks for the beautifully conceived, designed and executed SPDIF interface; I look forward to integrating the rest of your boards.

[qusp]

agreed, I dont know why more people dont grab it, its an incredible value and combined with fifo hard to really justify anything more for most occasions

i2s backdoor is direct i2s out