Thanks, Ian. I agree audio is the first priority in this system. I want to try to investigate solutions that will allow video to be good enough while still having excellent audio that meets the audiophile requirements.
For my application, the FIFO will be in a DAC that is sitting on my desk at my computer, I want to be able to watch TV or streaming videos (normally technical presentations for example) without having to swap audio sources around. So the video is less critical in my application. I would also like to think of ways this could be applied with minimal impact on video quality, in case a multichannel FIFO ever emanates from 'iancanada labs LLC'.
I am thinking of this as a solution that is implemented by the user and should not be a burden or require any sacrifice in the FIFO development. Hopefully proposing some solutions to this issue may remove one of the hurdles that has stopped others from using the FIFO.
But just as you mentioned, there still some possibles solutions, what I could think of are:
1, Enable the audio/video delay control function on the video player.
2, Trying to up-sampling the audio stream into higher Fs, for example, 196Khz only has 1/4 delay of 48Khz, says around just 150ms.
3, Hardware based delay controler placed between player and HDTV.
Sandy is comming now
Ian
1 and 2 are the two basic approaches that I had in mind. I have some work to do to make #1 work transparently, but I believe it is possible. #2 I will try to document my proposed approach though I have no way of testing it for now.
#3 is harder to implement and would require some modification to the FIFO. I have a method in mind that passes a FIFO status to the computer and adjusts video delay accordingly. For example 1/4 full, 1/2 full, 3/4 full delays that can be set automatically by software depending on the current Fs. Is this possible on the FIFO end? I have a method in mind on the computer side.
For now integrating this with a HDTV and presumably HDMI is beyond my ability. Though if I was to think of a solution that would interface with a HDTV I would start by investigating HDMI-CEC protocols and devices like this - Pulse-Eight. Control your TV from XBMC, or vice versa! USB - CEC Adapter that may allow communication between computer and the TV and implement the delay on the HDTV end. I am not sure if HDMI-CEC allows audiosync control. Though if the same can be achieved inside the software playing the video that may be an overly cumbersome solution compared to others that we might develop. As a result my focus isn't on the HDTV end but in the computer software for now. The proprietary nature of blueray players and other devices means that it would very difficult to implement something that is universally applicable.
I have been using HDMI-CEC between my Denon AVR and Sony TV for a few years now in my lounge and it does allow very nice integration of those consumer type products. I now only use one remote and without any need for a universal remote control!
Cheers,
Chris
Last edited:
Hi guys,
I was wondering if any of you have solved this puzzle. Ian's S/PDIF board in its output uses U.FL connectors. Acko's DAC at input uses W.FL Hirose connectors. Any idea how to connect those two? I do not think they make any crossover cable that has both types of connectors. The only idea I have is to somehow switch U.FL connectors from S/PDIF board to W.FL, which I am sure is less than optimal from mechanical stand point, but I believe only possible one. Obviously my intention is to use those prefabricated cables, as they seem like really good solution.
Now I hope someone had a same problem with better idea. I absolutely hate those ultra small connectors. U.FL are quite fine and I hope Acko will replace his at some point to the bigger ones.
I was wondering if any of you have solved this puzzle. Ian's S/PDIF board in its output uses U.FL connectors. Acko's DAC at input uses W.FL Hirose connectors. Any idea how to connect those two? I do not think they make any crossover cable that has both types of connectors. The only idea I have is to somehow switch U.FL connectors from S/PDIF board to W.FL, which I am sure is less than optimal from mechanical stand point, but I believe only possible one. Obviously my intention is to use those prefabricated cables, as they seem like really good solution.
Now I hope someone had a same problem with better idea. I absolutely hate those ultra small connectors. U.FL are quite fine and I hope Acko will replace his at some point to the bigger ones.
nah thats what you have to do, they actually solder just fine in the u.fl pad and are just as robust as if they were soldered to a w.fl pad. acko uses them for the same reason he uses a 2mm pitch for analogue output, he got measurably better performance that way as it allows a tighter layout, so myself I prefer they stay, I havent had a problem with them. you can of course leave the ufl for the MCLK.
just ask that Ian supplies the board without them soldered
I presume you mean the clock board output, not spdif board
just ask that Ian supplies the board without them soldered
I presume you mean the clock board output, not spdif board
Thank you Qusp. That is what I was afraid will need to take place. I do understand reasons, just hate those little buggers. I still think they are pain. Honestly I doubt there would be a big difference between the two, but I'll just take it. As for which board, since I decided to wait for the new clock board, I still did not put together FIFO project, so I could be quite wrong if I am sending I2S out of S/PDIF or from the clock board.
I remember last time reading the manual Ian put together, and somehow I had in my mind it goes out from S/PDIF board, but I am quite possibly wrong. I am not there yet - making connections. Still trying to figureuot space within the case, and all other issues, such as this one. Both clock and S/PDIF boards are with U.FL connectors, so that is so far what I am concerned at this point. Once I get close I will make sure all is clear. I was sure MCK goes out from clock board, but the rest... I am dragging my implementation, since I am planning to get battery management board, I2S insulator board and new clock board once they become available. You know the pain of rearranging everything, that I am trying to avoid, since I was anyway late to join the group of FIFO users. Thank you anyways for the correction.
the spdif board has u.fl, but they are just optional connectors to connect to the fifo board, which again has optional u.fl to connect to the clock board. none of that has any impact on your connection to the ackodac so you can just leave them as u.fl, or as I do, just use the ribbon connectors to interconnect the boards, the only important connection is that to the dac and all of the dac connections for i2s are from the clock board, which I have changed to w.fl, but left the MCLK as u.fl to match the dac. I dont find them any more fiddly than u.fl
my post in reply to this was deleted by EXADEVICES, so perhaps it should be corrected here where he has no moderation power.
it was predictable that he would rather leave the incorrect marketing information stand while editing replies.unfortunately I thought I had saved it, but I sent hochopeper a link instead and wayback doesnt have it
it was predictable that he would rather leave the incorrect marketing information stand while editing replies.unfortunately I thought I had saved it, but I sent hochopeper a link instead and wayback doesnt have it
I was thinking about this today. It may be of value, when we move to even higher frequencies being transmitted over the cables (ie Si570 @ frequency approaching 100MHz) to use u.fl between fifo/isol/clock board. As frequencies increase the loop areas decrease and the smaller gaps between wires in ribbon/fpc cable, that were previously ok, might no longer act as we desire. While the i2s signal integrity may be ok and cleaned up by the reclocking board. We may be creating additional noise emissions within the DAC enclosures as a side-effect of pushing for ever faster frequencies. Just a thought.
My idea above is basically my thoughts following reading this article:
http://www.hottconsultants.com/pdf_files/dipoles-1.pdf
and particularly this excerpt from the last page of that article as I quoted on another thread earlier today:
My basic understanding of what I've read from other 'tech tips' on the Hott website is that separation of gnd/signal wires should not be more than 1/20th of the freq being transmitted. In our case we have to consider the harmonics generated in the creation the clock waveform, which will be dependant on the slew rate of the square wave. Anyone have any ideas on this effect and its relevance?
The GND (return path) should be adjacent to the signal, when you start getting into 100MHz signals, you can easily inroduce signal integrity problems. The main concern is avoiding impedance mismatches as you go from on board to another, and distance is also critical, they dont like going a long way, depending on the driver, receiver and cable used for transmission.
Samtecs range of high speed cables to give you an idea of what is used for high speed signal transmission:
Samtec | High Speed Cable Assemblies
Another methos widely used is either FPC/FFC connectors and cables or bespoke two plus layer flex caqbles with a ground plane and the respective connectors. Preferably the signal should travel over a contigous return plane (GND) from transmittor to receiver, or if only one or two signals then co-ax cable with rf connectors.
The frequencies that are of concern are determined by the knee frequecy:
Fknee=1/2tr where tr is the 10-90% rise time of the signal.
This is also the determining factor on whether a design is high speed, not the ultimate clock frequency.
The following links are some of the main people for signal integrity:
beTheSignal.com
Signal Consulting, Inc. - Dr. Howard Johnson
Speeding Edge consultants specialize in high-speed PCB and system design disciplines
Samtecs range of high speed cables to give you an idea of what is used for high speed signal transmission:
Samtec | High Speed Cable Assemblies
Another methos widely used is either FPC/FFC connectors and cables or bespoke two plus layer flex caqbles with a ground plane and the respective connectors. Preferably the signal should travel over a contigous return plane (GND) from transmittor to receiver, or if only one or two signals then co-ax cable with rf connectors.
The frequencies that are of concern are determined by the knee frequecy:
Fknee=1/2tr where tr is the 10-90% rise time of the signal.
This is also the determining factor on whether a design is high speed, not the ultimate clock frequency.
The following links are some of the main people for signal integrity:
beTheSignal.com
Signal Consulting, Inc. - Dr. Howard Johnson
Speeding Edge consultants specialize in high-speed PCB and system design disciplines
Thanks marce!
I have more reading to do
To be clear, my post above I was mostly thinking about the JST PH series 2.0mm pich wires that are available on the FIFO and suggesting that with the faster clocks we might be getting past their useful frequency range for i2s signals. Now I need to go and learn more about rise time, now that you mention it in that way and make me think about it again, it does seem logical that the harmonics that make up the analogue signal are related to how tight the square is on the signal and hence the rise time becomes the critical factor.
I have more reading to do
To be clear, my post above I was mostly thinking about the JST PH series 2.0mm pich wires that are available on the FIFO and suggesting that with the faster clocks we might be getting past their useful frequency range for i2s signals. Now I need to go and learn more about rise time, now that you mention it in that way and make me think about it again, it does seem logical that the harmonics that make up the analogue signal are related to how tight the square is on the signal and hence the rise time becomes the critical factor.
Thanks marce, its already tested bitperfect in loop testing at these higher frequencies, so thats no worries. As hochopeper says the concern if any will be the radiated noise. actually its possible Ian is already using the optional u.fl for these intermediate ICs, easy fix to just use them as they are already there, the other cable is FPC.
yeah I looked into getting a custom flex cable/PCB done up for my portable dac, too pricey for one off designs still at this stage.
regardless AR2, you dont need to deal with w.fl on these interconnections from spdif->fifo board->clock board, worst case would be having to use the u.fl positions instead of the ribbon; you only need the w.fl + u.fl on the i2s output from the clock board
yeah I looked into getting a custom flex cable/PCB done up for my portable dac, too pricey for one off designs still at this stage.
regardless AR2, you dont need to deal with w.fl on these interconnections from spdif->fifo board->clock board, worst case would be having to use the u.fl positions instead of the ribbon; you only need the w.fl + u.fl on the i2s output from the clock board
Last edited:
Thanks marce!
I have more reading to do
To be clear, my post above I was mostly thinking about the JST PH series 2.0mm pich wires that are available on the FIFO and suggesting that with the faster clocks we might be getting past their useful frequency range for i2s signals. Now I need to go and learn more about rise time, now that you mention it in that way and make me think about it again, it does seem logical that the harmonics that make up the analogue signal are related to how tight the square is on the signal and hence the rise time becomes the critical factor.
yeah I guess youve missed marce's posts on this before, I was intrigued to know thats what they are referring to when they say high speed layout, the rise time/slew, not necessarily the frequency
I think I had seen them but, at the time, not fully comprehended. I previously had an overly simplistic mental picture, basically I had not considered that the rise time as a proportion of the signal period could be varied to improve the signal transmission. I had fallen into what I suppose is a someone 'rookie mistake', of thinking 'the squarer is better'. Which, with a different perspective, is obviously not the case for either integrity of the signal or the radiated noise. Now I realise I was to an extent pursuing the right solutions for the wrong reasons.
I still think its a fair call to reconsider some of the transmission medium we use between these boards as we move to faster clock frequencies, especially with consideration for radiated noise, considering that we are now up to 4x the clock speed the design started with. I am not sure how much this has changed the rise time but I am guessing there has been some change in that regard also?
Last edited:
think of it the same way you would sharp edges on a baffle, at the sharp edges you get a more destructive diffraction of the sound wave that sprays harmonics out from the corner. that edge is where the change in current/transient occurs and a square will obviously be a more accelerated change than a sine for the same total energy
I guess thats also what resistive termination is about. but a balance has to be struck, we are not dealing with a digital end result, clock is very much an analogue signal, similar to more RF than digital. The edge does need to be maintained, we dont just need an accurate decision point, its somewhat more stochastic than that IMO. We cannot damp the edge too much as we are without any form of error correction, well not at the clock board anyway, we just need to be aware of the facts and minimize the negative side effects
maybe this is a good reason to use sine wave clocks?
nah I dont think anything needs reconsidering at all, there are 2 options, one has always been the easy/cheap way out, the other is good up to 6GHz. the other parts on this design have been designed for much higher speeds than the audio data from the beginning, the clock is still a long way from encroaching on that. the Si570 board will have been designed for higher speeds from the outset and all lines are terminated.
Ians background is in high speed digital medical instrumentation, pretty sure the speeds hes used to dealing with for ADCs and sensors in that area are going to be running higher speeds than here. one thing that will definitely need to be considered is how the battery packs are hooked up, most batteries are natural and inductive dipoles
I guess thats also what resistive termination is about. but a balance has to be struck, we are not dealing with a digital end result, clock is very much an analogue signal, similar to more RF than digital. The edge does need to be maintained, we dont just need an accurate decision point, its somewhat more stochastic than that IMO. We cannot damp the edge too much as we are without any form of error correction, well not at the clock board anyway, we just need to be aware of the facts and minimize the negative side effects
maybe this is a good reason to use sine wave clocks?
nah I dont think anything needs reconsidering at all, there are 2 options, one has always been the easy/cheap way out, the other is good up to 6GHz. the other parts on this design have been designed for much higher speeds than the audio data from the beginning, the clock is still a long way from encroaching on that. the Si570 board will have been designed for higher speeds from the outset and all lines are terminated.
Ians background is in high speed digital medical instrumentation, pretty sure the speeds hes used to dealing with for ADCs and sensors in that area are going to be running higher speeds than here. one thing that will definitely need to be considered is how the battery packs are hooked up, most batteries are natural and inductive dipoles
Last edited: