Good news Clive!
LOL. I was going to ping you/Steen tomorrow and ask if you could run a new piCorePlayer kernel build...... I think a couple of the guys with testing hardware are running piCore..... And the boards appear to have gone on sale now from the Allo web site..... Although possible to pretend it is IQaudIO hardware to get the hardware working, there are reasons not to want to do that.....
We have pCP3.02 almost ready with kernel 4.4.20. We need to get this out to solve a couple of issues with the piCore distribution... but after that, I hope it flows to piCore quickly. I am keeping an eye on this interesting thread (and your posts).
regards
Greg
I think there are a couple of things that have gone in between .20 and .21 that you want to get to your users. People masochistic enough to be using the on-board Pi3 wifi, will probably thank you for this one, brcmfmac: do not use internal roaming engine by default.
Hopefully you can do a small incremental kernel update once you have pCP3.02 released.
The interesting posts in this thread (and most others) aren't authored by me! LOL.
Thx Clive. That was pretty amazing.
We are working hard on the DSP flow , but I think it will a while before being accepted. Meanwhile enjoy your 2.0 Kali .
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.
As dimdim described above, we spent a night testing kali wth a RPI and a Kali with his buffalo. The results made kali a winner without any doubt. Kali made the music reproduction, quieter, clearer and more detailed.
I also did my tests with a mamboberry I have with similar results. I also tested with an iqaudio dac + but unfortunately this dac is not powered up when kali is in the middle.
My next test will be with Piano Dac when it arrives.
P.s. csdgames do you have any update on the issue with the reversing of the channels?
@ tuxx and Dimdim:
Given that you hear a clear improvement with Kali, I would be interested to know how the Rpi + Kali into the Buffalo now compares with whatever is your preferred reference source into that dac. Does the Rpi still lag some way behind?
John
If the channel swapped that could lead to the other lines in I2S bus inverted.
Like data bus - if data bus inverted than with channel swap you will have ot of the phase, booth channels, signal after the DAC.
...
It should be measured with osiloscope with dital signal option and check
is the master clock is at rising edge or falling edge, System clock, data, and L/R latch line too.
...
And compare vs I2S standard.
...
Someone please send pin connector datas for digital line I2S outputs?
thanks
Like data bus - if data bus inverted than with channel swap you will have ot of the phase, booth channels, signal after the DAC.
...
It should be measured with osiloscope with dital signal option and check
is the master clock is at rising edge or falling edge, System clock, data, and L/R latch line too.
...
And compare vs I2S standard.
...
Someone please send pin connector datas for digital line I2S outputs?
thanks
Yeap we got it...on the 16 bit files there was a swap and some nastiness ...seems it was fixed on new firmware.
Could you elaborate on "nastiness" please?
By the way, further to my first impressions elsewhere: I listened to Kate Bush's Ninth Wave last night in full with the Kali in place between my Pi and AYA DAC. I have never heard it so rhythmically on point. Loads of layering revealed too when the recording got busy. Miles better than using the DAC Pro+ as an I2S source.
Oscilloscope screen showed some bugs in the data compared with original i2s
Could you elaborate on "nastiness" please?
By the way, further to my first impressions elsewhere: I listened to Kate Bush's Ninth Wave last night in full with the Kali in place between my Pi and AYA DAC. I have never heard it so rhythmically on point. Loads of layering revealed too when the recording got busy. Miles better than using the DAC Pro+ as an I2S source.
Perhaps you can explain to the people how they get the new firmware onto their Kali?
Paying customers will receive exchange units for free.
Testers, we are ready to send a new Kali (up to 384Khz this time) with the corrected code. Note that the bug is only seen on 16 bits.
Thx to Dimdim for finding the problem.
Testers, we are ready to send a new Kali (up to 384Khz this time) with the corrected code. Note that the bug is only seen on 16 bits.
Thx to Dimdim for finding the problem.
Oh, I see. When I said explain.... I was thinking you were going to make a firmware file available and explain to the people with the necessary skills/ability, (of which there are more than a few on this forum), how to upload via JTAG header...... But if you are going to send them another board, that's cool too!
Yes, thank you Dimdim. It's not like anyone else even noticed the channels were swapped! LOL.
