Why worry about the digital source?

[hochopeper]

I could comment about 2 things even if I don't consider me to belong to the brains...

1) The Isolator + Local Osc; I suppose these 2 are also the Ian "FiFO" solution!? If not it looks strange.
2) LM 317... why ruin it in the end?

/

1) yep they are part of the FIFO project but I separated them as the diagram makes more sense that way IMO

2) what qusp said above, that is opc's bipolar regulator board from The Wire project and is a well executed design. I did consider getting an extra transformer and using a +/- pair of sjostrom regulators for the JG filter/buffer board, will power up that board from batteries and IF there is an appreciable difference, then I'll consider power alternatives for a PSU for that buffer board alone.

 

[abraxalito]

Here's the SS - recording was made with Sony PCM-M10 with mics about 10cm from the bass/mid unit of my left speaker. Guess the timestamp where the laptop was unplugged (and then for a bonus - plugged back in again)?

@hocho - I could understand going to all that palava for a TDA1541N1/S2 or even perhaps at a pinch for a PCM63 but for an ESS9023?

 

[TNT]

It had been strange to incorporate Ians solution with the Ffifo, Ians Isolator board + Ians regeneration and THEN add whats is referred to as Isolator and Local Osc. - that was my comment.

OK, will I find info about The Wire by searching or do I need a help with a link ?

I'll try a search....

 

[marce]

Plugged into the mains?

 

[abraxalito]

Yep, as opposed to working on internal battery.

I checked the capacitance between the S/PDIF input and the output phono grounds - 25pF give or take 2pF. The noise level varied with the loop area enclosed between the mains lead and the USB cable to the HAinfo adapter - it sounds like a distant rumble, much like the rumble from a TT but with some HF hash which varies when the cursor's moved.

 

[qusp]

It had been strange to incorporate Ians solution with the Ffifo, Ians Isolator board + Ians regeneration and THEN add whats is referred to as Isolator and Local Osc. - that was my comment.

OK, will I find info about The Wire by searching or do I need a help with a link ?

I'll try a search....

given you own one, you do realise that the fifo main board and clock board are separate right and the final reclocking is after the isolator and not done on the fifo main board? and that the waveIO has an isolated i2s output option, as hochopeper explicitly mentioned?

the diagram makes perfect sense

the wire is a headphone amp, it was at the very top of the threads in the headphone forum last time I looked, you will be able to find the measurements there with 'search this thread' the second lot, not the ones at the beginning, that was the first gen. his is the balanced input, SE output version or BAL-SE the measurements (and sound) are insanely good. brutal little headphone amp that belies its size.

 

[qusp]

Yep, as opposed to working on internal battery.

I checked the capacitance between the S/PDIF input and the output phono grounds - 25pF give or take 2pF. The noise level varied with the loop area enclosed between the mains lead and the USB cable to the HAinfo adapter - it sounds like a distant rumble, much like the rumble from a TT but with some HF hash which varies when the cursor's moved.

you are describing blitter noise

 

[qusp]

well, interference certainly got a good illustration of his confusion at the many and varied tactics/views/fantasies/issues =)

 

[Interference]

Thank you all for the contributions.

If the main problem is related to noise from the source, the obvious solution would be to use an optical interface like TOSLink so we have full electrical isolation between the source and the converter.

You tell me that TOSLink as intrinsic jitter issues, but a this point a properly designed DAC should:
- detect the incoming clock frequency
- buffer the incoming samples
- generate a local clock of the same frequency of the incoming clock
- convert the buffered samples with the locally generated clock signal

What would be the problem with this kind of approach? (I'm not an expert so I may be missing something).

 

[TNT]

given you own one, you do realise that the fifo main board and clock board are separate right and the final reclocking is after the isolator and not done on the fifo main board? and that the waveIO has an isolated i2s output option, as hochopeper explicitly mentioned?

the diagram makes perfect sense

the wire is a headphone amp, it was at the very top of the threads in the headphone forum last time I looked, you will be able to find the measurements there with 'search this thread' the second lot, not the ones at the beginning, that was the first gen. his is the balanced input, SE output version or BAL-SE the measurements (and sound) are insanely good. brutal little headphone amp that belies its size.

qusp... I think if the drawing had said Ian fifo, Ian Isolator and Ian osc, I hadn't comment on it at all. Yes, I think I have a reasonable correct view on how the thing is built up

 

[Julf]

You tell me that TOSLink as intrinsic jitter issues, but a this point a properly designed DAC should:
- detect the incoming clock frequency
- buffer the incoming samples
- generate a local clock of the same frequency of the incoming clock
- convert the buffered samples with the locally generated clock signal

What would be the problem with this kind of approach? (I'm not an expert so I may be missing something).

One small missing piece is the synchronisation between your input data buffer and wherever your data is coming from. If you have asynch USB or feed the source with your DAC clock, you are OK, otherwise you have to do something about the end-to-end synchronisation issue.

If your buffer is small, you will eventually either fill up the buffer or have an empty buffer, as the clock of your source will run slightly slow or fast compared to your DAC. If you have a large buffer, you will have significant delay/latency - a nuisance with pure, recorded audio, but a real problem with simultaneous video or a live situation.

 

[qusp]

Thank you all for the contributions.

If the main problem is related to noise from the source, the obvious solution would be to use an optical interface like TOSLink so we have full electrical isolation between the source and the converter.

You tell me that TOSLink as intrinsic jitter issues, but a this point a properly designed DAC should:
- detect the incoming clock frequency
- buffer the incoming samples
- generate a local clock of the same frequency of the incoming clock
- convert the buffered samples with the locally generated clock signal

What would be the problem with this kind of approach? (I'm not an expert so I may be missing something).

yeah tbh your query was answered in the first few posts, Julf mentioned some valid concerns with what you posted and I linked a solution that takes one of his solutions direction, use a large buffer so that the mismatch between the incoming and outgoing clock is nolonger an issue in practice.

except I would add that with recorded audio its not even a nuisance, with video you need a video player that allows you to delay the video stream to match the inherent delay from the buffer (the time it takes to half full) that time delay varies with sample-rate of course since it takes longer to half fll a buffer with less samples per second, but for video I would simply just upsample all matching audio to 96khz and have the same delay no matter the video source.

 

[Interference]

One small missing piece is the synchronisation between your input data buffer and wherever your data is coming from. If you have asynch USB or feed the source with your DAC clock, you are OK, otherwise you have to do something about the end-to-end synchronisation issue.

If your buffer is small, you will eventually either fill up the buffer or have an empty buffer, as the clock of your source will run slightly slow or fast compared to your DAC. If you have a large buffer, you will have significant delay/latency - a nuisance with pure, recorded audio, but a real problem with simultaneous video or a live situation.

Thank you Julf, I'm sorry if I forgot to mention I read your comment.

If we're talking about pure audio reproduction, latency shouldn't be an issue at all. I understand it may be an issue when we need the sync with some video output.

I think that a well designed circuit should be able to keep the latency of the whole mechanism within an acceptable threshold.

Live sound is a totally different application with different requirements.

 

[Interference]

yeah tbh your query was answered in the first few posts, Julf mentioned some valid concerns with what you posted and I linked a solution that takes one of his solutions direction, use a large buffer so that the mismatch between the incoming and outgoing clock is nolonger an issue in practice.

Yes, I've seen it and I'll give a deeper look next.

except I would add that with recorded audio its not even a nuisance, with video you need a video player that allows you to delay the video stream to match the inherent delay from the buffer (the time it takes to half full) that time delay varies with sample-rate of course since it takes longer to half fll a buffer with less samples per second, but for video I would simply just upsample all matching audio to 96khz and have the same delay no matter the video source.

Yes, but if you introduce significant delay the "solution" is no longer universal and "plug and play" as I think it should be (it's simple to set the video delay on a computer, on a TV it might be problematic).

 

[qusp]

well then you are at an impasse, there WILL be delay for video, there WILL be delay no matter what size buffer. you make it smaller, it over or under-runs more quickly

there is no way around it other than writing software that adjusts it for you, or you put up with async, which still requires some small delay normally

the delay is unavoidable.

i'm sorry but convenient one size fits all hi-end low jitter synchronous reclocking, dont mix. the other option is simply to not use video on the audio rig. weve chewed this over among hundreds of users and the designer of the fifo (one of the more brilliant men I know) since the project began.

 

[Julf]

there is no way around it other than writing software that adjusts it for you, or you put up with async, which still requires some small delay normally

Well, not sure I would use the expression "put up with" about async. Async USB is a pretty good solution, with no real downsides (if the interface is isolated).

Yes, there will be a delay - but it can be short enough that it is of the same order as the delay caused by the physical distance between the speaker and your ears.

 

[qusp]

OK right so we are now talking about designing the entire USB->i2s->isolation, reclock syncronous clock->dac? as a one off? or something like the new gen EXU21?

i've been using async USB for years with es9018 including some pretty excellent interfaces like Titan, the only one that looks like it may get it right for multichannel syncronous isolated i2s output is the next generation EXA unit and it doesnt come cheap. aside from that, anything till now is handily beaten by the fifo, particularly with its flexibility, not everything can be had through USB and I picked up the theme that Interference does not want to be tied down.

hes been describing only synchronous processes, thus my mentioning 'put up with async'

but its late, i'm bored with the back and forth at the moment mate, no offense, I just dont have the energy to argue over somebody elses minutiae, its enough work obsessing over my own minutiae thanks

 

[Interference]

Thank you all for the advice, I think I made up my mind.

In my last message I was just speculating about what an "ideal" solution would be, but I have say that the I2S FIFO solves pretty much all the problems I was thinking about in the first place.

The original idea was to use a common Android tablet or smartphone (or a more traditional laptop) as a digital source without worrying about the quality of their digital output.

The main drawback is that most modern devices have HDMI only outputs, but that's another story

Thank you all again.

 

[hochopeper]

Thank you all for the advice, I think I made up my mind.

In my last message I was just speculating about what an "ideal" solution would be, but I have say that the I2S FIFO solves pretty much all the problems I was thinking about in the first place.

The original idea was to use a common Android tablet or smartphone (or a more traditional laptop) as a digital source without worrying about the quality of their digital output.

The main drawback is that most modern devices have HDMI only outputs, but that's another story

Thank you all again.

After I receive my FIFO (it is somewhere between Canada and Aus at the moment) I am planning to do experiment and perhaps write some extra code (that I will share, if it works) that can solve the video sync issue for I hope anyone who is using a device with android, osx, linux or windows (only one I am not confident of is iOS but that is not a priority for me personally). Sorry to be a tease but I don't want to promise or suggest that it is a solved problem before I test the theory .

I agree with your idea that the best audio should be possible regardless of source, I like to think of it as 'source agnostic'. I also agree that the best audio system need not be dedicated to music only.

I agree HDMI presents a whole new world of drama that is diy-unfriendly.