piCorePlayer = piCore Linux + Raspberry Pi + Squeezelite

Jump to Latest
#346
I have an issue with picore 5 on rpi3

Setting up an NFS share isn't working.
I have 'additional file systems' installed.

When trying to mount it 'by hand' in a shell I get
Code: 
sudo mount -t nfs 192.168.178.66:/export/data test
mount: wrong fs type, bad option, bad superblock on 192.168.178.66:/export/data,
       missing codepage or helper program, or other error
       (for several filesystems (e.g. nfs, cifs) you might
       need a /sbin/mount.<type> helper program)

       In some cases useful info is found in syslog - try
       dmesg | tail or so.
which indicates that something is still missing
(the mount works fine on a raspian-install)
Rüdiger
 
#349
Yatsushiro said:
... and will have addressed any perceived shortcomings...
Click to expand...

"any" "perceived" !?!?

Fact is that all RPI generations until gen 4 were IMO basically not suited to
run USB audio properly.

A single shared USB2.0 line for network and audio traffic - in/out at the same time simply doesn't work properly.

Hooking up a HDD to USB and running a USB DAC while controlling the RPI
via network doesn't make things much better.

Beside that the RPI up2 now had a very basic USB HW implementation.
The USB power rails need to be dead quiet and stable.
We shouldn't forget the power on the rail is shared with the RPI HW. Load variations and noise on that rail and of course data lines would impact both sides.

External power supply for a USB DAC IMO would be a must anyhow.

If you then try to run DSP work on the PI, such as quality resampling, the whole setup usually fails (XRUNS/lockups asf).

Let's better not start talking about running LMS tasks on such a setup.

That's one of the main reasons why audio HATs became extremely successful.

Another reason:

By using Allos reclocker device, Ian's reclocker&filter device or master-clock HATs the pretty low I2S performance of the RPI becomes pretty much irrelevant. Jitter levels in the femto second area can be and are achieved. And such a low jitter level easily competes with top USB audio implementations out there.
And a Beaglebone would look pretty outclassed on its I2S performance at that point.

The main issue of all the bones, droids, and fruit Pis (except RPI) out there is,
non of them can compete - not even close - with the RPI firmware, kernel and software support.
Without proper (longterm) SW (supplier + community) support your HW - no matter how great the specs seem to be - will be worth ...
Inmate amigo1 is basically proving the point: highjacking this thread while begging for BBB SW support that he'll never ever get.


For achieving highest quality audio the RPI can IMO be used in a very narrow band
and a rather specific setup only.
If you look for a general purpose high performance (USB) audio renderer and/or server you IMO better stick
to a NUC or similar and stay away from SBCs (and that'd even IMO include the Pi4).


Enjoy.
 
Last edited:
#356
Sorry, I lost track of the conversations over here......did you get your NFS problem sorted.

More than likely you are missing a mount option "vers=x" (Where x = 3 or possibly 2) it depends on what you are trying to connect to.

And yes, we have a 6.0.0 beta out there as we sort through all of the PI4 fun. We have even released a 64 bit kernel (32 bit userspace) Which helps on some of the RAM and Disk through put.
 
#360
soundcheck said:
Ah. OK. I don't use USB anyhow. rt-64 works great on Wifi+HAT-DAC installations. 😉

I just got myself into the process figuring out how to get the userspace to 64bit. Just the 64bit kernel is just half the story.
Click to expand...

That is a much bigger rabbit hole, especially for a minimal OS like pCPCore. Nothing can play at >32 bit, so I'm not sure of the benefit, but time will tell.
 
You must log in or register to reply here.
Top Bottom