Allo will announce a isolator board. They seem to accept my advice.
https://allo.com/sparky/isolator.html
Good news, but too bad it's almost as expensive as the Kali board... it makes no sense but than stacking purchases... Hey it's just an isolator but sold as a marvelous funtionality ???? more expensive than some Hat dac ????
It's ok for those whom don't want to buy the Kali, but for people wanting a Kali II I would putt some isolators chips on it if it measures better ! Want to make an antenna for catching things
?
It's ok for those whom don't want to buy the Kali, but for people wanting a Kali II I would putt some isolators chips on it if it measures better ! Want to make an antenna for catching things
?@cdsgames
Would you consider Toslink input for Kali II?
If so then one could connect Chromecast Audio to Kali II through toslink.
Chromecast Audio has best usability, because you can use native apps spotify, tidal from your phone to stream.
Then I could forget about all the hassle related to RPi3/Sparky and Volumio/Runaudio updates.
Another option would be to build Toslink receiver of RPi3/Sparky footprint. Then one could simply replace RPi3/Sparky with such board, put any existing RPi3 HAT DAC on top of it and then connect to Chromecast Audio
Best, best, best if one uses mostly tidal or spotify for streaming of course.
Would you consider Toslink input for Kali II?
If so then one could connect Chromecast Audio to Kali II through toslink.
Chromecast Audio has best usability, because you can use native apps spotify, tidal from your phone to stream.
Then I could forget about all the hassle related to RPi3/Sparky and Volumio/Runaudio updates.
Another option would be to build Toslink receiver of RPi3/Sparky footprint. Then one could simply replace RPi3/Sparky with such board, put any existing RPi3 HAT DAC on top of it and then connect to Chromecast Audio
Best, best, best if one uses mostly tidal or spotify for streaming of course.
Last edited:
I took it from a IanCanada manual or post iirc, but it seems things are more complex, look at here the answer of Braxie here : http://www.diyaudio.com/forums/digi...rips-discrete-r2r-multibit-2.html#post5104783
Anyway those cables are among the best at highs frequencies to link two boards : 50 ohms matching impedance so they have their own gnd return path and are shielded as well ! The shorter the conexion seems always the better !
Anyway those cables are among the best at highs frequencies to link two boards : 50 ohms matching impedance so they have their own gnd return path and are shielded as well ! The shorter the conexion seems always the better !
Last edited:
Good news, but too bad it's almost as expensive as the Kali board... it makes no sense but than stacking purchases... Hey it's just an isolator but sold as a marvelous funtionality ???? more expensive than some Hat dac ????
It's ok for those whom don't want to buy the Kali, but for people wanting a Kali II I would putt some isolators chips on it if it measures better ! Want to make an antenna for catching things
The isolator doesn't looks so simple.
http://www.diyaudio.com/forums/pc-based/300075-isolator-board-rpi-i2s-i2c-3.html#post5075477
I know IanCanada is also making a standalone isolator Pi hat... This is more this fame of multi boards which is borring me... fragile, expensive, certainly EMI trap... maybe not so good for digital stuffs than the feeling the consumer can be an actor of a Lego DIY...
But I see it as an improvement in relation to the usual mortgage hifi ! sold your car for a dac ? No thanks !
But I see it as an improvement in relation to the usual mortgage hifi ! sold your car for a dac ? No thanks !
Even worse, the isolator is not at the most appropriate place.
Currently I use ES9038 DAC, with Crystek CVSS-945 true sine wave output clock, 100MHz async mode.
I'm just curious how the ES9038's internal clock regen performs relative to different diyer reclocker boards.
Anyhow, the old ES9018 double chip DAC board is not in pair with the new ES9038, the newer chip has a new clock regen algorithm. There are also other changes, so better performance is possibly not due to the new algorithm alone.
Currently I use ES9038 DAC, with Crystek CVSS-945 true sine wave output clock, 100MHz async mode.
I'm just curious how the ES9038's internal clock regen performs relative to different diyer reclocker boards.
Anyhow, the old ES9018 double chip DAC board is not in pair with the new ES9038, the newer chip has a new clock regen algorithm. There are also other changes, so better performance is possibly not due to the new algorithm alone.
Last edited:
0 isolator board seems to be just enough. But an isolator chip after the FPGA worth to try. If not good for anyone, it can be bypassed. I suggested this for Kali 2 previously, without any result. OK, if they can sell an isolator board positioned before the noisy FPGA, or a Kali2 without bypassable isolator chip after the FPGA, they do it right.
Note, Twisted Peer Audio has an elegant solution for reclocking, called Chronus board. They do not use noisy FPGA at all, calculation is done in the audio server's Unix layer. They also don't use FIFO. It consists of minimal hardware + a good Botic driver. Though it has a disadvantage: it's limited to one less popular SBC currently.
But the main question is: ESSTECH new clock regen algorithm applied in the ES9038 worth to be replaced with one of the diyers solution?
Note, Twisted Peer Audio has an elegant solution for reclocking, called Chronus board. They do not use noisy FPGA at all, calculation is done in the audio server's Unix layer. They also don't use FIFO. It consists of minimal hardware + a good Botic driver. Though it has a disadvantage: it's limited to one less popular SBC currently.
But the main question is: ESSTECH new clock regen algorithm applied in the ES9038 worth to be replaced with one of the diyers solution?
@cdsgames
Would you consider Toslink input for Kali II?
If so then one could connect Chromecast Audio to Kali II through toslink.
Chromecast Audio has best usability, because you can use native apps spotify, tidal from your phone to stream.
Then I could forget about all the hassle related to RPi3/Sparky and Volumio/Runaudio updates.
Another option would be to build Toslink receiver of RPi3/Sparky footprint. Then one could simply replace RPi3/Sparky with such board, put any existing RPi3 HAT DAC on top of it and then connect to Chromecast Audio
Yes we are
Completely different tech... ess sabre is asynch but extremly well implemented with lots of math wizardry ..but in the end still asynch. Kali is bit perfect. As simple as that.
I try to keep up Greg
but gonna be a bit tough on the BOSS, because they're aiming for the fence. It's the way to go if just plugging it in and not worrying about it... and it's delicious on my headphone setup (tubes and solid state). Here's a pic, I'm running them 24/7 before back to the big system! I hope the bass settles in. Trust me, moved my speakers practically into the center of the room, different speakers, ml decent subs off/on/tuned etc...!!! But that was only with about ~24 hours play time on them.Attachments
Last edited:
Both sync & async has it pros and cons. I remember how sync systems depends on the cable used to connect clock, when clock is relatively far from the DAC chip. While easy to find cables providing bit perpect transfer, the sound is different with different cables. Maybe audio can't be simplified to the bit perfect question.
Hi.
Quick update.
Allo is still working on getting "the patch" into the kernel git.
I was a bit surprised though to learn last week that that early dual-mono patch
I received was supposed to be it!?!?
I had issues with it and on top I gave feedback related to the Piano21 documentation, terminology, DSP files and additional features.
From my perspective the whole project required an overhaul.
The response I received last week: "We look into it."
Bottom line, the way forward will look like this:
1. Allo needs to get their stuff together
2. The RPI kernel git sources needs to be updated accordingly ( using patches - speaking for Moode - is a NoGo )
3. The new kernel sources need to be integrated and tested by the OS maintainers
4. The new functionality associated to e.g. selecting the new dual mono modes need to be integrated
tested and documented by the OS maintainers (e.g. Tim would have to update the GUI)
5. And then that new functionality needs to be launched within one of the next OS releases
Speaking for Moode, all that can take a while, especially if bullet "1." is still outstanding.
PcP and the other OSes won't do it much differently. Some might introduce "quick and dirty" early stage patches.
Allo should develop an awareness that they are at the beginning of the chain and a success of a product highly depends and getting things right exactly at that point.
Cheers
Quick update.
Allo is still working on getting "the patch" into the kernel git.
I was a bit surprised though to learn last week that that early dual-mono patch
I received was supposed to be it!?!?
I had issues with it and on top I gave feedback related to the Piano21 documentation, terminology, DSP files and additional features.
From my perspective the whole project required an overhaul.
The response I received last week: "We look into it."
Bottom line, the way forward will look like this:
1. Allo needs to get their stuff together
2. The RPI kernel git sources needs to be updated accordingly ( using patches - speaking for Moode - is a NoGo )
3. The new kernel sources need to be integrated and tested by the OS maintainers
4. The new functionality associated to e.g. selecting the new dual mono modes need to be integrated
tested and documented by the OS maintainers (e.g. Tim would have to update the GUI)
5. And then that new functionality needs to be launched within one of the next OS releases
Speaking for Moode, all that can take a while, especially if bullet "1." is still outstanding.
PcP and the other OSes won't do it much differently. Some might introduce "quick and dirty" early stage patches.
Allo should develop an awareness that they are at the beginning of the chain and a success of a product highly depends and getting things right exactly at that point.
Cheers
Last edited:
Hi everyone,
I posted on another thread, but I think I better try asking here.
http://www.diyaudio.com/forums/digi...1-fifo-universal-i2s-pcm-driver-board-89.html
Recently, I assembled a dac with the following hardware combination with no luck.
Volumio - Rpi3 - kali reclocker - ian pcm board - AD1865/PCM1702 board - opamp IV
I did checked for dc offset at the output before inputting a 400hz signal (from youtube thru volumio). The frequency measured thru DMM doesnt show a 400hz, but it shows frequency fluctuating at a few thousands hertz. Out of curiosity, I connected it to my amplifier & speaker, only to hear pink noise.
Assuming i2s data (with mclk) is a standard, I wonder if anyone have tried connecting kali to ian pcm board?
I have no problem connecting the kali i2s data to TDA1543/passive IV. It is playing music, but the output level is low.
Regards,
Cheng
I posted on another thread, but I think I better try asking here.
http://www.diyaudio.com/forums/digi...1-fifo-universal-i2s-pcm-driver-board-89.html
Recently, I assembled a dac with the following hardware combination with no luck.
Volumio - Rpi3 - kali reclocker - ian pcm board - AD1865/PCM1702 board - opamp IV
I did checked for dc offset at the output before inputting a 400hz signal (from youtube thru volumio). The frequency measured thru DMM doesnt show a 400hz, but it shows frequency fluctuating at a few thousands hertz. Out of curiosity, I connected it to my amplifier & speaker, only to hear pink noise.
Assuming i2s data (with mclk) is a standard, I wonder if anyone have tried connecting kali to ian pcm board?
I have no problem connecting the kali i2s data to TDA1543/passive IV. It is playing music, but the output level is low.
Regards,
Cheng
