I have an issue with my Kali in my setup. I wonder if anyone can reproduce?
HW: RPi3 (onboard wifi enabled) / Kali / Piano 2.0 DAC
SW: Jessie Lite / Clive's 4.4.y-simple kernel / Clive's 4.4.y-simple allo DAC overlay / Squeezelite from Raspian repository
(I believe the Kali is a 44/48Mhz model.)
Tracks with 44k/88k/176k sample rate play fine no problems. Lock is received immediately on Kali.
When I play any track from the 48k/96k/192k sample rate family a few seconds of the track is played and then audio cuts out and the Lock and Empty LEDs flash alternately. The rate of LED flashing increases in line with increasing sample rate. This behaviour locks up the RPi3.
All sample rates play perfectly with the Kali removed and Piano DAC connected directly to the RPi3.
I need to try playing different sample rate files directly via aplay but thought I would note this issue in case it's been seen by anyone else. Also I will give some other distros a try. I'll try some other overlays as well.
HW: RPi3 (onboard wifi enabled) / Kali / Piano 2.0 DAC
SW: Jessie Lite / Clive's 4.4.y-simple kernel / Clive's 4.4.y-simple allo DAC overlay / Squeezelite from Raspian repository
(I believe the Kali is a 44/48Mhz model.)
Tracks with 44k/88k/176k sample rate play fine no problems. Lock is received immediately on Kali.
When I play any track from the 48k/96k/192k sample rate family a few seconds of the track is played and then audio cuts out and the Lock and Empty LEDs flash alternately. The rate of LED flashing increases in line with increasing sample rate. This behaviour locks up the RPi3.
All sample rates play perfectly with the Kali removed and Piano DAC connected directly to the RPi3.
I need to try playing different sample rate files directly via aplay but thought I would note this issue in case it's been seen by anyone else. Also I will give some other distros a try. I'll try some other overlays as well.
Last edited:
All works OK with Raspbian Jessie Lite and using play so must be a Squeezelite issue, will see what I can change regarding the output format there.
Last edited:
I'm sorry to say this, but as of today, 16/10/2016, I have zero interest in anything to do with Allo or their products.
I do not know if or when they are going to release (or be able to release) a driver and firmware to fully support their Piano 2.1 board under open source compatible licensing.. Please do not contact me (whether that be via PM or email) to ask any questions regarding Allo or their products. I do not work for Allo!
I offered to submit a PR for a basic driver to PiF github, which I did, and which was accepted. The "fully functional" driver code that I received from Allo was not of sufficient quality to even consider submitting it to PiF github.
TI still need to state under which license the DSP firmware can be released. On Friday, the latest update to me from Ioan was that, "Yesterday we spoke to TI regarding the DSP files...basically they told us that they are aware and our situation was escalated to another level because they did not have the answer. So we should have an answer in 24-48h". Please contact Ioan directly, <ioan_AT_allo.com>, for further information, not me!
I do not know if or when they are going to release (or be able to release) a driver and firmware to fully support their Piano 2.1 board under open source compatible licensing.. Please do not contact me (whether that be via PM or email) to ask any questions regarding Allo or their products. I do not work for Allo!
I offered to submit a PR for a basic driver to PiF github, which I did, and which was accepted. The "fully functional" driver code that I received from Allo was not of sufficient quality to even consider submitting it to PiF github.
TI still need to state under which license the DSP firmware can be released. On Friday, the latest update to me from Ioan was that, "Yesterday we spoke to TI regarding the DSP files...basically they told us that they are aware and our situation was escalated to another level because they did not have the answer. So we should have an answer in 24-48h". Please contact Ioan directly, <ioan_AT_allo.com>, for further information, not me!
I'm sorry to say this, but as of today, 16/10/2016, I have zero interest in anything to do with Allo or their products.
I do not know if or when they are going to release (or be able to release) a driver and firmware to fully support their Piano 2.1 board under open source compatible licensing.. Please do not contact me (whether that be via PM or email) to ask any questions regarding Allo or their products. I do not work for Allo!
I offered to submit a PR for a basic driver to PiF github, which I did, and which was accepted. The "fully functional" driver code that I received from Allo was not of sufficient quality to even consider submitting it to PiF github.
TI still need to state under which license the DSP firmware can be released. On Friday, the latest update to me from Ioan was that, "Yesterday we spoke to TI regarding the DSP files...basically they told us that they are aware and our situation was escalated to another level because they did not have the answer. So we should have an answer in 24-48h". Please contact Ioan directly, <ioan_AT_allo.com>, for further information, not me!
I do not know if or when they are going to release (or be able to release) a driver and firmware to fully support their Piano 2.1 board under open source compatible licensing.. Please do not contact me (whether that be via PM or email) to ask any questions regarding Allo or their products. I do not work for Allo!
I offered to submit a PR for a basic driver to PiF github, which I did, and which was accepted. The "fully functional" driver code that I received from Allo was not of sufficient quality to even consider submitting it to PiF github.
TI still need to state under which license the DSP firmware can be released. On Friday, the latest update to me from Ioan was that, "Yesterday we spoke to TI regarding the DSP files...basically they told us that they are aware and our situation was escalated to another level because they did not have the answer. So we should have an answer in 24-48h". Please contact Ioan directly, <ioan_AT_allo.com>, for further information, not me!
Iaon
Do you have any ideas what the issue with Kali and Squeezelite could be when using 48k Fs family?
Occasionally I can get Kali to work with 48k sample rates, but I cannot get it to work repeatably. If I restart Squeezelite, or reboot the RPi3 with Kali remaining powered (I have removed the backpower jumper) then sometimes 48k will work. I cannot reliably recreate this. I am guessing (wildly, no doubt) that somehow the Kali gets set to a state where it's happy playing 48k Fs material, and once it's in that state all is OK.
(I have a 44/48Mhz Kali. I wonder if the behaviour is the same for the 22/24Mhz Kali?)
Any suggestions? I'm happy to help diagnose the issue, or provide the images I'm using for your guys to take a look.
Hi ,
we have tested the 48Khz family sample rate with multiple players on multiple SBCs (Vana , RPI 2) and it works fine
I know that RPI3 especially with wifi (on board enabled )is a bit buggy so we suspect the issue is from there...anyway I sent you an email.
we have tested the 48Khz family sample rate with multiple players on multiple SBCs (Vana , RPI 2) and it works fine
I know that RPI3 especially with wifi (on board enabled )is a bit buggy so we suspect the issue is from there...anyway I sent you an email.
Just received a Kali and Allo's recommended 5v 3A power supply.
I have plugged the Kali in between a rPi2+ and a ES9023 DAC (the cheap Chinese version of the Audiophonics) and with no change to software it works !
I'm running piCorePlayer 3.02
Only tried it on headphones so far so haven't done any serious listening, however as I suspected, the Kali's buffer plays havoc with synchronization with the Kali equipped pCP lagging, The volume levels seem fairly close, also I have only tried 44.1 / 16 .
I have plugged the Kali in between a rPi2+ and a ES9023 DAC (the cheap Chinese version of the Audiophonics) and with no change to software it works !
I'm running piCorePlayer 3.02
Only tried it on headphones so far so haven't done any serious listening, however as I suspected, the Kali's buffer plays havoc with synchronization with the Kali equipped pCP lagging, The volume levels seem fairly close, also I have only tried 44.1 / 16 .
I've been following this topic from the start and finaly got my own Kali reclocker on its way to my audio setup. Got some questions someone here might be able to awnser.
I've come across two possible ways to connect mclk; one via the u.fl connector, another via pin 29 normaly used to connect to a hat dac. I would prefer to use the pin, but if this gives the same result, why is there a seperate u.fl connectection for mclk? And if i better use the u.fl connection, where to connect the ground on the other side (i2s over hdmi module), where the mclk connection is a single solder point.
My other question is about the power supply. I'm powering my RPI and current Hifiberry Dac+ Pro via an 5v linear power supply. Can i use the 5v input pins next to the round power connection on Kali? I've seen a picture where its done, but also one where the pins are markt as "for testing only".
Once in working order, i'll report my findings, can't wait to find out what his reclocker does for my setup.
I've come across two possible ways to connect mclk; one via the u.fl connector, another via pin 29 normaly used to connect to a hat dac. I would prefer to use the pin, but if this gives the same result, why is there a seperate u.fl connectection for mclk? And if i better use the u.fl connection, where to connect the ground on the other side (i2s over hdmi module), where the mclk connection is a single solder point.
My other question is about the power supply. I'm powering my RPI and current Hifiberry Dac+ Pro via an 5v linear power supply. Can i use the 5v input pins next to the round power connection on Kali? I've seen a picture where its done, but also one where the pins are markt as "for testing only".
Once in working order, i'll report my findings, can't wait to find out what his reclocker does for my setup.
@cdsgames, is the RPi's 3.3V still not passed through?
One specific application where it would be handy to have the 3.3V pass through is for use with the Soekris dam1021. The Soekris dam1021 requires 3.3V input along with the i2s because it has an isolator that needs to be powered. So a "default" RPi can provide that natively, but it looks like using the Allo Kali would require a separate 3.3V supply.
(Granted, the Soekris has its own reclocker after the isolation, so in theory the Kali would be redundant anyway. Despite that, I've read subjective reports of improvements when using better I2S devices.)
One specific application where it would be handy to have the 3.3V pass through is for use with the Soekris dam1021. The Soekris dam1021 requires 3.3V input along with the i2s because it has an isolator that needs to be powered. So a "default" RPi can provide that natively, but it looks like using the Allo Kali would require a separate 3.3V supply.
(Granted, the Soekris has its own reclocker after the isolation, so in theory the Kali would be redundant anyway. Despite that, I've read subjective reports of improvements when using better I2S devices.)
Where did you get that from? Who told you that Pin29 could be used for MCLK? Unless ALLO have done something strange, Pin29 should be GPIO21, pass-through from the RPi, IIRC.
Had a quick thought on the Kali...
Should it be called a "reclocker" ? -- maybe a better choice be a "clocker" (or something like that)
...seems that term may be watering down what this thing really is.
There are so many dime-a-dozen "reclockers" out there... usb-->usb usb-->spdif spdif-->spdif etc. etc. etc.
Isn't this the purest form it could be, taking the i2s (PCM) straight to the FIFO, then clocked with the flip-flops?
Should it be called a "reclocker" ? -- maybe a better choice be a "clocker" (or something like that)
...seems that term may be watering down what this thing really is.
There are so many dime-a-dozen "reclockers" out there... usb-->usb usb-->spdif spdif-->spdif etc. etc. etc.
Isn't this the purest form it could be, taking the i2s (PCM) straight to the FIFO, then clocked with the flip-flops?
Last edited:
Question... I've not been able to get my modified HiFiBerry DAC+ Pro to work with a Kali. I have updated the config.txt to add the dtoverlay slave parameter (I've seen it listed as either ',slave' or ',slave=on', tried both).
This is on PCP 1.22 (which I prefer sonically, however I've not tried anything newer than 2.05) and PCP 2.05.
Do I need to try a newer version of PCP or am I missing something else?
TIA!
Greg in Mississippi
P.S. I just posted some comments on the Uptone Audio LPS-1 Listening thread over on CA, the R-Pi->Kali->various DAC HATs are quite improved using 1 or 2 LPS-1 supplies in place of my DIY linear supplies, my modified HFBD+P even sans Kali was stunning, need to hear it on a Kali!
This is on PCP 1.22 (which I prefer sonically, however I've not tried anything newer than 2.05) and PCP 2.05.
Do I need to try a newer version of PCP or am I missing something else?
TIA!
Greg in Mississippi
P.S. I just posted some comments on the Uptone Audio LPS-1 Listening thread over on CA, the R-Pi->Kali->various DAC HATs are quite improved using 1 or 2 LPS-1 supplies in place of my DIY linear supplies, my modified HFBD+P even sans Kali was stunning, need to hear it on a Kali!