Home of the Squeezebox™ & Transporter® network music players.
Page 2 of 5 FirstFirst 1234 ... LastLast
Results 11 to 20 of 49
  1. #11
    Senior Member sckramer's Avatar
    Join Date
    Oct 2008
    Posts
    282
    Quote Originally Posted by JackOfAll View Post
    Scott,

    Soldering is always therapeutic, unless you do it for a living.....

    Do you have a fully working Kali now, without any of the firmware bugs?
    Ahh, you love it ;P

    Heck no, I still have the funky kali that at times goes in that bizarre .7 second loop, like a skipping record (hey, at least we know it's working) I've emailed Ioan about it, was gonna send a new one, but I think more problems cropped up--

    FYI @iancanada is back in town, he's further along after all--> if you didn't see this already:

    http://www.diyaudio.com/forums/pc-ba...decoder-6.html

    He just now started the GB...

    related: http://www.superbestaudiofriends.org...e-9#post-89017
    Last edited by sckramer; 2016-10-23 at 22:25.
    Scott Kramer - AudioSystem - YouTube - Twitter

  2. #12
    Senior Member
    Join Date
    Apr 2010
    Posts
    729
    Quote Originally Posted by badboygolf16v View Post
    I'm starting this thread as a request for information from JackOfAll. I thought it might be useful to have this information on a separate thread that others could easily find. I suspect there may be a reasonable amount of interest in the KALI Reclocker.

    Allo have released an interesting product called the KALI Reclocker that will provide a low jitter I2S input to Raspberry Pi DACs. KALI will only work with DACs that operate in Slave mode.

    I believe I'm correct to say that some DACs that work in Slave mode are the Mamboberry LS and the Allo Piano DACs. DACS that work in Master mode are the HiFiBerry and IQaudIO DACs - therefore they do not work with the KALI.

    Now I would like to give the KALI a try, but unfortunately I only have an IQaudIO DAC+ and a HiFiBerry DAC+ Pro.

    I have seen posts on diyAudio that indicate there are patch sets that may allow these DACs that run in Master mode by default to run in Slave mode.

    I wondered if this was correct? And if so, are these kernel or driver patches? Would that guarantee these DACs would work with the KALI, or would testing be required for confirmation.

    Thanks in advance Clive.
    This makes no sense to me. AFAIK there is pretty much zero point in 12s with the dac as slave. if you already have a dac which works the right way (ie with the dac as master) why seek out a dac which does it the wrong way so that you can buy another item to alleviate the problem caused by the dac working the wrong way? It seems like you want to get someone to put a hole in your roof so you can try out an umbrella. This would only make sense if the dac with a master clock has a really useless clock. IN that case I think you'd be better off buying a dac with a decent internal clock.

    If I have misunderstood this then I would be delighted to have it explained to me why one might prefer a dac in slave mode.

  3. #13
    Senior Member JackOfAll's Avatar
    Join Date
    Dec 2005
    Location
    London, UK
    Posts
    2,749
    Quote Originally Posted by adamdea View Post
    This would only make sense if the dac with a master clock has a really useless clock. IN that case I think you'd be better off buying a dac with a decent internal clock.
    Nail on the head..... Both of the two "master" HAT boards that are commonly available are "flawed"..... (And no, I'm not going to expand on that! )

  4. #14
    Senior Member
    Join Date
    Apr 2010
    Posts
    729
    Quote Originally Posted by JackOfAll View Post
    Nail on the head..... Both of the two "master" HAT boards that are commonly available are "flawed"..... (And no, I'm not going to expand on that! )
    Perhaps someone will be able to publish some measurements demonstrating the superiority of the kali + slave solution for those boards.
    Does the same apply to the audiophonics product?

  5. #15
    Senior Member JackOfAll's Avatar
    Join Date
    Dec 2005
    Location
    London, UK
    Posts
    2,749
    Quote Originally Posted by adamdea View Post
    Perhaps someone will be able to publish some measurements demonstrating the superiority of the kali + slave solution for those boards.
    Does the same apply to the audiophonics product?
    Maybe Greg or Scott, or someone who has used the HB DAC+ Pro in master mode without Kali, and compared to same DAC+ Pro in slave, but with Kali, can post their impressions.

    Since Allo called me a liar, I'm not inclined to want to say anything positive about any of their products in public, even if it is justified.

  6. #16
    Senior Member
    Join Date
    Apr 2010
    Posts
    729
    Quote Originally Posted by JackOfAll View Post
    Maybe Greg or Scott, or someone who has used the HB DAC+ Pro in master mode without Kali, and compared to same DAC+ Pro in slave, but with Kali, can post their impressions.

    Since Allo called me a liar, I'm not inclined to want to say anything positive about any of their products in public, even if it is justified.
    I see. Anyway does the audiophonics product suffer the same weakness as the others?

  7. #17
    Senior Member JackOfAll's Avatar
    Join Date
    Dec 2005
    Location
    London, UK
    Posts
    2,749
    Quote Originally Posted by adamdea View Post
    I see. Anyway does the audiophonics product suffer the same weakness as the others?
    In general terms, IMHO, the Sabre design using on-chip ASRC with a semi-decent single freq local OSC, will benefit less from Kali (or re-clocking in general) than a PCM5xxx series design where the DAC PLL is dependent on the MASH'd Pi BCLK. However, if you use the MCLK from the Kali NDK 44/48M OSC's to drive the Sabre SYNC, and disable the OSC on the Sabre HAT, you might have different results. I have opinions, rather than validated scientific results, which is why I'm being somewhat vague.

  8. #18
    Senior Member
    Join Date
    Apr 2010
    Posts
    729
    Quote Originally Posted by JackOfAll View Post
    In general terms, IMHO, the Sabre design using on-chip ASRC with a semi-decent single freq local OSC, will benefit less from Kali (or re-clocking in general) than a PCM5xxx series design where the DAC PLL is dependent on the MASH'd Pi BCLK. However, if you use the MCLK from the Kali NDK 44/48M OSC's to drive the Sabre SYNC, and disable the OSC on the Sabre HAT, you might have different results. I have opinions, rather than validated scientific results, which is why I'm being somewhat vague.
    Does that mean that the sabre design is treating the input as S/PDIF, neither mastering nor slaving to the pi's clock?

  9. #19
    Senior Member JackOfAll's Avatar
    Join Date
    Dec 2005
    Location
    London, UK
    Posts
    2,749
    Quote Originally Posted by adamdea View Post
    Does that mean that the sabre design is treating the input as S/PDIF, neither mastering nor slaving to the pi's clock?
    No, it's still accepting an I2S input, and on-paper it's slave to Pi, by which the Pi is sending BCLK and LRCK to DAC as well as DATA..... But the Sabre board local OSC and on-chip ASRC, is re-clocking it internally, on the Sabre chip. (And if you buy into the Sabre white-papers about their hyperstream technology and jitter reduction, kind of getting you to the same point as external re-clocking taking place.... but then you start the whole new discussion with many people preferring to disable the ASRC by using MCLK that is multiple of sample rate. And that's a whole new can of worms. I personally don't have a problem with Sabre ASRC, and my wisdom says put all the money into one very high quality OSC and use the Sabre ASRC, rather than splitting funds between 2x OSC's for 44k1/48k multiples. One mans junk is another mans treasure.... )

  10. #20
    Senior Member
    Join Date
    Apr 2010
    Posts
    729
    Quote Originally Posted by JackOfAll View Post
    No, it's still accepting an I2S input, and on-paper it's slave to Pi, by which the Pi is sending BCLK and LRCK to DAC as well as DATA..... But the Sabre board local OSC and on-chip ASRC, is re-clocking it internally, on the Sabre chip. (And if you buy into the Sabre white-papers about their hyperstream technology and jitter reduction, kind of getting you to the same point as external re-clocking taking place.... but then you start the whole new discussion with many people preferring to disable the ASRC by using MCLK that is multiple of sample rate. And that's a whole new can of worms. I personally don't have a problem with Sabre ASRC, and my wisdom says put all the money into one very high quality OSC and use the Sabre ASRC, rather than splitting funds between 2x OSC's for 44k1/48k multiples. One mans junk is another mans treasure.... )
    Thanks. Sorry if i didn't express myself well that's pretty much what I meant by the sabre treating the input as though it were S/PDIF. I assume that the LRCLK is ignored by the Sabre. Or does it actually do something?

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •