Jump to content

Archphile - Yet another Archlinux based audiophile distribution for Raspberry Pi (and more soon..)


Recommended Posts

Hi everyone!


I am writing this post in order to present you a project I have been working on the last months: Archphile:


Archphile - Yet Another Archlinux Based Distribution for Raspberry Pi


Archphile, is a customized ArchlinuxARM distribution in order for the Raspberry Pi to be used as an audiophile mysic player along with the use of USB Dacs. The whole spirit of the project is to keep it simple. The main ingredients of Archphile are:




There are no automations and there will never be.


Usb disks/sticks work out of the box and in order for the system to see your network shares you will have to edit /etc/fstab (you will find some examples there in order to customize and use).


Some special notes:

- Archphile since the beginning contains the latest FIQ FSM USB driver which solves the majority of problems with raspberry pi and USB Dacs. For more details please see:


Troubleshooting pops and clicks with usb DACS - How to - Archphile


However from next version step 1 will no longer be needed.


- Archphile repository contains customized packages which are updated frequently. The major packages there are mpd-archphile (two packages - one with ffmpeg support) and ympd.


- Some instructional articles in order to help beginners configure their system



- You can download and see initial instructions here










I am not a developer and Archphile is just a configuration I created for my needs and I just thought that uploading and sharing my image would also help users with the same needs that do not have the knowledge to configure a linux system.

My intention is not to support many devices as I just want to support the devices I like and use in my everyday life. Udoo Quad is the next possible device to be supported by archphile.


I really hope that you like and enjoy Archphile.






I hear dead digits

Link to comment

0.25 Beta is out.



[color=#333333][font=Open Sans]- updated firmware with SKIP_BACKUP=1 rpi-update[/font][/color]
[color=#333333][font=Open Sans]- removed FIQ_FSM options from /boot/cmdline.txt as they are enabled by default[/font][/color]
[color=#333333][font=Open Sans]- removed CMA options from /boot/config.txt[/font][/color]
[color=#333333][font=Open Sans]- updated to latest ArchlinuxARM[/font][/color]
[color=#333333][font=Open Sans]- updated to ympd-archphile to 1.2.1[/font][/color]
[color=#333333][font=Open Sans]- changed fstab shares examples to read-only to ensure that music library won’t be modified by Archphile[/font][/color]




Archphile - An audiophile distribution for Raspberry Pi - Downloads

I hear dead digits

Link to comment
  • 4 weeks later...

Just thought I'd drop by and save you from the first sign of madness - talking to yourself.


I don't have any ARM devices so I can't use/test your image myself, apart from within QEMU. Unfortunatey latest systemd in ARCH and QEMU don't work well together.


You have an interesting blog and I think archpile is a worthy alternative to the likes of volumio etc if you're not so focused on their WebUI.


You've made some sensible suggestion about network and remote fs mounts on your blog, but it is possible to to use a combo of wpa_supplicant and systemd-networkd and so handle both wired and wireless connections, dhcp or static, with systemd-networkd alone. Switching between dhcp and a static ip on a given interface would need a script. Some basic refs:


systemd-networkd with wpa_supplicant to manage wireless with roaming support | BeaverIs.Me

Using systemd-networkd with wpa_supplicant to manage wireless network configuration with roaming

Good riddance netctl


For nfs/cifs network shares, systemd.automount is not necessarly as long as you can guarantee the network is properly up before remote mounts are attempted. The use of systemd-networkd for all connection types would ensure this, as it pulls in the systemd-networkd-wait-online.service and you should get something like this:


systemd-analyze critical-chain
The time after the unit is active or started is printed after the "@" character.
The time the unit takes to start is printed after the "+" character.

graphical.target @5.158s
└─multi-user.target @5.158s
 └─getty.target @5.157s
   └─[email protected] @5.156s
     └─systemd-user-sessions.service @5.098s +56ms
       └─remote-fs.target @5.056s
         └─mnt-disk1.mount @4.417s +636ms
           └─remote-fs-pre.target @4.355s
             └─nfs-client.target @4.355s
               └─rpc-statd.service @3.844s +510ms
                 └─rpcbind.service @3.316s +468ms
                   └─network.target @3.314s
                     └─systemd-networkd.service @3.104s +205ms
                       └─dbus.service @2.781s
                         └─basic.target @2.764s
                           └─timers.target @2.754s
                             └─shadow.timer @2.750s
                               └─sysinit.target @2.730s
                                 └─swap.target @2.730s
                                   └─dev-disk-by\x2duuid-dd5b2346\x2db151\x2d4e3f\x2d89d9\x2d5dbe22a8252a.swap @2.686s +43ms
                                     └─dev-disk-by\x2duuid-dd5b2346\x2db151\x2d4e3f\x2d89d9\x2d5dbe22a8252a.device @2.685s


Personally, I would prefer to have a single app/config that covers all connections types rather than using a mixture of say dhcpcd, systemd-networkd and wicd. But then once you've decided on wired or wireless, dhcp or static. I guess the user would tend to stick to their chosen config.


I'm useless at writing bash scripts, but made a start on something to switch from dhcp to static on a wired connection with systemd-networkd already enabled on a system.


#  usage set_network interface mode
#  assumes interface is a valid name
#  accepts dhcp as a valid mode, otherwise sets to static


if [[ "$mode" == "d*" ]]
       cat > myifcfg.network <<-EOF
       cat > myifcfg.network <<-EOF

rm -f $DIR/*.network
mv ifcfg.network $DIR/
ip link set $int down
ip add flush dev $int
systemctl restart systemd-networkd


Next stage is to parse "ip link show" to get available interface devices, user selects interface and connection type, and if static inputs address, gateway etc. Plus extend script to setup systemd-networkd as necessary and work with wireless connections.


Link to comment

Hi Krisbee!


Thank you very much for your post!



Let me tell you some history on archphile and network configuration. When I started archphile, i only supported the raspberry pi and all i needed was ethernet, both static and dhcp. I started making images with netctl. I made a single file with both configurations and the user had only to uncomment the configuration he preferred.


After some time, I started experiencing some instability with netctl and I decided to move to systemd-networkd for dhcp and static with no support for wifi. With systemd-networkd I had two problems:


1. the router did not recognize the hostname of archphile and the user could not find the ip of archphile without using bonjour

2. cpu usage was high with with dhcp


So I decided to move to pure dhcpcd for dhcp and systemd-networkd for static. I also installed wicd for anyone who would like to experiment with wifi.


I really don't like this situation and this is exactly what i am working with these days. You can read here for more details:


Archphile Forum View topic - 0.30 Beta - Udoo Quad (and Udoo Dual with some extra steps!)

Archphile Forum View topic - Network configuration - an effort for a unified solution


At the moment I am testing netctl again in Udoo for everything and it seems to be pretty stable. I will start making the next raspberry pi version in the next days and if netctl will be stable for the rpi too, nectl will be the only configuration tool for archphile.


What I have done so far is to create a sincle netctl profile named archphile. At the moment it's content is the following:


[color=#8B8B8B][font=Monaco]#Description='A basic dhcp ethernet connection'[/font][/color]

[color=#8B8B8B][font=Monaco]Description='A basic ethernet connection with static ip'[/font][/color]

[color=#8B8B8B][font=Monaco]#Description='A basic dhcp wireless connection without security'[/font][/color]
[color=#8B8B8B][font=Monaco]## Uncomment this if your ssid is hidden[/font][/color]

[color=#8B8B8B][font=Monaco]#Description='A basic dhcp wireless connection with WPA security'[/font][/color]
[color=#8B8B8B][font=Monaco]## Uncomment this if your ssid is hidden[/font][/color]


When I finish with this file, the only thing you will have to do is just edit /etc/netctl/archphile and uncomment the desired configuration. I hope that in the next 15 days I will release the next images for udoo/rpi with the configuration above.


However, I will read all the given links above, in order to see alternatives and get ideas in general.





I hear dead digits

Link to comment



You say you started by using netctl, was that with ifplugd using [email protected]e and [email protected]e?


All the standard ARCH ARM LINUX images seem to be setup that way. But any testing I've done of Arch in a VM showed this combination always attempted to mount network shares before any network connection was fully working. So you had to use systemd.automount for network shares. You may also find other services dependent on a working network connection can fail to start.


But, using netctl alone, as you plan to do, restores some sanity and network mounts don't need systemd.automount etc.


The challenge would be to extend the Ympd web interface to allow the user to configure network interfaces and network shares. For a simpler approach, it shouldn't be too hard to write a bash script to let the user pick/configure the appropriate netctl profile, enable it and restart the associated service.


Link to comment
  • 1 month later...
  • 3 weeks later...

Hi all,


I decided to remove the image “supposed to be stable” image for the raspberry pi as I found some last minute annoying problems and I believe that it’s best to apply some more fixes and do some additional testing.


Later today or tomorrow I will upload a new image hoping to be the final beta for this device.


I really apologize for this inconvenience.





I hear dead digits

Link to comment
  • 8 months later...

Hi all,


I thought that it might be interested to share with you my experience so far with DSD reproduction alternatives:


MPD package with SACD/DVD-A ISO support - Blog - Archphile


MPD with native DSD mode support - Blog - Archphile


Although native DSD support is still under development, it appears that SACD ISO support works ok for many Archphile users.


However, in my opinion the best practice is always to convert the ISO to dsf files. This way you can get rid of the multichannel part of the ISO and free up disk space.


For anyone that wants to test the sacd ISO package, please not that it's an unofficial and experimental package. In addition it's not vanilla MPD but an MPD fork created by Maxim V. Anisiutkin.

I hear dead digits

Link to comment
  • 2 months later...

Have tried it and it works flawlessly thanks to your very clear instructions. I like the simplified web interface (though I use mostly Cantata on a PC or MPDroid on Android). Although the web interfaces offered by Volume, Rune, Mood, etc... offer more functionality, there always seem to be glitches (and the library view is useless for large libraries).


Read my NAS library without a glitch - good call on deactivating ffmpeg - and downloaded a bunch of m3u files from vTuner into the Webradio directory.


Simple, and works. Great job !

Link to comment
  • 3 months later...

Hi all,



after a long time I am really happy to announce that I am working on the next Archphile image. There is no ETA yet, but I believe that it will be ready in the next 30 days.



Some worth noting details:



- Support of ODROID C1+

- End of support of the old Raspberry Pi (arm6)

- latest MPD 0.19.11 with the less possible configuration options enabled for a minimal result

- latest MPD fork with SACD ISO support (not installed by default)

- latest YMPD from github sources with various changes (the most noticeable being dirble support)

- replacement of shairport with shairport-sync (ios9 compatible)

- many backend improvements (custom IRQ affinity for each board, setting MPD to use 1 core for all it's threads (with taskset), option for usb disk sleep etc)



Last but not least I have prepared some unofficial packages that will be in playground repository for squeezelite and LMS. I will not support these packages but feel free to experiment with them as it will be very easy for MPD and squeezelite to coexist in the same system.



Currently I am doing all development and testing on my new Odroid C1+ and in the next days I will start transfering all the optimization to the RPI, Cubox-i and Udoo Quad.



There is also a blog post explaining some of the above features, but it's already outdated as I have added stuff after that:



Details on upcoming Archphile version - Archphile







I hear dead digits

Link to comment
  • 3 months later...
  • 4 weeks later...
  • 4 years later...

Its been a long time, but Archphile is back !!



Best thing is, its better than ever....MPD support by default, Squeezelite and Roon support.


Wifi works great with the RPi no issues.


Works with Rpi 2-4


Enjoying Archphile immensely 

Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Create New...