Interesting, from these multiples I'd say that it does support ONLY 16/32 bit word length. The 24bit ist just number of data clock cycles used for DA conversion.
It's been a while since I last fiddled with PCM1794. From memory, I'm sure it is fine with I2S 64 bit. (ISTR, driving it from XMOS which would have been outputting 64 bit.)
If people are concerned about 64 bit with the DDAC1794. Doede is expecting 64 bit I2S and then converting on the mainboard to split and right justify 24 bit samples for left/right channels, so that will work just fine with 64 bit I2S word output from the cape.
Last edited:
So in theorie it might work, however earlier Supersurfer wrote his DDDAC didn't accept a 16bit words I2S feed. We'll have to wait and see.
Thank you for the reply- I hope you will reconsider. The HQPlayer NAA is a lot more than just PCM>DSD, and I feel the concept may be very applicable here. Its intent is for the server to resample in the more powerful server and then send to the client. HQPlayer has multiple algorithms and dithers. It also supports multi channel and convolution with support up to 700k rates. To date it has the best sounding upsampling for me. As I noted, it already works in Debian. The SOtM sMS 100 uses the NAA along side of LMS and MPD. Presently the developer has a distro image for the NAA on Cuboxi, but this project seems perfect for it. The idea of DXD/DSD straight to i2s using good clocks while skipping USB seems like a game changer.
Forgive me if I seemed expectant. It was meant as a request, and obvioulsy I do not understand well enough to get it. Thank you for your reply.
This is probably due to the constraints of the motherboard Doede has designed.
According to this post: DangerousPrototypes.com forum • View topic - I2S DAC board for raspberry pi and beaglebone black
Better clocks may not improve the jitter problem with BBB. The author of the post believe the problem is in the s/w.
Better clocks may not improve the jitter problem with BBB. The author of the post believe the problem is in the s/w.
Yes, interesting read.
Noted a piece in the blog about RaspberryPi/I2S: "One huge take away here though is that: pretty much no solution that uses an unbuffered I2S stream from a Raspberry Pi will be high performing.". Much earlier in this thread the was praise for RPi via I2S even tho we have moved on from the to the BBB and the cape.
One potential way to address this would be to use "better" audio playback software, maybe also in combination with some operating system tweaks.
For Linux, BruteFIR is alleged to be an above-average audio player application. It's a back-end application only, but it can be used in combination with Music Player Daemon, by using MPD's pipe output plugin.
I guess the same would be true for Mopidy.
The "investigation" I did on the linux audio stack seems to suggest that properly configured, the audio path is just a pass-through. When I did that (and by playing a native 48KHz file), the amount of jitter on the data (as indicated by having to use a very wide DPLL setting) was in my opinion not characteristic of the quality of the built-in clock (I thought the built-in clock could not be that bad). As the author of the above post speculated, I thought it would be the SOIC polluting the clock signals. Based on his findings, it seems the data itself is at fault.
Results from Botic will be very interesting in supporting or disproving this issue. Right now, it is a mystery to me. I can't believe the audio s/w in Linux is causing the problem.
Results from Botic will be very interesting in supporting or disproving this issue. Right now, it is a mystery to me. I can't believe the audio s/w in Linux is causing the problem.
In the conclusion to this Dangerous Prototypes post on its page 2, the author states:
"To me they (the jitter/phase noise results) point at software as being the issue rather than hardware. So my hypothesis now would be that the "phase noise" seen in all my plots up to now might be mostly software related. Even the Raspberry Pi stuff could just be the software."
He says this after he has tried adding low noise clocks to the BBB and found no significant improvement. Any improvement could have been masked by the audio s/w and data faults in Linux.
Before I read this I was contemplating fitting an improved clock/oscillator to my Rpi but now I don't think this is alone on the critical path to improvement. Might the same be true for the Botic.
John
"To me they (the jitter/phase noise results) point at software as being the issue rather than hardware. So my hypothesis now would be that the "phase noise" seen in all my plots up to now might be mostly software related. Even the Raspberry Pi stuff could just be the software."
He says this after he has tried adding low noise clocks to the BBB and found no significant improvement. Any improvement could have been masked by the audio s/w and data faults in Linux.
Before I read this I was contemplating fitting an improved clock/oscillator to my Rpi but now I don't think this is alone on the critical path to improvement. Might the same be true for the Botic.
John
+1 Please!Good to hear, put me down for a cape when they are ready, providing it will work with the DDDAC
Software
I read the article with interest, but am not sure what software it is that he is referring to?
Is it Squeezelite or some other software that I don't realise is involved in BBB? He seems to indicate that aplay in Linux can be transparent pass through.
Jonathan
Hi John
I read the article with interest, but am not sure what software it is that he is referring to?
Is it Squeezelite or some other software that I don't realise is involved in BBB? He seems to indicate that aplay in Linux can be transparent pass through.
Jonathan
Today, I've received a gift from a Premier Farnell's manager I never heard about. He sent me a brand new element14 BeagleBone Black, as a replacement for a board I've damaged lately and he included also handwritten message with compliments. Thanks a very much!
In these days I'm trying to prepare Botic driver with multichannel and DSD support (no I2C control yet, sorry). The new kernel 3.15.1 seems to be faster than previous one, but there are still some issues to be resolved.
For example I'd like to examine a issue reported by brian at dangerousprototypes.com. I can easily reproduce that when playing 4 channels at 192kHz rate. In such case 3rd and 4th channels has frequent dropouts. The question is if that can happen also with <=96kHz and if that can be detected and prevented.
Maybe this week, but more probably in the 2nd week of July.
In these days I'm trying to prepare Botic driver with multichannel and DSD support (no I2C control yet, sorry). The new kernel 3.15.1 seems to be faster than previous one, but there are still some issues to be resolved.
For example I'd like to examine a issue reported by brian at dangerousprototypes.com. I can easily reproduce that when playing 4 channels at 192kHz rate. In such case 3rd and 4th channels has frequent dropouts. The question is if that can happen also with <=96kHz and if that can be detected and prevented.
Maybe this week, but more probably in the 2nd week of July.
I've wrote false statement in the last post...
With disabled SPDIF autodetection and maximum DPLL the BBB with internal oscillator seems to plays 8 channels of 192kHz 32bit data well.
Also 4 channels of DSD64/DSD128 are fine too.
However with the 384kHz there is static noise in the sound, but I hope this one can be solved too.
With disabled SPDIF autodetection and maximum DPLL the BBB with internal oscillator seems to plays 8 channels of 192kHz 32bit data well.
Also 4 channels of DSD64/DSD128 are fine too.
However with the 384kHz there is static noise in the sound, but I hope this one can be solved too.
- Status
- This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.