I had a burn-in track running continuously for 24h now.
As expected everything becomes less edgier - some would call it more natural.
For those not owning burn-in tracks:
iFi offers a burn-in track FOC for download.
Also have a look at FOC Taralabs Burn-In track.
What's next?
I do expect more to gain. Obviously.
PcP 3.0 is not fully tweaked and the power supply setup is not finished yet. There should be space for improvement.
The DAC, in its current stage, is not on the level of the "fully tweaked" HifiBerry and tweaked PcP2.
I'll keep you posted.
As expected everything becomes less edgier - some would call it more natural.
For those not owning burn-in tracks:
iFi offers a burn-in track FOC for download.
Also have a look at FOC Taralabs Burn-In track.
What's next?
I do expect more to gain. Obviously.
PcP 3.0 is not fully tweaked and the power supply setup is not finished yet. There should be space for improvement.
The DAC, in its current stage, is not on the level of the "fully tweaked" HifiBerry and tweaked PcP2.
I'll keep you posted.
Last edited:
Some steps further down the road.
Last night I managed to compile my shaped squeezelite binary. That usually comes next after all OS optimizations are in place.
I had to compile it since the old binary I was using before was not working anymore.
This time I did it on the pCp30 machine. It took me while to figure out what tiny-core packages to use.
I had to increase the partition size first (pCp main menu) to get some more space to run the jobs.
Result: Great stuff. It was confirmed that's well worth running that exercise.
I ended up at the same result as reported/discussed before.
While running this exercise I figured piCore comes with gcc6.3 in the repo nowadays. That's lightyears ahead from e.g. the official PI crosscompiler (gcc4.8). This alone might very well generate more efficient binaries.
The rpi-vc package for turning off HDMI was still not available though. I moved the rpi-vc.tcz package from the old pCp image to my pCp3.0
As you all know that's a must-do tweak to save some decent power (20mA).
The package was still not in the beta-repo last time I looked. You basically have to copy both package files to the image (../tce/optional) and edit manually onboot.lst to add that package. Reboot and than you'll have the required tools available.
Over night I then kept torturing the DAC with the Taralabs track.
In the morning I had a quick glance to see where I'm at now.
Just loaded one of my favorite test tracks "Jan Garbarek - Talking Wind"...
...JFC. Pretty awesome!
All I can tell already now. My HifiBerry days are finally over! And that with just my temporary HW setup, temporary PS and no kernel update in place. (Now you know my ToDo list)
Note: I'm talking about my modified Hifiberry HW setup, which plays in a a different league compared to the stock HifiBerry DAC+ Pro!
I think it's time to better open up a new MamboBerry thread, otherwise things get mixed up too much.
Thx for all your valuable contributions, it's been a lot of fun. 😀
A nice day.
Last night I managed to compile my shaped squeezelite binary. That usually comes next after all OS optimizations are in place.
I had to compile it since the old binary I was using before was not working anymore.
This time I did it on the pCp30 machine. It took me while to figure out what tiny-core packages to use.
I had to increase the partition size first (pCp main menu) to get some more space to run the jobs.
Result: Great stuff. It was confirmed that's well worth running that exercise.
I ended up at the same result as reported/discussed before.
While running this exercise I figured piCore comes with gcc6.3 in the repo nowadays. That's lightyears ahead from e.g. the official PI crosscompiler (gcc4.8). This alone might very well generate more efficient binaries.
The rpi-vc package for turning off HDMI was still not available though. I moved the rpi-vc.tcz package from the old pCp image to my pCp3.0
As you all know that's a must-do tweak to save some decent power (20mA).
The package was still not in the beta-repo last time I looked. You basically have to copy both package files to the image (../tce/optional) and edit manually onboot.lst to add that package. Reboot and than you'll have the required tools available.
Over night I then kept torturing the DAC with the Taralabs track.
In the morning I had a quick glance to see where I'm at now.
Just loaded one of my favorite test tracks "Jan Garbarek - Talking Wind"...
...JFC. Pretty awesome!
All I can tell already now. My HifiBerry days are finally over! And that with just my temporary HW setup, temporary PS and no kernel update in place. (Now you know my ToDo list)
Note: I'm talking about my modified Hifiberry HW setup, which plays in a a different league compared to the stock HifiBerry DAC+ Pro!
I think it's time to better open up a new MamboBerry thread, otherwise things get mixed up too much.
Thx for all your valuable contributions, it's been a lot of fun. 😀
A nice day.
Just walked by.
It seems that Moode/Tim picked up Clivems 4.4,y-simple kernel.
Now the rest of the crowd can enjoy latest I2S PI-HAT audio features.
Unfortunately the PCP folks do not run this bleeding edge 4.4. kernel
package. Ok. Ok. I know. We shouldn't call a 4.4. kernel bleeding edge. 😀
I still keep the fingers crossed that one day all these valuable
features/improvement/fixes make it into the official PI kernel.
Enjoy.
It seems that Moode/Tim picked up Clivems 4.4,y-simple kernel.
Now the rest of the crowd can enjoy latest I2S PI-HAT audio features.
Unfortunately the PCP folks do not run this bleeding edge 4.4. kernel
package. Ok. Ok. I know. We shouldn't call a 4.4. kernel bleeding edge. 😀
I still keep the fingers crossed that one day all these valuable
features/improvement/fixes make it into the official PI kernel.
Enjoy.
Ok so he is not using the standard 4.4.19 kernel - has he stated that?
BTW: Is there an easy "how to do it" recipie for installing Cliverns kernel?
I feel the information is quite fragmented but that could likely be lack of understanding 🙂
BTW: Is there an easy "how to do it" recipie for installing Cliverns kernel?
I feel the information is quite fragmented but that could likely be lack of understanding 🙂
SC, do you know that for a fact? Not that I have an issue with it, but at the point someone is using it as the basis for a distro kernel, I'd like to make sure they realise that the patch sets are unsupported. Anyone has any issues, I may be able to help on a best efforts basis, but there cannot be any expectation, or demand of support.
I just re-based rpi-4.4.y-simple from 4.4.19 to 4.4.20.
I haven't made this public yet, but I need to confess that I have moved all but one of my Pi's to a 4.7.3 kernel. ie. rpi-4.7.y plus modified patch set. I'll post a public rpi-4.7.y-simple branch when I have time.
It seems the Pi guys are going to wait for the next LTS kernel, (4.9), before budging from 4.4 being their "official" default kernel. I figure that is not likely to happen before the new year........ Just a useless piece of information for you. 😉
Hi folks.
I just handed over to Tim (Moode) a compiled 4.4.20-simple kernel based on Clives latest sources and a little spice from my side.
As a matter of fact. He didn't have Clives kernel in. He might have soon.
He'll be running some tests. People might be able to choose between different kernels.
But hey. No promises. We/He just started today.
@Clive - I looked up the overlays/README.
The HifiBerryDAC+ Pro doesn't come with "384k" parameter as the Mambo!?!?
Is 384k enabled by default for the PCM51xx family DACs? No 384k paramter required? Thx.
I just handed over to Tim (Moode) a compiled 4.4.20-simple kernel based on Clives latest sources and a little spice from my side.
As a matter of fact. He didn't have Clives kernel in. He might have soon.
He'll be running some tests. People might be able to choose between different kernels.
But hey. No promises. We/He just started today.
@Clive - I looked up the overlays/README.
The HifiBerryDAC+ Pro doesn't come with "384k" parameter as the Mambo!?!?
Is 384k enabled by default for the PCM51xx family DACs? No 384k paramter required? Thx.
Yep, 384k enabled by default for anything using the pcm512x codec driver.
Any overlay using the es9023 or pcm5102 codec drivers, you need to specify 384k param to the dtoverlay to get it enabled. Did it it this way, because some es9023 boards, which have piggy-backed on hifiberry_dac/pcm5102a combo, for as long as I can remember, don't have a suitable OSC for > 192k. And ESS say up to 192k in datasheet, so 384k is "overclocked" even if it does work. But my logic says that anything that isn't officially supported by datasheet is an opt-in, rather than an opt-out.
Thx Clive. Great info.
And it's good to know that not everybody can expect 384k to work.
Things like that should be noted and communicated by the distro maintainers.
And it's good to know that not everybody can expect 384k to work.
Things like that should be noted and communicated by the distro maintainers.
Last edited:
Hi Clive,
Soundcheck's kernel working just fine so far 🙂 Some quick test results with Moode indicate 32/384k output from alsa for Mamboberry es9023 and DAC+Pro pcm5122 boards. This is nice 🙂
When I get through a more extensive set of tests I'll post results and any issues that crop up.
I used to have a kernel swap feature in Moode so should be relatively straight forward to resurrect it and offer the "Advanced Audio Kernel" and associated settings as an option.
-Tim
@Clive, @Soundcheck
Hello! Was thinking about compiling your kernel Clive, directly on a pi3.
It compiles for ~ an hour, bombs at the drivers, during this command:
make -j4 zImage modules dtbs
Can you help me along, or is it more work than this? If you guys cross-compile, then that's ok (I don't have a linux machine running right now).
Thanks!
Wow that pi3 chip is like lava, ouch! 😀
Hello! Was thinking about compiling your kernel Clive, directly on a pi3.
It compiles for ~ an hour, bombs at the drivers, during this command:
make -j4 zImage modules dtbs
Can you help me along, or is it more work than this? If you guys cross-compile, then that's ok (I don't have a linux machine running right now).
Thanks!
Code:
git clone --depth=1 [url]https://github.com/DigitalDreamtimeLtd/linux.git[/url]
cd linux
KERNEL=kernel7
make bcm2709_defconfig
make -j4 zImage modules dtbs
sudo make modules_install
sudo cp arch/arm/boot/dts/*.dtb /boot/
sudo cp arch/arm/boot/dts/overlays/*.dtb* /boot/overlays/
sudo cp arch/arm/boot/dts/overlays/README /boot/overlays/
sudo scripts/mkknlimg arch/arm/boot/zImage /boot/$KERNEL.imgWow that pi3 chip is like lava, ouch! 😀
Last edited:
Ooops, probably ran out of space, expanded the sdcard filesystem this time.
Does this look correct?
Does this look correct?
Attachments
Last edited:
Doesn't look too bad.
It's just the wrong kernel. 😉
You might want to try this:
or if you want to have it faster downloaded, try this:
Note: This will not become a kernel hacker support thread! At least from my side. 😉
Good luck.
It's just the wrong kernel. 😉
You might want to try this:
Code:
git clone --branch rpi-4.4.y-simple "https://github.com/DigitalDreamtimeLtd/linux.git"or if you want to have it faster downloaded, try this:
Code:
wget "https://github.com/DigitalDreamtimeLtd/linux/archive/rpi-4.4.y-simple.zip"Note: This will not become a kernel hacker support thread! At least from my side. 😉
Good luck.
Tim, whilst I am interested in any issues you may find, I hope SC has explained to you that I maintain the patch sets in that simple tree (which I think SC built the kernel from) on a best efforts basis. There is nothing implied or guaranteed by me. You use it at your own risk. If a kernel built from it breaks, you get to keep both pieces...... Having said that, I don't have any issues with it and I am running 20 or so "typical" I2S audio HAT's 24/7, with those patch sets applied in my I2S test farm.
There isn't really any documentation, but if you read the commit logs for individual patches, they do provide useful info....
😀 haha cool, Thanks!
Also built squeezelite, straight from ralph's git. Did the 384K test.
I'm happy, can test things out easily!
Attachments
Hi Clive,
No prob. Moode software also without any guarantees, breakage always a possibility.
After testing the only issue I've run into so far is that on Mambo DAC+ 24/192 bit rate audio from flac files sounds greatly slowed down when using the custom overlay (with or w/o params).
- if I switch to using hifiberry-dac overlay then no issue
- if I use mambo custom overlay but enable SoX resampling in MPD then no issue
-Tim
I just tested the problem Tim describes.
I run into the same issue on 192kHz native files - either flac or PCM.
Resampling to 192 on LMS also generates the same issue.
384 is OK.
It's like 192 played @ 44.1/48. Alsa however reports 192 under /proc/asound/card0/... .
There's not much I can see in the logs.
Sorry. I gotta run. CU in 2 weeks.
I run into the same issue on 192kHz native files - either flac or PCM.
Resampling to 192 on LMS also generates the same issue.
384 is OK.
It's like 192 played @ 44.1/48. Alsa however reports 192 under /proc/asound/card0/... .
There's not much I can see in the logs.
Sorry. I gotta run. CU in 2 weeks.
Last edited: