The driver seems to be limited to 192kHz.
What goes out to the DAC is this:
Basically sox resamples to a .rate_max of 192000.
The DAC pcm512x codec source (this is not the driver) shows 384kHz as .rate_max though:
[/CODE]M512x_FSSP_384KHZ;
pcm512x.c: .rate_max = 384000,
pcm512x.h:#define PCM512x_FSSP_384KHZ (3 << 0)
[/CODE]
@HifiDuino you'll find a nice writeup about I2S and RPI.
The samplerate limit is set by the 19.2Mhz clock on the PI. That would prevent from running 384khz samples. (The BBB can do that btw!)
If the PI runs as I2S master!
However.
That HifiDuino article does not consider the DAC+ Pro running as I2S master with its own and faster clocks.
DAC+ Pro clockfrequency divided by 64 gives the max samplerate.
24576000Hz/64=384000Hz
From that angle the DAC+ Pro might work at 384k.
What's then the factor that prevents from running 384k??
I guess Clive is the man who'd be able to shed some light on this. Clive are u listening?
Code:
sox 02-white-noise-30s-32-384000.wav -t alsa -b 32 -c2 hw:0,0
02-white-noise-30s-32-384000.wav:
File Size: 36.7M Bit Rate: 24.6M
Encoding: Signed PCM
Channels: 2 @ 32-bit
Samplerate: 384000Hz
Replaygain: off
Duration: 00:00:11.95
In:100% 00:00:11.95 [00:00:00.00] Out:2.29M [!=====|=====!] Hd:0.0 Clip:1.23k
sox WARN rate: rate clipped 1226 samples; decrease volume?
Done.What goes out to the DAC is this:
Code:
cat /proc/asound/card0/pcm0p/sub0/hw_params
access: RW_INTERLEAVED
format: S32_LE
subformat: STD
channels: 2
rate: 192000 (384000/2)
period_size: 1024
buffer_size: 8192Basically sox resamples to a .rate_max of 192000.
The DAC pcm512x codec source (this is not the driver) shows 384kHz as .rate_max though:
Code:
pcm512x.c: 88200, 96000, 176400, 192000, 384000,
pcm512x.c: ranges[1].max = 384000;
pcm512x.c: fssp = PC[CODE][CODE]pcm512x.c: .rate_max = 384000,
pcm512x.h:#define PCM512x_FSSP_384KHZ (3 << 0)
[/CODE]
@HifiDuino you'll find a nice writeup about I2S and RPI.
The samplerate limit is set by the 19.2Mhz clock on the PI. That would prevent from running 384khz samples. (The BBB can do that btw!)
If the PI runs as I2S master!
However.
That HifiDuino article does not consider the DAC+ Pro running as I2S master with its own and faster clocks.
DAC+ Pro clockfrequency divided by 64 gives the max samplerate.
24576000Hz/64=384000Hz
From that angle the DAC+ Pro might work at 384k.
What's then the factor that prevents from running 384k??
I guess Clive is the man who'd be able to shed some light on this. Clive are u listening?
Last edited:
OK. I just looked at two basic Alsa kernel 4.4 sources:
/linux/include/sound/pcm.h
/linux/sound/core/pcm_native.c
and the I2S driver:
/linux/sound/soc/bcm/bcm2835-i2s.c
Bottom line. Alsa just supports up 2 192khz on this kernel - independent of specific DACs.
Even if technically 384khz would be possible with the DAC+ Pro. At least patching above files and a kernel update would be required to enable 384khz - as far as I can see it.
It's more than just a HifiBerry driver update.
I don't think though it's too difficult to introduce 384kHz as samplerate. Perhaps there are patches available somewhere!?!?
Clive. Please, correct me if I'm wrong.
/linux/include/sound/pcm.h
/linux/sound/core/pcm_native.c
and the I2S driver:
/linux/sound/soc/bcm/bcm2835-i2s.c
Bottom line. Alsa just supports up 2 192khz on this kernel - independent of specific DACs.
Even if technically 384khz would be possible with the DAC+ Pro. At least patching above files and a kernel update would be required to enable 384khz - as far as I can see it.
It's more than just a HifiBerry driver update.
I don't think though it's too difficult to introduce 384kHz as samplerate. Perhaps there are patches available somewhere!?!?
Clive. Please, correct me if I'm wrong.
Last edited:
Found it now!
Here is the Alsa 384khz patch and related developer discussion.
That pretty much confirms my earlier findings.
From here it is just a tiny step to get it into the HifiBerry DAC+ Pro driver universe -- I'd guess.
EDIT: Just checked all sources from kernel 4.4 - 4.6 - Above Alsa patch is not part of it! If we want it in, we have to do it ourselves.
Here is the Alsa 384khz patch and related developer discussion.
That pretty much confirms my earlier findings.
From here it is just a tiny step to get it into the HifiBerry DAC+ Pro driver universe -- I'd guess.
EDIT: Just checked all sources from kernel 4.4 - 4.6 - Above Alsa patch is not part of it! If we want it in, we have to do it ourselves.
Last edited:
Yep. I managed to get it working @384kHz.
3 files need to be patched in the kernel.
Above listing shows the actual samplerate that goes out to the device during playback.
For now I made it work with sox as player only.
I'm still facing problems to get squeezelite/LMS going.
Somehow squeezelite thinks that 192kHz is still max.
3 files need to be patched in the kernel.
Above listing shows the actual samplerate that goes out to the device during playback.
For now I made it work with sox as player only.
I'm still facing problems to get squeezelite/LMS going.
Somehow squeezelite thinks that 192kHz is still max.
VERY KEWL!!!
Getting this going will help motivate me to re-start work on the HFBD+P. I still owe this thread my assessment of why my mods to-date did not provide as much improvement as I expected. One thing that had me not excited about going back into this DAC was that when I assessed the possible items that kept the performance down, there were several that we could do nothing about or that were just too difficult to bother with (such as upgrading clocks... unless we can come up with a good adapter board or a better set of clocks in that package, it is going to be a real pain to do with no real guarantee that it will be a noticeable improvement).
This just resolved one of those items and one that I suspect will be key to getting really good performance out of this setup!
WAY MANY THANKS!!!
Greg in Mississippi
This just knocked down one of those are
Getting this going will help motivate me to re-start work on the HFBD+P. I still owe this thread my assessment of why my mods to-date did not provide as much improvement as I expected. One thing that had me not excited about going back into this DAC was that when I assessed the possible items that kept the performance down, there were several that we could do nothing about or that were just too difficult to bother with (such as upgrading clocks... unless we can come up with a good adapter board or a better set of clocks in that package, it is going to be a real pain to do with no real guarantee that it will be a noticeable improvement).
This just resolved one of those items and one that I suspect will be key to getting really good performance out of this setup!
WAY MANY THANKS!!!
Greg in Mississippi
This just knocked down one of those are
What do you folks think this:
Code:cat /proc/asound/card0/pcm0p/sub0/hw_params access: RW_INTERLEAVED format: S32_LE subformat: STD channels: 2 rate: 384000 (384000/1) period_size: 1024 buffer_size: 8192
means ?
Awesome! Nice job tracing though and actually compiling the patch in, very interesting!
So they are talking about this patch in the forums, is there an official pull request / issue for this on github yet that you saw?
Now what do we have here, any changes with what DSP program the PCM5122 reports it's using?
Skimming thru the whitepaper quick there is this:
Attachments
I have the patch here. If somebody wants it -- just PM me.
BUT. The patch has no use for anybody not being able to build a custom kernel!
####
From what I understood is that 384kHz bypasses the filters. That would be the only
reason to go for it -- IMO.
And then it's a matter what's worse - the issues associated to much higher data processing
upstream plus resampling vs. the ON-DAC filter associated losses.
Hello all,
Today I replaced the ExpressO TCXO's with NDK NZ2520SD's
For the ones interested in replacing the ExpressO TCXO's, BE CAREFUL!!
Since there are no frequency markings on the ExpressO's you have to look what's
printed on the PCB. The printings on the pcb are WRONG!!
The TCXO marked "44" is NOT the TCXO for 44.1/88.2/176.4 KHz sample frequency
The TCXO marked "48" is NOT the TCXO for 48/96/192 KHz sample frequency
You need to solder as below:
22.5792 MHz TCXO at "48" marked spot.
24.5760 MHZ TCXO at "44" marked spot.
This caused me a LOT of troubles experimenting, and too many times of de-soldering.
I finally succeeded and it works, but pcb looks like a battlefield right now
So, the 44.1 KHz TCXO (22.5792MHz) is the one next to the I2S pins.
About SQ:
Not sure if it's an improvement at all, differences are subtle. LF is a little tighter,
but it seems overall details/soundstage/blackness around instruments and voices
is not as good as the ExpressO's. But, to be honest, I'm not 100% sure if those
NDK's have had their burn-in time. I used them before, but not sure if they had
at least 150 hours of burn-in time. I will buy another DAC+Pro to compare.......
Alex
Today I replaced the ExpressO TCXO's with NDK NZ2520SD's
For the ones interested in replacing the ExpressO TCXO's, BE CAREFUL!!
Since there are no frequency markings on the ExpressO's you have to look what's
printed on the PCB. The printings on the pcb are WRONG!!
The TCXO marked "44" is NOT the TCXO for 44.1/88.2/176.4 KHz sample frequency
The TCXO marked "48" is NOT the TCXO for 48/96/192 KHz sample frequency
You need to solder as below:
22.5792 MHz TCXO at "48" marked spot.
24.5760 MHZ TCXO at "44" marked spot.
This caused me a LOT of troubles experimenting, and too many times of de-soldering.
I finally succeeded and it works, but pcb looks like a battlefield right now
So, the 44.1 KHz TCXO (22.5792MHz) is the one next to the I2S pins.
About SQ:
Not sure if it's an improvement at all, differences are subtle. LF is a little tighter,
but it seems overall details/soundstage/blackness around instruments and voices
is not as good as the ExpressO's. But, to be honest, I'm not 100% sure if those
NDK's have had their burn-in time. I used them before, but not sure if they had
at least 150 hours of burn-in time. I will buy another DAC+Pro to compare.......
Alex
Yeah, the whole point is to bypass the filters.
Why isn't this patch set to be in the official linux build, just for completeness?
I'm not set up now to compile kernels, so can't try it out
Wonder why squeezelite won't work with it--
Hi Alex,
How are you powering it?
Are you using separate linear power for the pi / Dac+ analog?
and decoupling the 3.3V?
-- even the quick & dirty way without extra parts
-->https://www.youtube.com/watch?v=JxEdd6GJCNA
Burn-in Schpurn-in
these ain't capacitors, unless it slaps you in the face... "this is better" or at least different, it's too subtle for the effort! (That is if you are already doing the linear power)
Last edited:
Hi Alex,
How are you powering it?
Are you using separate linear power for the pi / Dac+ analog?
and decoupling the 3.3V?
-- even the quick & dirty way without extra parts
https://www.youtube.com/watch?v=JxEdd6GJCNA
Hi Scott,
I am using a double Diyinhk 0.8uV ultra low noise psu, 1x3.3V 1x 5V to power the DAC directly, cut off the 5V and 3.3V.
I only use I2S output. Sounds amazing in my "Monster DAC"
The NDK's sounding better, definitely, overall, after a little burn-in time.
You would be amazed what even a new soldered wire does in a "burned-in device". It all is noticeable!
When building my dac, I had to add a tenth R-Core transformer for powering
isolated XMOS I2S module, I added this 10th R-Core transformer and a tenth
netfilter. When listening to it THE MAGIC WAS GONE.
Picture: https://drive.google.com/file/d/0B5ivzpgUT3UYU0tMLVdnQ0NodFk/view?usp=sharing
After a few days constantly running it came better and better, and finally it
sounded better than before.
EVERY mod has to "burn-in".
The NDK's are not worth the troubles btw, but they do sound better.
Every little step helps
Btw, would love to see the 384K patch for PicorePlayer which I use with LMS.
This is very interesting to me. I'm trying to learn more on the topic and I read some old comments by Swenson concluding that" filtering in software gave the best of both worlds, it still had the richness and aliveness, but was clean."
RE: Question about DSP and Filtering - John Swenson - Computer Audio Asylum
Is that still the thoughts on the topic on software filtering vs DAC chip? Do you also hear a difference in your setup when bypassing the filters? I'd appreciate some input or if someone has some links to where this is discussed in detail.
Btw: thank you all for sharing your progress.
Hi Scott,
I am using a double Diyinhk 0.8uV ultra low noise psu, 1x3.3V 1x 5V to power the DAC directly, cut off the 5V and 3.3V.
I only use I2S output. Sounds amazing in my "Monster DAC"
The NDK's sounding better, definitely, overall, after a little burn-in time.
You would be amazed what even a new soldered wire does in a "burned-in device". It all is noticeable!
When building my dac, I had to add a tenth R-Core transformer for powering
isolated XMOS I2S module, I added this 10th R-Core transformer and a tenth
netfilter. When listening to it THE MAGIC WAS GONE.
Picture: https://drive.google.com/file/d/0B5ivzpgUT3UYU0tMLVdnQ0NodFk/view?usp=sharing
After a few days constantly running it came better and better, and finally it
sounded better than before.
EVERY mod has to "burn-in".
The NDK's are not worth the troubles btw, but they do sound better.
Every little step helps
Btw, would love to see the 384K patch for PicorePlayer which I use with LMS.
Hi Alex,
Wow, you're really set up to hear changes! Do you describe that Dac somewhere else? Very interesting looking...
Are you happy with those 0.8uV power supplies? I have some of those on order for my Digi+ and to play with on the D+Pro. Instead of those r-cores went with 25W Telema's (any thoughts on transformers?)
So that's interesting on the NDK's!
I think the best thing for us to do on the 384K to start is talk to the right people that did the patch & can get a PR going in the official linux github. It should be there for completeness anyway.
Last edited:
Hi Scott,
I am using a double Diyinhk 0.8uV ultra low noise psu, 1x3.3V 1x 5V to power the DAC directly, cut off the 5V and 3.3V.
I only use I2S output. Sounds amazing in my "Monster DAC"
My only reservation on your "Monster DAC" is all those "ultra quiet" 0.8uV supplies must be sitting in a powerful magnetic soup from all those transformers!
DAC+ Pro I2S Ethernet Streamer
Just rid myself of USB with the DAC+ Pro so thought I'd share my setup. I now have an ethernet I2S streamer
Mac Mini (Roon) -> RPi3 (RoonBridge) -> DAC+ Pro -> I2S -> Buffalo II -> Legato
Modded the DAC+ Pro with two external linear DIYINHK 5V (DAC+ and RPi) and 3V3 (DAC+ clocks). For 3V3 I just bent away pins 1 and 17 on the RPi, soldered a header to pin 1 on the DAC+ Pro. (Buffalo and Legato buffer both have TPA shunt PSUs)
I2S is connected with uFL high bandwidth coax cables as short as practical.
Installed Raspberry Lite (Jessie) using HiFiBerry installer. RoonBridge then installed using their script - only 3 command lines.
RPi then magically appears as an endpoint in Roon and the tunes flow! I can highly recommend Roon - it's a stellar UI with optional Tidal streaming too... Now with their linux end point support... well...
Sound quality of this setup is great - I was using a WaveIO async USB board and this is an upgrade.
Just rid myself of USB with the DAC+ Pro so thought I'd share my setup. I now have an ethernet I2S streamer
Mac Mini (Roon) -> RPi3 (RoonBridge) -> DAC+ Pro -> I2S -> Buffalo II -> Legato
Modded the DAC+ Pro with two external linear DIYINHK 5V (DAC+ and RPi) and 3V3 (DAC+ clocks). For 3V3 I just bent away pins 1 and 17 on the RPi, soldered a header to pin 1 on the DAC+ Pro. (Buffalo and Legato buffer both have TPA shunt PSUs)
I2S is connected with uFL high bandwidth coax cables as short as practical.
Installed Raspberry Lite (Jessie) using HiFiBerry installer. RoonBridge then installed using their script - only 3 command lines.
RPi then magically appears as an endpoint in Roon and the tunes flow! I can highly recommend Roon - it's a stellar UI with optional Tidal streaming too... Now with their linux end point support... well...
Sound quality of this setup is great - I was using a WaveIO async USB board and this is an upgrade.
Attachments
Last edited:
@BruceInOz
Really really nice, simple, and no hacking up the board!
Did you experiment turning off the analog part of the PCM5122? Pretty sure thats what the 5V is used for on the Dac+, the 3.3V is for digital & clocks. Not sure the best way to do that, maybe lift the input leg of U2-- edit... or just move your 5V on the DAC+ header to pin 4,6 (5V,GND) on the pi GPIO, with R14 removed of course.
Could you post a few more pics with power supplies, transformers etc.?
Thanks!
Really really nice, simple, and no hacking up the board!
Did you experiment turning off the analog part of the PCM5122? Pretty sure thats what the 5V is used for on the Dac+, the 3.3V is for digital & clocks. Not sure the best way to do that, maybe lift the input leg of U2-- edit... or just move your 5V on the DAC+ header to pin 4,6 (5V,GND) on the pi GPIO, with R14 removed of course.
Could you post a few more pics with power supplies, transformers etc.?
Thanks!
Last edited:
Yes, have thought about ditching the PCM5122 but haven't researched it yet. Given the clocks run on 3V3 I was wonder if 5V is required at all when using just I2S? Need to investigate.
Here's my other box which has the PSUs. Pic shows linear PSUs for RPi / DAC+ Pro and two shunt regulated PSUs -> one for DAC and one for buffer.
This network streamer / DAC / pre combo then has balanced outputs to the Millennium XP amp below.
Here's my other box which has the PSUs. Pic shows linear PSUs for RPi / DAC+ Pro and two shunt regulated PSUs -> one for DAC and one for buffer.
This network streamer / DAC / pre combo then has balanced outputs to the Millennium XP amp below.
Attachments
Last edited:
- Status
- This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.