Hmmm , we are still having discussion on what left and whats right channel..
From our tests so far looks like not reversed.
From our tests so far looks like not reversed.
I confirm what dimdim mentioned with regards to the reversing of the channels.
I did my tests with mamboberry dac and mainly Archphile (I also tried with volumio) and it seems that when kali is in the chain the channels reverse.
With regards to the sound quality it's too early for me, as most of my tests focused on the technical part and not the listening experience.
I did my tests with mamboberry dac and mainly Archphile (I also tried with volumio) and it seems that when kali is in the chain the channels reverse.
With regards to the sound quality it's too early for me, as most of my tests focused on the technical part and not the listening experience.
Ok today I had a discussion with the designer and I seen he was not sure about LR channels. However he did say that both Piano and Kali they behaved the same.
I suspect that both might be reversed ..
Now with confirmation , Kali will be fixed.
I suspect that both might be reversed ..
Now with confirmation , Kali will be fixed.
Is there a proper way to get a good spdif output from the Kali? Will you be able to make a shield for that? Many do use spdif.
thank you
Last night we got together with tuxx and a couple more friends to have a listen to the Kali in my system.
The audio chain was as such: Raspberry Pi 2 running Archphile -> Kali -> Buffalo III -> Hypex UcD400s -> my DIY floorstanders.
The RPi was powered through Kali with an SMPS capable of supplying 5V/4A.
We listened to a few test tracks both with and without Kali in the audio chain. When we were not using Kali, the RPi was powered by a second SMPS (5V/2A) of reasonable quality.
It did not take us long at all to come to the conclusion that Kali made a very substantial improvement. In fact, I can say that I haven't heard my B III perform this good before, and I am comparing the RPi+Kali combination to Amanero & XMOS designs. The difference was so obvious that our eyebrows were raised almost instantaneously.
So I can definitely say that anyone who is using an RPi as an I2S transport has a lot to gain by putting in a Kali. The RPi does indeed put out very bad sounding I2S.
Congrats to cdsgames' team for making a fine piece of hardware (and software).
Next up is teaming Kali up with my Amanero, plus of course trying out the Piano 2.1 board.
The audio chain was as such: Raspberry Pi 2 running Archphile -> Kali -> Buffalo III -> Hypex UcD400s -> my DIY floorstanders.
The RPi was powered through Kali with an SMPS capable of supplying 5V/4A.
We listened to a few test tracks both with and without Kali in the audio chain. When we were not using Kali, the RPi was powered by a second SMPS (5V/2A) of reasonable quality.
It did not take us long at all to come to the conclusion that Kali made a very substantial improvement. In fact, I can say that I haven't heard my B III perform this good before, and I am comparing the RPi+Kali combination to Amanero & XMOS designs. The difference was so obvious that our eyebrows were raised almost instantaneously.
So I can definitely say that anyone who is using an RPi as an I2S transport has a lot to gain by putting in a Kali. The RPi does indeed put out very bad sounding I2S.
Congrats to cdsgames' team for making a fine piece of hardware (and software).
Next up is teaming Kali up with my Amanero, plus of course trying out the Piano 2.1 board.
Attachments
DimDim,
Another thing worth trying is to un-power the 100mHz clock on the B-III board and feed the MCLK signal from the Kali (on the bottom of the board) to the clock output of that 100Mhz clock. That would put the ESS018 in synchronous mode and many have reported additional gains with that setup.
Many thanks for the great report. I'm working to have mine running later today, first with a MamboBerry DAC.
Greg in Mississippi
DimDim, the other thing is that the amount of improvement you reported and what I'm hearing with the Mamboberry tonight continues adding evidence that destroys the common wisdom that the ESS ASRC eliminates any effect of upstream jitter!
Got it going about 4 hours ago, want to give it MUCH more time to fully break in before a detailed report, but so far my response is "WOW!"
I am truly impressed with the amount of improvement with the Mamboberry, which was not a slouch before. Now re-thinking where to try it next.
So far have hit Maria Schneder, The Jazz Crusaders, Toy Matinee, Level 42, David Sylvain, Seal, Radka Toneff, and now on Lee Ritenour. All VERY impressive, much more music!
CDSGames, I know you've mentioned the next iteration will work with DACs running in master mode. I wonder if you and the team can come up with a configuration where the Kali 2.0 sends out a lower-jitter bit-clock (which acts as the clocking source) instead of using the one from the DAC... and then reclocks the I2S going back to the DAC.
Also, will the next version be 352/384 capable? Please?
Greg in Mississippi
Kali 2 , will work (like Kali 1) with 352/384 (with the right frequency oscilators)
If we reclock the master dac to send to SBC... you wont gain much. Remember that mclk is fed to DAC and if thats not good then Kali cannot help much..
Instead , on master DACs the main advantage is that DATA will be buffered on memory and it will be served on time.
A lot of audio apps swear that one kernel sounds better than another , some distributions shut down many processes , because DATA can be disrupted by an interrupt for example...not with Kali 2
If we reclock the master dac to send to SBC... you wont gain much. Remember that mclk is fed to DAC and if thats not good then Kali cannot help much..
Instead , on master DACs the main advantage is that DATA will be buffered on memory and it will be served on time.
A lot of audio apps swear that one kernel sounds better than another , some distributions shut down many processes , because DATA can be disrupted by an interrupt for example...not with Kali 2
Hi there Greg,
This thought did cross my mind as well. However, doing it right will require considerable work, so I'll make a note and get to it when I have the time.
I'm pretty sure that this specific "wisdom" has been demolished long ago, with the arrival of Ian's FIFO.
What I am seeing is real evidence that the RPi's I2S output is very very bad.
@John,
Mamboberry Hifi Dac+.
I've been identifying mods to make to that DAC card. Comparing it to the LS DAC+ in detail, I can see some changes they made to that DAC that should be worthwhile to do on the HiFi DAC+, especially on clock & signal transmission. From a power network perspective, the LS DAC+ might have a slight edge, but both should be close.
I'm also planning to adapt some of the techniques used by EUVL in his ES9022 DAC card and possibly some of the power supply techniques in Joe Rasmussens' alternate filtering thread.
I'll post my planned mods, progress, and results in Soundcheck's LS DAC+ thread.
Greg in Mississippi
RPi accepted a patch today for basic (2 channel stereo) support of the Allo Piano DAC boards. Once it trickles down to the distributions, enable with ...
... in /boot/config.txt.
ALSA card name is "PianoDAC", so eg. squeezelite config would be...
Scott or anyone else building from my rpi-4.4.y-simple branch, I rebased that. Although be aware that if using the Piano on top of Kali, the 384k patch set will enable 352k8 and 384k, which will result in no output from Kali for those sample rates, so assuming using squeezelite, you probably want to...
... in your squeezelite config to limit the supported rates, by explicitly listing them, to those the Kali won't have an issue with. And enable resample by exception (for non-supported sample rate), with...
Code:
dtoverlay=allo-piano-dac-pcm512x-audioALSA card name is "PianoDAC", so eg. squeezelite config would be...
Code:
-o hw:CARD=PianoDACScott or anyone else building from my rpi-4.4.y-simple branch, I rebased that. Although be aware that if using the Piano on top of Kali, the 384k patch set will enable 352k8 and 384k, which will result in no output from Kali for those sample rates, so assuming using squeezelite, you probably want to...
Code:
-r 192000,176400,96000,88200,48000,44100
Code:
-u E
Last edited: