Announce: Squeeze on Arch - developer version

[Krisbee]

There was a fair bit of discussion on the orig CSOS project thread about whether there should be a SAMBA server on the Wandboard, and how it should be configured for the envisaged use cases: e.g.:

http://forums.slimdevices.com/showth...ease-1/page125

http://forums.slimdevices.com/showth...ease-1/page126

The idea of using the “VortexBox file share layout” was in favour for quite a while,

http://info.vortexbox.org/tiki-index...e+share+layout

but I don't know if that was the last word on the subject, or if it's still relevant.

I think you only need to share storage local to the Wandboard via SAMBA to cater for files on USB HDD, USB mem sticks, and possibly HDD attached via SATA header.

But will you cater for both the case where the local storage is already formatted and loaded with audio files, and the case where the attached local storage is blank and unformatted and the “VortexBox file share layout” template, or something like it, can be generated on such media?

It would be plus if the soa-aur project could be used on other devices where additional SATA drives are easily attached. I would also think it would be best if any mount scheme adhered to the Linux Filesystem Hierarchy where possible, which, for example, begs the question as to where a USB memory stick should be mounted and if/how to share it via SAMBA.

Do you need separate mount points for local and network mounts? End users don't care, they just want the simplest unambiguous way to store and access their audio data: local or remote. They see the webUI, and don't care about the back end complexities.

[Triode]

There was a fair bit of discussion on the orig CSOS project thread about whether there should be a SAMBA server on the Wandboard, and how it should be configured for the envisaged use cases: e.g.:

http://forums.slimdevices.com/showth...ease-1/page125

http://forums.slimdevices.com/showth...ease-1/page126

The idea of using the “VortexBox file share layout” was in favour for quite a while,

http://info.vortexbox.org/tiki-index...e+share+layout

but I don't know if that was the last word on the subject, or if it's still relevant.

I think you only need to share storage local to the Wandboard via SAMBA to cater for files on USB HDD, USB mem sticks, and possibly HDD attached via SATA header.

But will you cater for both the case where the local storage is already formatted and loaded with audio files, and the case where the attached local storage is blank and unformatted and the “VortexBox file share layout” template, or something like it, can be generated on such media?

It would be plus if the soa-aur project could be used on other devices where additional SATA drives are easily attached. I would also think it would be best if any mount scheme adhered to the Linux Filesystem Hierarchy where possible, which, for example, begs the question as to where a USB memory stick should be mounted and if/how to share it via SAMBA.

Do you need separate mount points for local and network mounts? End users don't care, they just want the simplest unambiguous way to store and access their audio data: local or remote. They see the webUI, and don't care about the back end complexities.

Seems to me that copying Voxtexbox layout only works for people who are familar with it and needs explaining to everyone else... So I am thinking of going with /storage and /mnt/disk[1-6] with /storage exported rw via samba. This is how CSOS was - does this work for everyone? (or does no one care?)

[bobertuk]

Seems to me that copying Voxtexbox layout only works for people who are familar with it and needs explaining to everyone else... So I am thinking of going with /storage and /mnt/disk[1-6] with /storage exported rw via samba. This is how CSOS was - does this work for everyone? (or does no one care?)

Sounds good to me. Most common use is going to be USB but some (like me) will try using SATA. I only started using SoA about a week ago and it seems easy to use already. Adding capability for using with SATA makes it more flexible.

Bob

[bobertuk]

I know MIP is compiled for use on x86 processors but is there ANY possibility of running SugarCube on Wandboard SoA without linking to a PC based MIP database. The whole idea for me is to use Wandboard as a standalone system - using a PC would defeat the object of it for me.

In addition, is it possible to use Brutefir on Wandboard with SoA? If so, how :-)

TIA

Bob

[Rob P]

In addition, is it possible to use Brutefir on Wandboard with SoA? If so, how :-)

TIA

Bob

Yes, it is possible, it would be great addition to SoA making it a super transport!
The horse power is here (WB quad) and possibly on some other ARM devices. Here is my old post: http://forums.slimdevices.com/showth...l=1#post777068
Brutefir on WB is very stable, I've been running it for weeks/months without any issues (CSOS).

Installation on Archlinux takes couple steps:

1. Installation of Python package (pacman)
2. PKGBUILD/installation of Brutefir https://aur.archlinux.org/packages/brutefir/, latest version: http://www.ludd.luth.se/~torger/file...ir-1.0m.tar.gz
3. Installation of BrutefirDrc LMS plugin (by placing BrutefirDrc plugin files in LMS plugin directory, http://klaasreineke.tumblr.com/brutefirdrc-installation)
4. Creation of brutefir filter directory and placement of your favorite filters
5. Player/file type configuration and filter assignment.

Best,
Rob.

[Kuro]

Seems to me that copying Voxtexbox layout only works for people who are familar with it and needs explaining to everyone else... So I am thinking of going with /storage and /mnt/disk[1-6] with /storage exported rw via samba. This is how CSOS was - does this work for everyone? (or does no one care?)

This arrangement works for me.

BTW, is it possible to add a page called "Optimization"? What I want see on this page is the ability to disable/enable services. So if I don't need Samba, then I want to be able to disable it. I found that by running minimum number of background processes, the sound would get better even if it is just acting as a LMS server.

Ideally, it'd show as many possible services (such as crypto), and disable processes which are not needed at all. Thanks.

[albertone74]

Sounds good to me. Most common use is going to be USB but some (like me) will try using SATA. I only started using SoA about a week ago and it seems easy to use already. Adding capability for using with SATA makes it more flexible.

Bob

+1

[Krisbee]

Seems to me that copying Voxtexbox layout only works for people who are familar with it and needs explaining to everyone else... So I am thinking of going with /storage and /mnt/disk[1-6] with /storage exported rw via samba. This is how CSOS was - does this work for everyone? (or does no one care?)

You could do that, but I have two points:

1. The user, who for example, attaches a USB HDD to their Wandboard and wants to drag & drop files on to it via their network would have to know to use “/storage” and not “/mnt/disk[1-6]”

2. What happens if a user wishes to attach more than one USB HDD to their Wandboard?

I have separate questions re: “/mnt/disk[1-6]” which relates to how people may have organised large audio file collections in order to make best use of LMS and for their own ease of maintenance.

Let's say someone has organised their audio data on NAS something like this:

/media/music/classical
/media/music/jazz
/media/music/blues
/media/music/pop
/media/music/ …. etc.

How do they mount this on their Wandboard? If they have more than six categories, they would have to mount top-level “/media/music” on one of the “/mnt/diskX”. So if they wanted to do maintenance on one part of their audio collection, they would have to umount the entire collection.

Also, as a result of the “/mnt/disk[1-6]” scheme, the mount names and what you see as LMS folders are rather anonymous. For example, a network share like “/media/music/classical” turns into “/mnt/disk1”.

Triode asked if there should be separate mount points for local and remote mounts, while the user shouldn't care, I think this does have several advantages from a design/usability viewpoint.

For example, if there was a single mount in the system of remote mounts, called say “/mnt/NAS” or “/mnt/NetShares”, then the user just adds as many remote shares as they want (nfs or cifs) under this single point and a share like “/media/music/classical” would map to “/mnt/NAS/classical”, and “/media/music/jazz” would map to “/mnt/NAS/jazz” etc. You would then see meaningful folder names in LMS.

Local external drives/partitions could be mounted under a single point in the same way, say under ”/mnt/local/”, or even under “/media”. How to deal with attached USB memory sticks is an open question.

This leaves the question of running a SAMBA server. I believe we only need to share locally attached storage. As soa-aur on Arch has no normal user, just root and system user jivelite, you could expose everything under “/mnt/local/” with a samba config that has “security = user” and “guest account = root”. This would make all local data available as a public share fully rw. That may not be restrictive enough for some users. It should also be possible enabel/disable any SAMBA server via the soa-webUI.

I think the current/proposed scheme ( “/mnt/disk[1-6]” + “/storage” ) has a number of limitations, and if the project wishes to progress from the “developer” stage and has any ambitions to be usable on a variety devices, and not just the Wandboard, then I think it's worth the effort of getting the “soa-web” storage functions into better shape.

[gstew]

This arrangement works for me.

BTW, is it possible to add a page called "Optimization"? What I want see on this page is the ability to disable/enable services. So if I don't need Samba, then I want to be able to disable it. I found that by running minimum number of background processes, the sound would get better even if it is just acting as a LMS server.

Ideally, it'd show as many possible services (such as crypto), and disable processes which are not needed at all. Thanks.

+1!!!!

Greg in Mississippi

[Triode]

I've created a new install script for SolidRun's cubox-i / hummingboard. This is tested on a hummingboard 1 so I would be interested for positive results from other SolidRun products if anyone has them.

To create the install image from a linux machine, where /dev/sdX is the device containing the sdcard.

wget https://raw.githubusercontent.com/SqueezeOnArch/soa-installers/master/create-sdcard-soa-cubox-i.sh
chmod 755 create-sdcard-soa-cubox-i.sh
sudo ./create-sdcard-soa-wand.sh /dev/sdX

I expect everything to work except wifi at present as I am not sure what nvram files should be used.

I must say I am reasonably impressed with a hummingboard 1 - its a single core, but can run squeezelite and jivelite at the same time with only some slowing down of jivelite if upsampling with squeezelite.