Ok build an image with another kernel. You clone the git :
and you modify the file scripts/x86config.sh
and you put the kernel you want to test. You can do everything in a virtual environment under osx.
I work on my own version of volumio and I see the 8GB of RAM. I don’t share this version because it has undergone many modifications of which I don’t know the impacts on the other materials. I only have one NUC.
Maybe try comment this line about kernel in this script. Multistrap build the OS with the PAE kernet in build.sh.
You will find the solution by doing tests of this type. 
Which leads to this question , can we enable Amd64 in 4.16 gkkpch is testing and make it official eventually?
Most new x86 machines have at least 4g memory now.
It is kind of waste we do the latest 4.16 kernel but 32 bit only, even odorid c2 defaults to 64 bit.
Can we make 64bit 4.16 an option? Or even officially some time soon?)
Thoughts?
It is not all that simple.
Technically yes, of course you could have amd64, or x86 PAE (with a slight performance hit), but what does that mean for us?
We would have to maintain different image versions as we have absolutely no intention stop support for older platforms.
And it is not just a matter of kernel versions, for amd64 we would also need to include 64bit versions of a number of customized packages.
Just to recompile them for 64bit does not make them any better or faster, neither does any other 3rd party package which is not optimized for 64bit.
(and yes, I’m aware of the multiarch option to avoid recompiling)
Waste or not depends on how you look at it, do people really gain anything with 64bit userland for Volumio?
Or is there anything we can not do when not using 64bit?
I cannot see any real advantage at the moment, just more maintenance work.
@xxxbugxxxx, I understand why you prefer a huge buffer for mpd and with the current version you can not profit from that on your hardware.
As @WeDloMiS already mentioned, it is fairly easy to create your own image version another kernel version by modifying x86config.sh
Just be aware that you might have to find the correct firmware packages too.
Firmware is not built anymore during compiling of the a kernel version > 4.12.
When using those, firmware packages should be downloaded from the Debian stretch repo.
We have no plans to support 64bit userland on 64bit ARM platforms either.
It currently defaults to 64bit kernel and 32bit userland on C2, Pine64, SoPine64, Rock64 and NanopPI-A64.
With Odroid C2 as an example, just refer to the Hardkernel forum and you will find a number of discussions around this issue.
Same issue as above, effectively no advantage but more maintenance work.
I totally agree with gkkpch.
Keeping support for old hardware is important. Using volumio on an old atom/1Gb (32bits only!) is just fine. Cpu usage is <3% if I remember. Having a x10 faster system will not improve sound quality or usability.
It’s a way of giving a new life of such old hardware.
Got it.
Is there an easier way on the existing 4.16 image, say just use new kernel deb if I want to just update to a 4.16 pae kernel?
Thank you.
Never tried it but installing a pae kernel package on the existing image would probably not work, as using a different kernel also means that our initramfs must be rebuilt with it.
Should you only install a Debain kernel package, our initramfs remains untouched and most likely causes a failure in the boot process.
Building initramfs is part of the x86config.sh script in the build procedure.
Finally, took a step back ,turned on my Odroid C2 using gkkpch’s latest image.
Kernel is little bit old, but everything works great , with graphics set to off in boot.ini, I can set MPD buffer to 800MB ( modified MPD and Volumio buffer limit), plus it is fanless. :mrgreen:
Who needs those super expensive memory player when you can just get it for fre in Volumio/MPD;)
Still big thanks to gkkpch 
Yep, but it is the newest
I2S audio for mainline linux on amlogic platforms is still work-in-progress, a company called Baylibre appears to be working on it.
When they release the new drivers, I will switch to the 4.x.x kernel.
I hope by autumn this year, but they have not given any schedule.
Hi Gé,
the current DEV version volumio-2.394-2018-04-14-x86 is working well with my Trekstor W3 Mini PC.
Best regards,
Robert
Zotac Zbox Nano CI327:
Works very slow with the current production release, but really smooth (and fast) with the dev version.
What’s not working:
Not testet:
Thanks for your feedback, much appreciated!
As for the plugins, it could have been an unlucky moment generating the image.
I’ll build a new one and update the opening post tonight.
Thank you for the new dev version.
Now plugins (I’m using only personal radio and the backup/recover tool) are usable.
One point: I wasn’t able on the Zotac Nano to update through external USB-Stick, but the update inside volumio (installed on the internal SSD) was possible and really fast without loosing any settings.
Not sure what you meant with this, trying to update the usb stick itself? Or update the internal ssd using the usb stick?
I wasn’t able to boot from the usb stick with the new version on it.
But this should be a problem with the stick itself and not with volumio.
So I’ve nstalled the new version as an update from the internal ssd.
I am try last dev ver. on Liva PC.
Boot from usb stick fine.
But then i try to copy volumio to emmc i get boot eror : unable to resolve UUID.
It is posible to clone system to emmc ?
I try this version Dev Version 2.374
Then system boot i get eror UUID.
Then i boot from usb and change UUID for partition mmcblk0p2 (volumio image) and system boot fine.
If i use latest dev fersion then boot eror UUID i do - ls dev and do not see any dev mmcblk
Mayby You can fix this eror in next version.
volumio-2.394-2018-04-14-x86 this version boot from emmc and work fine.
But it wont boot without conectet minitor.
I try to edit grub conf file but cant update grub.cfg
Thanks for your feedback, yes, my latest dev version should work for most configurations.
However, I have not discovered any issues with booting without a monitor.
So far all my configurations had one (desktops, notebooks) and therefore there was no need for testing headless, sorry
Editing grub.cfg is not recommended, it is specifically configured for booting volumio.
Please let me know why and what you wish to edit in grub.cfg, perhaps we can find another solution.
I solve problem boting whitout minitor.
Found solution ( The VGA dummy principle is simple: simulating the monitor RGB channels load with 3 resistors. Any resistor between 50 and 150 ohms is okay.)