Ok, it works, but I get some crackling during music playback. See here for details. Any ideas how to debug this?
I have been using kali reclocker with RoonBridge on a Rpi2 (DietPi distrib) with no issues. I2S goes straight to my DAC (actually a digital amplifier). No problems and sounds good.
Tidal/MQA files over RPI/Kali ?
Hopkins, not sure do you mean RPI/Kali works fine with Tidal/MQA?
Hopkins, not sure do you mean RPI/Kali works fine with Tidal/MQA?
Experimenting with the Piano a bit...
i2s w/(MCLK) straight in (no pi)
Interesting thing is both Dac chips are active... less load on the LT3042's ? -- when I hook right on one, left on the other?
And the generic ESS9023,384K i2s option works, and both Dac's are active...
Ioan, wonder if this is utilizing MCLK (the PLL bypass) that we've discussed, since we know the allo/hifiberry/iqaudio PCM51xx based driver does not utilize mclk, even though it is there.
i2s w/(MCLK) straight in (no pi)
Interesting thing is both Dac chips are active... less load on the LT3042's ? -- when I hook right on one, left on the other?
And the generic ESS9023,384K i2s option works, and both Dac's are active...
Ioan, wonder if this is utilizing MCLK (the PLL bypass) that we've discussed, since we know the allo/hifiberry/iqaudio PCM51xx based driver does not utilize mclk, even though it is there.
Attachments
Last edited:
Just an update on the issue of the filters: I made some measurements of the filters for the Piano 2.1 in Volumio and found that there is indeed a big drop in frequency response at the crossover points. I reported this to Allo, and they are in the process of revising the filters.
Sckramer , yes all our drivers use the MClk. Jonners seems the issue is with TI DSP algo , we reported the bug but I bet it will take a while for TI to fix it. Meanwhile we just changed from LR to another filter. Last I heard it was working fine.
Hello Everyone, this is my first post on this particular thread but I have interacted with a few of you on the DDDAC 1794 thread here : http://www.diyaudio.com/forums/digi...pcm1794-waveio-usb-input-612.html#post5018833
I am facing issues with 32bits setting in the conf.mpd file which is not retaining the changes made to it, neither the bit depth nor the sampling rate.
Can someone please refer to the post#6098, 6100, 6101, 6103, 6104, 6107, 6109 & 6110 and try to provide me with a solution? I really need to make this work.
Thanks.
I am facing issues with 32bits setting in the conf.mpd file which is not retaining the changes made to it, neither the bit depth nor the sampling rate.
Can someone please refer to the post#6098, 6100, 6101, 6103, 6104, 6107, 6109 & 6110 and try to provide me with a solution? I really need to make this work.
Thanks.
Yes, I did. So it means that it is the end of the road for this setup? Is not rectifiable? I understand that some people owing the same dac have been able to make the combo work?
Do you feel that a forced 32 bit depth from sparky/volumio is causing this concern? Few folks who were able to play the signal as is (16bits/24bits) were able to take the crackling sound away.
Anywhere that you can help?
Also, the mpd.conf file doesn't retain the settings for either the bit depth or the sampling rates despite a proper save of the file. Upon reboot, it goes back to the default. Any solutions to that as well?
That probably has to do with your distribution of choice. It probably "fixes" your custom setting upon reboot by applying its own configuration. I don't suppose it's Volumio?
I use Raspbian with mpd or Archphile and none of them exhibit this problem. Whenever I edit mpd.conf, it stays edited.
You could also try Moode. It has built-in support for resampling so you could try some 16bit or 24bit settings and see if that helps. But I don't think it has an option for doing just padding of the bits, without also doing resampling.
I use Raspbian with mpd or Archphile and none of them exhibit this problem. Whenever I edit mpd.conf, it stays edited.
You could also try Moode. It has built-in support for resampling so you could try some 16bit or 24bit settings and see if that helps. But I don't think it has an option for doing just padding of the bits, without also doing resampling.
@cdsgames - i got some replies on the L vs R justified concept on the other thread. Would be great if you can read these posts and share any suggestion to make it work.
http://www.diyaudio.com/forums/digi...pcm1794-waveio-usb-input-612.html#post5019053
Unfortunately I cant try raspbian or archphile or Moode with my SBC (Sparky). Once I try to fiddle around with this setup - Sparky, Kali & DDDAC, I might as well try out Raspi with these players.
Also, do you feel using digi+ card would not have these issues that are being faced with Kali & DDDAC?
Since you're using Sparky's specific distribution, it shouldnt't be hard for Ioan and co. to figure out what is happening. I'm sure that they won't let you down.
Regarding the Digi+ card, isn't that one strictly s/pdif out?
If you mean the Pro version, I can't know how well it will fare in your situation. You shouldn't be having problems with Kali + DDDAC, yet you are..
BTW, I noticed that the PCM1794 used on DDDAC needs to be configured for either 16bits or 24bits. I assume it's configured for 24bits. That would explain your problems with 16bit material.
But then again, there is some glue logic in front of it shifting bits and stuff. It might have something to do with it.
Regarding the Digi+ card, isn't that one strictly s/pdif out?
If you mean the Pro version, I can't know how well it will fare in your situation. You shouldn't be having problems with Kali + DDDAC, yet you are..
BTW, I noticed that the PCM1794 used on DDDAC needs to be configured for either 16bits or 24bits. I assume it's configured for 24bits. That would explain your problems with 16bit material.
But then again, there is some glue logic in front of it shifting bits and stuff. It might have something to do with it.