Hi Greg,
^ what bobsherman said 😀
There's a 2nd thread discussing the digi+ and power supplies, you'll see it in the same section--
--Scott
^ what bobsherman said 😀
There's a 2nd thread discussing the digi+ and power supplies, you'll see it in the same section--
--Scott
Last edited:
Scott, thanks for your hardware configuration. I use it.
A Question: I tried to set the buffer to 400000:20000 but when I do this, Squeezelite is not running. When I leave the buffersetting blank, Squeezelite is running again.
What can be the problem (LMS is decoding flac to pcm).
Thanks again and I hope you can give me the answer!
(Did you see my PM?)
A Question: I tried to set the buffer to 400000:20000 but when I do this, Squeezelite is not running. When I leave the buffersetting blank, Squeezelite is running again.
What can be the problem (LMS is decoding flac to pcm).
Thanks again and I hope you can give me the answer!
(Did you see my PM?)
Advise:
set the buffers the other way around:
20000:400000
If you convert to PCM on LMS the data gets pretty much straight to the 400MB playback buffer. No need to have a large streamingbuffer (20MB in above example).
Obviously your playbackbuffer should be in line with system RAM size.
Maybe you'd start smaller e.g. 20000:200000 and then increase values until it fails.
set the buffers the other way around:
20000:400000
If you convert to PCM on LMS the data gets pretty much straight to the 400MB playback buffer. No need to have a large streamingbuffer (20MB in above example).
Obviously your playbackbuffer should be in line with system RAM size.
Maybe you'd start smaller e.g. 20000:200000 and then increase values until it fails.
Last edited:
Just installed my latest kernel on PCP.
Perhaps some of you are able to figure out what's so specific about that one!?!? 😉
PS:
For the time being I skip my 4.4 kernel upgrade project on PCP. I realized from 4.1 to 4.4 a lot has changed. It requires a lot more base work within TinyCore to get going.
I decided to wait until PCP/TinyCore introduces the 4.4 kernel .
Code:
Linux pico1 4.1.20-rt23-sc1 #2 SMP PREEMPT RT Sun May 15 16:33:02 CEST 2016 armv7l GNU/LinuxPerhaps some of you are able to figure out what's so specific about that one!?!? 😉
PS:
For the time being I skip my 4.4 kernel upgrade project on PCP. I realized from 4.1 to 4.4 a lot has changed. It requires a lot more base work within TinyCore to get going.
I decided to wait until PCP/TinyCore introduces the 4.4 kernel .
Hi DJ le Roi,
The pi dedicates 64MB to the GPU by default, you can change this to: gpu_mem=16 in the overclock section, or in config.txt manually, to free up additional ram.
That's why 400MB, or even 420MB works.
Added this to the notes, Thanks!
Yes now 400000:20000 works, thank you!
By the way, I saw in your contributions to the forum that you use only the digital side of the Dac+ Pro to provide the I2S signals to your I2S Dac. Do you put the volume of the Dac+ Pro at 100%?
Last edited:
Yes, I indeed am using I2S from DAC+Pro and put alsamixer to 100%.
Using Picoreplayer, latest versions have alsamixer already at 100%,
so no need to change those values.
Yes, it's great what he's designing.
Btw, take a look at https://twitter.com/iancanadaTT
He's designing DSD/I2S isolation HAT 😀
I did. And left a comment.
Unfortunately it is of no use to our HAT DACs...
And e.g. my 2nd best option -- the Soekris DAC - already has an isolator and reclocker onboard....
.....
What am I supposed to do with it!?!?
My goal is to keep the complexity in terms of number of additional
units as low as possible. This would not be the case with this HAT reclocker board.
It might be interesting for the USB-I2S folks out there. They'd get rid of USB and related units.
I don't know why Ian just doesn't put a stupid DAC on that board.
Even with a simple DAC chip he'll probably be able to outclass most of the other HAT DACS.
Just my 2 cents.
Last edited:
Maybe use it with native DSD output and use one of those NO DAC options (from Acko or others), that probably would be very interesting.
Not saying Soekris isn't good, but I think there are better options.
Just my 2 cents.
For now I love my RPI3/DAC+Pro - I2S straight to AK4495SEQ (built-in my dac)
Yep. You got it.
The 4.1 rt-kernel/rt-patch comes with a RPI specific issue though.
Somehow the usb-otg drivers causing around 1.5% CPU load. And that's
3 of them. That's a lot, considering that squeezelite runs at less than 0.5%
on my configuration.
With the standard kernel you won't notice these usb-otgs at all.
Meanwhile I figured that's a known issue.
What's the overall result!?!?
I do think things further improved. That much that the rt-kernel stays for the time being.
However. I do also have the feeling that a small layer of "clouding" has been introduced.
I suspect the usb-otg issue to be the source of this.
Bottom line. I ended up with a compromise I'm not 100% happy with.
Dropped down to rank 18 on my priority list.
First I'd have to prepare that 384 patch for 4.1.
Then I'd have to look how to get squeezelite to work with it.
@clive -- You also applied your 384 patch. Did you have a problems with squeezelite/mpd?
Do I miss something?
Beside that I presume that 384 is not worth the effort. Why?
The associated much higher load, resource utilization plus resampling asssociated losses might cause more issues then the positive contributions associated to the bypass of the ON-DAC filter would cover.
If the PCP folks upgrade to kernel 4.4 one day (they confirmed to be working on it) I'll look at it again. That'll make live easier.
Last edited:
@Abartels1965
If that board would have the option to easily attach (plug-in style)
e.g. a No-DAC option and does the DSP work onboard, I'd be more than interested.
As I said, I'd love to see solutions that are as easy to handle as the other known HAT dacs.
If that board would have the option to easily attach (plug-in style)
e.g. a No-DAC option and does the DSP work onboard, I'd be more than interested.
As I said, I'd love to see solutions that are as easy to handle as the other known HAT dacs.
Please don't make me regret trying to share this with you! 😉
rpi-4.4.y-simple
The 384k support I'm using doesn't involve touching ALSA defs, the patch already having been refused by upstream, it's better doing it by CONTINUOUS/KNOT.
Sorry, I have very little time to say more, except that there are comments in the commits and that the tree is based on current rpi-4.4.y HEAD, plus upstream dma/i2s backport, plus my 384k patch set, plus es9023 codec, plus simple overlays, plus bclk_div being implemented via msperl simple-card framework now.
Also note, that I have not tested DAC+ Pro (in master mode), waiting for Daniel to get a replacement to me. Works fine with DAC+ standard (slave) @ 352k8/384k.
For PCM5122 DAC+, no config changes necessary, and 384k max is default....
Code:
dtoverlay=hifiberry_dacplusFor Mambo, (max 192k, which is the default for es9023), and AUDIO_DEV="-o hw:CARD=MamboBerry" from squeezelite config, you use....
Code:
dtoverlay=simple-es9023-audio,card-name="MamboBerry"
dtoverlay=simple-bclk-int-div-40-80
Code:
dtoverlay=simple-es9023-audio,384k,card-name="MamboBerry"
dtoverlay=simple-bclk-int-div-50-100Adding '384k' param, get you 352k8/384k support if Mambo can do it. (Don't know.... Although I have 5 other es9023 boards, don't have a Mambo.) 'dtoverlay=simple-bclk-int-div-50-100' gets you 50/100 ratio's rather than 40/80 with 'dtoverlay=simple-bclk-int-div-40-80'.
Last edited: