Scott, did they give you the driver code for the Piano DAC, or tell you it was compatible with an existing driver. eg. hifiberry? (I know it might have been a waste of time anyway, as they have said that the DAC hardware isn't going to function on the Pi, and they need to send a replacement. I'm just trying to get at, did they give you any more information with the package they sent you about which driver you were supposed to use?)
Is it possible to power the Kali from the Pi, or do you have to power both Kali and Pi via the Kali barrel connector? (You appear to be using the Kali barrel connector, to power the Kali and "back-power" the Pi via GPIO header?)
Is it possible to power the Kali from the Pi, or do you have to power both Kali and Pi via the Kali barrel connector? (You appear to be using the Kali barrel connector, to power the Kali and "back-power" the Pi via GPIO header?)
attached the 2 modifications for the Piano 2.1 (hardware to work on RPI)
Regarding powering from RPI...yes its possible but attention to the amps ...Kali itself takes up to 1.2A , then you have the DAC and maybe wifi..micro usb only provides limited power.
Regarding the hanging of the Kali (1cm) we are aware, but we had many constraints and it was a choice. We will provide an acrylic box for those that need it.
Driver...we are working on it , will update you guys today.
Regarding powering from RPI...yes its possible but attention to the amps ...Kali itself takes up to 1.2A , then you have the DAC and maybe wifi..micro usb only provides limited power.
Regarding the hanging of the Kali (1cm) we are aware, but we had many constraints and it was a choice. We will provide an acrylic box for those that need it.
Driver...we are working on it , will update you guys today.
Attachments
Scott, can you confirm you are able to do this, power the Kali from the Pi. I tried this morning and quickly (possibly incorrectly) came to the conclusion that the diode on the underside of the Kali circuit board was preventing powering Kali via the 5V GPIO pins.
I'm not sure you are understanding the points. a) I was considering putting the Kali into an existing product, which uses a custom case. The case design allows for the extra height, but not the extra depth! b) (without getting into a discussion about the EEPROM making a board HAT compliant), HAT board dimensions are 65x56mm. Now I can see how the Sparky is your priority..... But there are 10 million Pi's in the wild, which I suspect equals more opportunity to sell this to Pi owners rather than Sparky owners. One thing people are looking for when buying Pi add-on boards, is compliance with the HAT spec.
Can you just point us at the source code for what you have now for the DAC driver?
Last edited:
Hi Clive ,
I tried powering Kali from RPI...yes not possible. A diode is present.
Regarding the HAT size...we populated the board with lots of filters , LDOs (4 I think) , 2 inductors sram and fpga. We actually had a problem matching 100% the RPI.
Its not that we want to give more sales to our own SBC...its just hard to find the space. In any case this is the first version , we will have many more to come..
Driver...will update today.
I tried powering Kali from RPI...yes not possible. A diode is present.
Regarding the HAT size...we populated the board with lots of filters , LDOs (4 I think) , 2 inductors sram and fpga. We actually had a problem matching 100% the RPI.
Its not that we want to give more sales to our own SBC...its just hard to find the space. In any case this is the first version , we will have many more to come..
Driver...will update today.
Look, I'm not trying to be rude, but I'm not in the business of teaching grandma to suck eggs. You seem to be marketing this (at least as far as what I've seen on several forums) as primarily for the Pi. You need to read the HAT spec and absorb other info that is already out there, eg. virtual diode...
The smart money would have extended the board forward, above the USB and ethernet ports, not rearwards..... Which is what other people have done when space has been an issue.
Oh great, just what we need, a revision a week. Obsoleting the current board, or what was the current revision of the board from the week before.... CLUE: People who spend their "hard-earned" to purchase hardware, only to have it obsoleted a week later when a new revision is released, tend to get pissed off rather than becoming repeat customers. Release early and often with software. Do the exact opposite with hardware!
Update..... An initial driver would be good. I'm still trying to get get my head around the concept of sending hardware to people that requires a driver to operate, without providing the driver.
Now, can I get some technical info..... One of the things I wanted to be able to do was get MCLK out of the Kali board. I assume I can do that from UFL on the underside of the board? What can I expect? 22/24 for 44k1/48 multiples, or 45/49?
Last edited:
cdsgames, can you confirm that the Kali has been tested @ sample rates > 96k. I can put a tick in the box for 44k1, 48k, 88k2, 96k.... But 176k4 and 192 seem to be replaying at half speed, or at least the first second or so of the track followed by flashing lights on the Kali (LOCK and EMPTY alternate flashing).....
352k8 appears to be trying to lock at 96k (at least that is the lit sample rate LED) and playing garbage. 384k not locking at all and nothing lit and no audio output.
You can get the 384k patch set from, rpi-4.4.y-384k, the last 6 commits if you want to work on this.
Is it going to be possible to update firmware on Kali directly from RPi?
You can get the 384k patch set from, rpi-4.4.y-384k, the last 6 commits if you want to work on this.
Is it going to be possible to update firmware on Kali directly from RPi?
Hi Clive ,
I understand and share some of the point that you made.. yes I also think that above USB/Ethernet would have been better...
Now , the main function of the reclocker is to correct the i2s clocks...and it does that beautifully , with extremely low jitter.
For people that don't have a box , the advantage above might be more important that 1cm overhanging ..but again I do understand your point.
Yes UFL underneath is MCLK ...22/24 on reviewer boards but we will also offer 45/49
Regarding driver...our team fell a bit behind , we will release it soon.
Tested on RPI up to 192Khz and it works . We did not test the 384 on RPI but we tested on Sparky and 384 also works (tested on Sparky)
I understand and share some of the point that you made.. yes I also think that above USB/Ethernet would have been better...
Now , the main function of the reclocker is to correct the i2s clocks...and it does that beautifully , with extremely low jitter.
For people that don't have a box , the advantage above might be more important that 1cm overhanging ..but again I do understand your point.
Yes UFL underneath is MCLK ...22/24 on reviewer boards but we will also offer 45/49
Regarding driver...our team fell a bit behind , we will release it soon.
Tested on RPI up to 192Khz and it works . We did not test the 384 on RPI but we tested on Sparky and 384 also works (tested on Sparky)
I'll put it into my main system later and compare to Ian's FIFO, (which I already have in a RPi based setup). For the moment, just functionality testing with the dumbest board (ie. DAC in hardware config, no I2C reqd), so a PCM5102 PHAT DAC connected to a portable speaker.
Attachments
Yep looks like you figured that out, The Kali powers the pi, not the other way around (Edit: maybe a good thing, even if it's not quite standard... possibly good for less noise?). Also the Kali does not provide 3.3v on the GPIO, nor pass it thru from the pi. So any Hat will need on board reg's.
Far as I got was light the different sample rate LED's (no sound).
So that PHATDAC works? For the heck of it I tried a hifiberry dac+ pro, digi+ since the Piano is not working (nothing from those either) (I did provide ext. 3.3V to them)
Last edited:
176k4 and 192k confirmed to work just fine with normal music tracks of typical length. (I think this issue I was seeing with my 176k4 and 192k test tracks, was that they were only 10 secs long and the buffer was running empty as soon as the track started playing..... I'll diagnose that more thoroughly over the weekend.)