Jeff65

Do any of the Allo operating system choices operate the RPi SD card in "diskless" mode? This mode is where the operating system is configured only to read from the SD card except when making a configuration change. I ask because I have had many SD card failures in RPi's over the years, while my Alix running a diskless mode OS has never had a memory card failure in 15 years. I'd prefer to preserve the "always just works" aspect of my Alix when I'm considering replacement options. RPi SD card failures can be tricky to diagnose. It's usually not obvious what is wrong. Thanks

Hmmm. Everything I read before indicated the Alix boards are i586, but I looked a little more carefully after your post and found a couple of items indicating that i686 architecture will actually work. Here is one: https://bbs.archlinux.org/viewtopic.php?pid=1190899#p1190899 I may give your suggestion a go. I have a spare board so the main system is not off line while I experiment. Have you made any attempt to get Debian running with a read only root file system as Voyage does? Thanks!

I need BNC not AES, but it appears to have both!

Thanks, added to the list of candidates.

Thanks for the reply. I saw a link to something similar in the PC Engines forum. This won't help with the software currency issue as it is Debian that has dropped support for i586 in Debian 9. Even if Voyage continued it could not support the old Alix boards as Voyage is Debian based.

Starting with Debian 9, my PC Engines Alix music server of the last 10 years is no longer supported. The Voyage Linux maintainer has indicated it will not be updated to Debian 9, probably because support for i586 has been dropped by Debian. The mpd version available in Voyage is a few years old already. With this set up the music files are hosted on a NAS. I have used various USB - SPDIF converters or USB inputs on DACs that have them. I'm looking for similar, modern alternatives. Obvious candidates are APU or RPi based set ups. I've been out of the game for a long while so I have a few questions that I hope can be answered here: Have RPi solved the bandwidth problems due to shared data path for the Ethernet and USB ports? Recent readings indicate perhaps not. If not, this rules out using the RPi to feed the USB input of my Metrum Octave DAC. I'm intolerant of any playback dropouts no matter how infrequent. An alternative then is to use a Pi hat to feed the SPDIF BNC input of the DAC. From what I have read, most customers demand a ready to go solution, expecting compete software images. I am the opposite. I want to control all of the software - at most I want the Linux driver only and expect the driver to work with current and future standard Linux software. I don't wish to be tied to particular software versions as much as it is possible. One of the reasons for leaving the Alix is that the mpd maintainer is unlikely to offer much help for version 0.19.12 which is several years old. Are there Pi hat SPDIF options out there that fit this description? I could also try one of the Pi hat DAC options, with similar requirements. Is this felt to be a better option than the SPDIF hats? I really like my current DAC. I have never had a corrupted flash card with the Alix set up because Voyage Linux operates from memory. This can be a problem with RPi flash cards. Has anyone managed this with their RPi music server set ups? If I am not satisfied with the above RPi options I will probably look at the PC Engines APU. Are there other offerings I should consider that are similar? I don't want to move to something like a NUC. Less is more. Thanks in advance for your thoughts!

cjf, It's all mpd and kernel using the cpu according to htop. The spikes are mostly kernel. mpd ticks along at around 25-30% playing 24/192. I haven't installed anything on top of the standard Voyage MPD package except htop. This started happening when I made the following changes: New NAS (HP N54L running OpenIndiana which is a Solaris variant - previously was Windows XP) NFS mounts (previously was using CIFS/SMB) New version of Voyage (I think I went from 0.8 to 0.9.1) Which logs? The mpd log is written to the NAS. No errors there, but I haven't turned on additional logging. I will do that. The rsize mount option definitely affects the frequency and duration of the skips. Both too big and too small cause longer and more frequent skipping.

The default negotiated sizes in my set up were 1048576, so my sizes are smaller. Of course, I'd listened for a few hours last night and this morning but right after I posted the previous I had a very short skip. Now trying rsize=65536. Is there anyway to log the state of the mpd buffer? I'd like to know if it is skipping due to buffer underruns or high CPU utilization locking out the audio stream to the DAC.

Update on the skipping issue: It persisted even with the larger buffer specified in mpd.conf. It's early days, but changing the NFS mount rsize and wsize options in FSTAB seems to have at least helped and may have resolved the issue entirely. On the theory that reads from the NAS are large files and writes are small (mpd log, database, etc.) I used the following settings: 192.168.0.222:/tank/music /mnt/music nfs rw,noatime,rsize=131072,wsize=4096 0 0 Prior to this, I was not specifying the rsize and wsize, letting the server and the Alix negotiate those sizes. Since the change I've had no skips. Also, the Alix processor only maxes when viewed using htop when starting playback or skipping to a new track at 24/192. The mid track peaks in CPU are more frequent and in the 50% range instead of 100%. If you are playing back music over a NAS and suffering skips, adjusting these parameters might be something to try.

cjf, Thanks for the reply. It isn't easily replicated. The audio drop outs are likely to occur shortly after skipping to a new track or during one of the longer bursts like the one after the 20 second interval which lasts for about 5 seconds. I upped the buffer to 8192. If this doesn't eliminate the issue I might try increasing the priority of the audio IRQ process as well. I'm using an Alix 2d2 - when these network bursts occur the processor red lines according to HTOP. Changing the HTOP settings to break out the CPU utilization says it's due to iowait, whatever that means. Cheers Jeff

I have switched from CIFS (SMB) to NFS and have started having the odd skip during network access. I posted this on the Voyage thread, but later found this thread and thought it might better fit here. ______________ Since I updated to Voyage 0.9.1 and switched over to NFS on new NAS hardware, I've been having the occasional audio skip on 24 / 192 material. Watching the network traffic on the NAS, mpd requests data from the NAS in a distictive pattern: 2 short bursts at the start of each track another 5 seconds later another 10 seconds later another 20 seconds later another 40 seconds later Each burst approximately doubles in duration, the one after the 20 second interval is 5 seconds long; the one at 40 seconds is enough to finish grabbing the remaining data for most tracks. The pattern isn't really making sense to me in terms of mpd's buffer settings, which I've left at the defaults. I'm thinking maybe caching by NFS could play into it. Thoughts? I'd really like to kill off the skips. It kind of surprises me that the activity is so spiky. Apart from the first one, the bursts must be much larger than the mpd buffer size (2048). Thanks in advance.

Since I updated to Voyage 0.9.1 and switched over to NFS on new NAS hardware, I've been having the occasional audio skip on 24 / 192 material. Watching the network traffic on the NAS, mpd requests data from the NAS in a distictive pattern: 2 short bursts at the start of each track another 5 seconds later another 10 seconds later another 20 seconds later another 40 seconds later Each burst approximately doubles in duration, the one after the 20 second interval might is 5 seconds long; the one at 40 seconds is enough to finish grabbing the remaining data for most tracks. The pattern isn't really making sense to me in terms of mpd's buffer settings, which I've left at the defaults. I'm thinking maybe caching by NFS could play into it. Thoughts? I'd really like to kill off the skips. It kind of surprises me that the activity is so spiky. Apart from the first one, the bursts must be much larger than the mpd buffer size (2048). Thanks in advance.

Hey, thanks. This worked for me. Unsure what I was doing wrong previously. My hardware wont run Windows, so I can't try cMP2

Demian, Thanks for the response. Is there somewhere I can keep track of progress getting this driver into ALSA? I'm inclined to wait too, but I'll want to know if the effort stalls somewhere. Cheers

Has anyone had success with the Hiface1 drivers here: Index of /dists/experimental/snd I've tried several matching kernel / driver combos and can't get the driver to load. After installing the package, running insmod returns an error "Unknown symbol in module" or similar. Thoughts?