Party at my house! Just be sure to give my wife plenty of lead time... 
Oh my dear, I can't believe I didn't see the drawing you'd attached, Greg! Perhaps at some point my kids will allow me sufficient sleep. Anyway, perhaps I'm still too new at this, but it's hard for me to justify a PSU that's as expensive as the CPU and DAC combined!
I realize the support behind RPi is much higher, and that is a significant factor. One other thing in ODroid's favor though is better Android support (although I might be ignorant on this point), and there are some games on Android that I think my kids would enjoy. At the end of the day, I have a relatively focused goal for the SoC: an inexpensive but high-functioning HTPC and light gaming device. Seems that the RPi wins on the former, but the ODroid wins on the latter. If I'm mistaken on that score, please set me straight!
I graduated from Carroll HS in '99...so a few moons fewer ago. Odal, in what part of IN do you reside?
Oh my dear, I can't believe I didn't see the drawing you'd attached, Greg! Perhaps at some point my kids will allow me sufficient sleep. Anyway, perhaps I'm still too new at this, but it's hard for me to justify a PSU that's as expensive as the CPU and DAC combined!
I realize the support behind RPi is much higher, and that is a significant factor. One other thing in ODroid's favor though is better Android support (although I might be ignorant on this point), and there are some games on Android that I think my kids would enjoy. At the end of the day, I have a relatively focused goal for the SoC: an inexpensive but high-functioning HTPC and light gaming device. Seems that the RPi wins on the former, but the ODroid wins on the latter. If I'm mistaken on that score, please set me straight!
I graduated from Carroll HS in '99...so a few moons fewer ago.
Odal, in what part of IN do you reside?
Ok folks.
Pretty much focus on power supplies these days.
I still use very happily my iPower and have no intention to change that!
That gives me some space to dig into the SW side again.
I made a 180° turn and switched from my own Arch Linux installation with realtime kernel, tweaks... to PiCorePlayer.
Many people who prefer the squeeze universe over MPD based stuff are using PCP.
I wanted to see how much potential PiCorePlayer as serious audio base really has.
I mentioned earlier that I consider the base system an average quality playback engine.
This was my conclusion after quickly looking and listening into it some time ago.
The base PCP installation was 2D and showed limited separation and depth. Details and dynamics -- Gone.
But that's the A/B comparison to my own reference setup. That doesn't mean that it is worse then others!
And "Average Quality" is of course a relative term. It really depends on your experiences and expectations.
What I'm saying is. There's space for improvement for those who want to squeeze the last drop out of everything.
TinyCore Linux the base of PCP is not my favorite Linux flavor.
It's that much stripped down that every 2nd turn puts you in front of a wall.
I actually needed some support of the PCP folks to get going without major efforts.
That's what I did. It still took me a couple of days to get going.
Meanwhile I managed to apply several of my known configurations and tweaks.
Introducing my own squeezelite binary is still kind of complex, I'm working on it.
Introducing my own kernel would be a major project. Their kernel is one of the key
issues I have with PCP.
They use a base 4.1 kernel with none of the patches we discussed earlier in place.
They also use a slow and rather fad base TinyCore default kernel config. Hmmmh. No good.
Bottom line -- the PCP kernel I consider pretty much the biggest challenge of the project.
As a result of all my efforts until now - I'd like to say though,
that my tweaked PiCorePlayer installation sounds already damn good.
Considering that I still see space for improvement - the whole project seems to be worth the efforts.
I also wanted to verify my findings against another system and another ears.
Guess what!?!? Surprise, surprise. Greg volunteered!
I sent him quite a basic configuration instruction for one of my easy-win tweaks.
A simple copy/paste action of some commands via ssh.
From what I understood, he is planning to leave that configuration in for now.
That's a good sign I guess.
I told him that this would be the tip of the iceberg.
I'll keep you posted.
As soon as things stabilize I'll post this or that tweak.
Enjoy.
Hi Soundcheck,
Very impressive! Got me curious
PCP is the first RPI project I started with, never could compare with other RPI solutions, but I am open to it.
I only use I2S straight to my dac, and would love to see DSD capabilities for using flip flop (no dac) or DoP at highest possible samplerate.
I use RPI3 btw.
Keep up the good work!
Regards,
Alex
Maybe not here, but (software upsample and output to TI PCM5xxx @ 352k8/384k connected to Pi), was being done over a year ago with first gen Pi HB and IQ DAC's. (These used the separate I2S header on the original PiB, before they switched to the 40 way on the B+. The reason I mention this.... I've lost track of time. How long has it been since B+ was released? Must be more than a year ago.....)
The SabreBerry32 is limited to 192k in master mode. You need to run it slave, and switch off OSF via I2C, to run 352k8 and 384k sample rates, which brings the quality of the Pi OSC back into the discussion.
@Clive.
Did you ever come across any patches that were used to enable 384kHz in the past.
The base PI Alsa sources still just won't allow more then 192kHz for any DAC as far as I can judge!??!
And that'll go on until 4.6. If anybody claims higher rates, there must be kernel patches been available/used.
Background:
I still have problems to get squeezelite going @384. It's giving me hwparams setting issues on 384kHz.
These I don't have with sox. I was wondering if I was missing something.
Attached you'll find my patch. That's no rocket since, just some declarations get changed.
Did you ever come across any patches that were used to enable 384kHz in the past.
The base PI Alsa sources still just won't allow more then 192kHz for any DAC as far as I can judge!??!
And that'll go on until 4.6. If anybody claims higher rates, there must be kernel patches been available/used.
Background:
I still have problems to get squeezelite going @384. It's giving me hwparams setting issues on 384kHz.
These I don't have with sox. I was wondering if I was missing something.
Attached you'll find my patch. That's no rocket since, just some declarations get changed.
Last edited:
Only the patch I wrote. I wasn't aware of the patch, that had been posted to the ALSA mailing list until you posted a link last week. (I was surprised they didn't add a def for 352800 at the same time.)
EDIT: Oh, and if you do add a def for 352800, you'll need to modify the codec driver as well.
Last edited:
Just to keep you in the loop.
Today I finished my own squeezelite binary.
It's specifically made for the PI2 and it's also stripped down compared to the one as supplied by PiCorePlayer.
The main challenge for me was to modify and build all static libraries first that are required
for squeezelite on PCP. squeezlite on PCP has basically all it needs statically inside a single binary. That's not the case on most other systems. That also makes the binary much larger.
Arch Linux - my development base - does not come with static libraries anymore. That's why it was a major task (at least for me) to get going with this.
Anyhow. I managed. And I think it was well worth it.
Enjoy.
Today I finished my own squeezelite binary.
It's specifically made for the PI2 and it's also stripped down compared to the one as supplied by PiCorePlayer.
The main challenge for me was to modify and build all static libraries first that are required
for squeezelite on PCP. squeezlite on PCP has basically all it needs statically inside a single binary. That's not the case on most other systems. That also makes the binary much larger.
Arch Linux - my development base - does not come with static libraries anymore. That's why it was a major task (at least for me) to get going with this.
Anyhow. I managed. And I think it was well worth it.
Enjoy.
Is it possible to patch it for RPI3 too?
Btw, received a new DAC+Pro today, I wasn't happy with my "NDK" version.
Immediately, after modifying it and listening to it, it sounds netter than the NDK version.
Very strange how things work with human ears, really thought in the beginning the NDK
version sounded better. Standard version with XpressO tcxo's definitely sounds better.
Wider and deeper soundstage. No argue about that.
I leave it as it is now, but would love to try the 384KHz patch for RPI3.
Keep up the good work
Btw, received a new DAC+Pro today, I wasn't happy with my "NDK" version.
Immediately, after modifying it and listening to it, it sounds netter than the NDK version.
Very strange how things work with human ears, really thought in the beginning the NDK
version sounded better. Standard version with XpressO tcxo's definitely sounds better.
Wider and deeper soundstage. No argue about that.
I leave it as it is now, but would love to try the 384KHz patch for RPI3.
Keep up the good work
About those updates to the HFBD+P Setup & PiCorePlayer from Soundcheck...
I was delighted when Soundcheck approached me about trying out some of the changes & tweaks he's been working on around both the HFBD+P & PiCorePlayer. I JUMPED at the chance. And as far as what I experienced, let me preface my impressions with what I said about my highly-modified HFBD+P a few weeks back...
After implementing Soundchecks changes and tweaks, I was delighted to find out that the mods I had done not only DID perform the way I expected, but handily exceeded my expectations. Clearly the overall sound of that modified DAC was compromised by the DAC and player setup.
Now I am hearing the "dynamics, articulation, and detailing" I heard before and mentioned above in concert with a much improved midrange balance. The cleanliness of the add-on regulators plus the lowered hash of the SMD film caps over the typical ceramics in the stock unit are providing very extended, yet not accentuated and definitely non-fatiguing highs. That sense of "digitalitis" is totally gone and instead of wanting to swap in another setup after 10 minutes or so, I had several sessions where I was going to listen for a few minutes and instead was captured for an hour or two.
I'm very excited by what I'm getting from this setup now. It has jumped up in my ranking of my different setups to equaling the modified S47 DVD Player and the HAPZ in virtually all ways and in some circumstances possibly beating them on midrange articulation.
I'd considered a lot of reasons this setup was disappointing before... that the regulators or caps in the add-on supplies were not of the quality I expected (this was my first use of that regulator setup and now won't be my last), that the magic I'd heard replacing the industry-standard ceramic capacitors with SMD PPS film capacitors in many other setups was not universal, that maybe the PCM5122 was just a bad DAC chip... and possibly the SW environment. But I discounted that last as I was getting such good sound with a very similar setups feeding either the Mamboberry or Soekris DACs. And the culprit WAS the latter, especially how it was implemented for this DAC. AND my power supply and cap mods for that DAC are now a resounding success!
I am really excited now to hear Soundcheck's final product!
As Soundcheck wrote before:
Not only am I leaving it in, I have NO intention of taking it out.
I can't wait for the whole iceberg!
Greg in Mississippi
I was delighted when Soundcheck approached me about trying out some of the changes & tweaks he's been working on around both the HFBD+P & PiCorePlayer. I JUMPED at the chance. And as far as what I experienced, let me preface my impressions with what I said about my highly-modified HFBD+P a few weeks back...
After implementing Soundchecks changes and tweaks, I was delighted to find out that the mods I had done not only DID perform the way I expected, but handily exceeded my expectations. Clearly the overall sound of that modified DAC was compromised by the DAC and player setup.
Now I am hearing the "dynamics, articulation, and detailing" I heard before and mentioned above in concert with a much improved midrange balance. The cleanliness of the add-on regulators plus the lowered hash of the SMD film caps over the typical ceramics in the stock unit are providing very extended, yet not accentuated and definitely non-fatiguing highs. That sense of "digitalitis" is totally gone and instead of wanting to swap in another setup after 10 minutes or so, I had several sessions where I was going to listen for a few minutes and instead was captured for an hour or two.
I'm very excited by what I'm getting from this setup now. It has jumped up in my ranking of my different setups to equaling the modified S47 DVD Player and the HAPZ in virtually all ways and in some circumstances possibly beating them on midrange articulation.
I'd considered a lot of reasons this setup was disappointing before... that the regulators or caps in the add-on supplies were not of the quality I expected (this was my first use of that regulator setup and now won't be my last), that the magic I'd heard replacing the industry-standard ceramic capacitors with SMD PPS film capacitors in many other setups was not universal, that maybe the PCM5122 was just a bad DAC chip... and possibly the SW environment. But I discounted that last as I was getting such good sound with a very similar setups feeding either the Mamboberry or Soekris DACs. And the culprit WAS the latter, especially how it was implemented for this DAC. AND my power supply and cap mods for that DAC are now a resounding success!
I am really excited now to hear Soundcheck's final product!
As Soundcheck wrote before:
Not only am I leaving it in, I have NO intention of taking it out.
I can't wait for the whole iceberg!
Greg in Mississippi
Last edited:
@Greg
Really? Without a new squeezelite binary (for 384K, or pcm server side upsample) and diff kernel?
Here's how I've been running my piZERO... these are just my notes:
Scott piZERO HifiBerry Setup
@Greg, @soundcheck
please skim thru the notes--
any overlap?
Really? Without a new squeezelite binary (for 384K, or pcm server side upsample) and diff kernel?
Here's how I've been running my piZERO... these are just my notes:
Scott piZERO HifiBerry Setup
@Greg, @soundcheck
please skim thru the notes--
any overlap?
@sckraemer
Really!
I've looked at your settings and there is some overlap, but a key area that Soundcheck addressed is not covered.
I won't steal his thunder, but will let him reveal as he wishes.
And I believe his kernel and binaries will be very significant too.
And finally, truthfully, I am not a good resource to assess your optimizations other than HW... I am very early on my Linux audio optimization learning curve.
Greg in Mississippi
First things first.
I'm in the middle of getting the kernel project done. That keeps me quite busy.
The learning curve is pretty steep.
Still. All that is as complex as I expected it to be on PCP.
There's nothing like a proper writeup out there. All info is widely spread.
Anyhow I managed by now to get my own crosscompiled 4.1 kernel booted and the core modules loaded. (I'd still need to get the INTEGER.patch and the 384kHz for kernel 4.1 ).
Now I'm working on the Alsa modules which are kept in a different package.
I'm positive though that I'm gonna manage today. I found some related info on the net.
@sckramer
I looked at your tweaks:
1. I also turn off HDMI - but you know that
2. I also turn off the LEDs
3. The streaming buffer is configured with e.g. 40000:500000 - I just stream PCM streams!!
All decoding of flac/mp3 etc. is done on the server.
This I also mentioned a long time ago @squeezebox forums and elsewhere.
You basically stream a full track from a RAM Buffer to the device. That huge buffer
gets bulk loaded within the first seconds of a track.
4. Obviously I also kill all processes that are not required.
5. I also overclock the PI.
Greg mentioned that he prefers the lower rates. I still run below settings on my PI2:
1000 ARM
250 Core
500 SDRAM
OV 2
Force Turbo 1 (renders warranty void! -- by setting a hardcoded warranty bit - Be careful with this one!!!)
GPU_MEM 16
If you guys tell me there's something better -- I'm all ears.
Above settings are not available via PCP webinterface!
6. I also set the DAC params via Alsa. I mentioned that before - and made my recommendation.
7.-26. I do some more.
I plan to write-up something as soon as I have my kernel done.
I'm sure - Greg won't spread any info I gave to him -- as he promised.
Cheers
I'm in the middle of getting the kernel project done. That keeps me quite busy.
The learning curve is pretty steep.
Still. All that is as complex as I expected it to be on PCP.
There's nothing like a proper writeup out there. All info is widely spread.
Anyhow I managed by now to get my own crosscompiled 4.1 kernel booted and the core modules loaded. (I'd still need to get the INTEGER.patch and the 384kHz for kernel 4.1 ).
Now I'm working on the Alsa modules which are kept in a different package.
I'm positive though that I'm gonna manage today. I found some related info on the net.
@sckramer
I looked at your tweaks:
1. I also turn off HDMI - but you know that
2. I also turn off the LEDs
3. The streaming buffer is configured with e.g. 40000:500000 - I just stream PCM streams!!
All decoding of flac/mp3 etc. is done on the server.
This I also mentioned a long time ago @squeezebox forums and elsewhere.
You basically stream a full track from a RAM Buffer to the device. That huge buffer
gets bulk loaded within the first seconds of a track.
4. Obviously I also kill all processes that are not required.
5. I also overclock the PI.
Greg mentioned that he prefers the lower rates. I still run below settings on my PI2:
1000 ARM
250 Core
500 SDRAM
OV 2
Force Turbo 1 (renders warranty void! -- by setting a hardcoded warranty bit - Be careful with this one!!!)
GPU_MEM 16
If you guys tell me there's something better -- I'm all ears.
Above settings are not available via PCP webinterface!
6. I also set the DAC params via Alsa. I mentioned that before - and made my recommendation.
7.-26. I do some more.
I plan to write-up something as soon as I have my kernel done.
I'm sure - Greg won't spread any info I gave to him -- as he promised.
Cheers
One more thing should be considered. At least that's my experience.
I mentioned that already when talking some years ago about my SqueezeBox Touch Toolbox and related network environment.
Networking:
I would not use any WLAN dongles on the PI! These cause extra load and noise.
I'd say that also applies to the onboard WLAN that comes with the PI3.
What I use is a very short unshielded ethernet cable and a well powered Cisco ethernet hub
right in front of the PI.
The cable cuts the ground loops and gets me a very stable streaming connection at all times.
People who'd like to push the limits, replace such an ethernet hub with a well powered/filtered wireless bridge/router that connects wireless to the main router
and use a short cable to connect the PI.
Enjoy.
I mentioned that already when talking some years ago about my SqueezeBox Touch Toolbox and related network environment.
Networking:
I would not use any WLAN dongles on the PI! These cause extra load and noise.
I'd say that also applies to the onboard WLAN that comes with the PI3.
What I use is a very short unshielded ethernet cable and a well powered Cisco ethernet hub
right in front of the PI.
The cable cuts the ground loops and gets me a very stable streaming connection at all times.
People who'd like to push the limits, replace such an ethernet hub with a well powered/filtered wireless bridge/router that connects wireless to the main router
and use a short cable to connect the PI.
Enjoy.
While I have not tried any alternatives, based Soundcheck's post on his blog regarding HW & network setup, I use the following for networking in my SBT setup:
1. A Netgear GS605AV router powered by a linear supply. My Pi, LMS Server, and WiFi access point are connected to this.
2. An old D-Link DI-624 wireless router setup as an access point only (no connection into the WAN port), also powered by a linear supply.
This music playback network is not connected to the internet and the WiFi access point is only used for remote access into the Pi or the LMS Server.
To minimize RF noise, I have:
1. Fairly short Ethernet cables (many are 1 foot in length, but the cable to the Pi and the one to the WiFi router are 6' to allow them to be spaced away from each other).
2. Clamp-on ferrite chokes at either end of each Ethernet cable.
3. Clamp-on ferrite chokes on each of the linear supply's AC cord.
I have listened to various Ethernet cables, but only between the Pi and the switch. I was surprised that an old gimme CAT 5 was the best above various CAT 6 and CAT 6A, including the standard Blue Jeans cables.
My LMS server is a low-powered Zotac PI-320-W2B about the size of a smart-phone. Another linear supply powers it. My music is on a 256Gb SD card in the Zotac. I also have a 256 USB stick available to supplement that at some point. When I use the USB stick, I will have it powered by another linear supply.
I have separate clean and dirty circuit AC connections in my setup which go to separate circuits on the system sub-panel. The LMS server and network HW is all on the dirty side circuit with a dual Hammond choke AC filter at the outlet.
The R-Pi is plugged into the clean side, but before a PS Audio P-10 Regenerator that powers the rest of the system. There is another dual Hammond choke AC filter at the outlet where the Pi and P-10 are connected. I did try the Pi into the P-10 and also on the dirty circuit, the current connection is the best of the three.
Yup, I wanted to make this as clean as possible right from the start! That's why I have 5 separate linear supplies setup and available for the network/LMS server side, with a couple not-used at this time for future expansion.
And of course, no WiFi dongle on the Pi. Only WiFi connection to the setup is through the WiFi router used as an access point.
Greg in Mississippi
1. A Netgear GS605AV router powered by a linear supply. My Pi, LMS Server, and WiFi access point are connected to this.
2. An old D-Link DI-624 wireless router setup as an access point only (no connection into the WAN port), also powered by a linear supply.
This music playback network is not connected to the internet and the WiFi access point is only used for remote access into the Pi or the LMS Server.
To minimize RF noise, I have:
1. Fairly short Ethernet cables (many are 1 foot in length, but the cable to the Pi and the one to the WiFi router are 6' to allow them to be spaced away from each other).
2. Clamp-on ferrite chokes at either end of each Ethernet cable.
3. Clamp-on ferrite chokes on each of the linear supply's AC cord.
I have listened to various Ethernet cables, but only between the Pi and the switch. I was surprised that an old gimme CAT 5 was the best above various CAT 6 and CAT 6A, including the standard Blue Jeans cables.
My LMS server is a low-powered Zotac PI-320-W2B about the size of a smart-phone. Another linear supply powers it. My music is on a 256Gb SD card in the Zotac. I also have a 256 USB stick available to supplement that at some point. When I use the USB stick, I will have it powered by another linear supply.
I have separate clean and dirty circuit AC connections in my setup which go to separate circuits on the system sub-panel. The LMS server and network HW is all on the dirty side circuit with a dual Hammond choke AC filter at the outlet.
The R-Pi is plugged into the clean side, but before a PS Audio P-10 Regenerator that powers the rest of the system. There is another dual Hammond choke AC filter at the outlet where the Pi and P-10 are connected. I did try the Pi into the P-10 and also on the dirty circuit, the current connection is the best of the three.
Yup, I wanted to make this as clean as possible right from the start! That's why I have 5 separate linear supplies setup and available for the network/LMS server side, with a couple not-used at this time for future expansion.
And of course, no WiFi dongle on the Pi. Only WiFi connection to the setup is through the WiFi router used as an access point.
Greg in Mississippi
Last edited:
- Status
- This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.