Pine64 as Squeezebox Touch replacement (running on Armbian?)

[Learnincurve]

Hi,

 

  Wasn't sure where to start this as it's at-least potentially and partially off-topic regarding Armbian.

 

First of all, thanks for what appears to be the best distro for the small ARM-soc devices, including the PINE64. I really appreciate all the work and houtrs that many people are dedicating to the project.

 

 

Some history:

 

The Logitech Squeezebox Touch was launched in April 2010)

 

 

It has

• 4.3" colour touchscreen
• Connects to Logitech Media Server (LMS) through Ethernet or Wifi and plays songs stored there or from a wide range of internet sources.
• Supports 16- and 24-bit audio with a sampling rate of up to 96 kHz (or up to 192 kHz, enabled by use of a free third-party plug-in.)
• Supports asynchronous USB digital audio output, enabled by use of a free third-party plug-in.
• Native WMA lossless support.
• Can pass through DSD streams if repacked as PCM (DoP)
• Has a builti DAC of reasonable quality, that can handle PCM up to 96 kHz, but can alos output to an external DAC, through COAX, TOSLINK or USB

Logitech discontinued the whole squeezebox line in 2014, but the community is keeping the project alive, with LMS and plugins being actively developed.

An open source player "Squeezelite" replaces and improves on the audio-functionality of the squeezebox and the Jivelite interface provides a Squeezebox Touch-like UI.

 

 The original touch is starting to show its age. The hardware is starting to fail and suffers from some limitations (especially relating to the ARM USB implementation of the time), It is locked to a 2.6 kernel and cannot be made to support higher bitrates/-dephs than 192KHz@24. DSD is only supported as DoP and is limited to DSD64 (SACD quality).

 

 

There is an active community developing Squeezebox touch-like implementations on ARM. Mostly for the R. Pi., But even recent versions of the R. Pi have some USB bus compromises that might impact sound quality.

 

 

 

Who am I and what do I want?

 

I'm a linux-tinkerer. Definitely not developer material. But I know my way around a linux system enough to fiddle a bit here and there, compile a kernel and try to put the bits together to make a system out of a base distro plus code taken from other places. I also prefer to build things myself than to buy them

 

I'm interested in music and audio-quality and fool myself into thinking that I can hear the difference between different bit-/samplerates and streams.

 

I'm financially-challenged enough that the difference in price between a R.Pi3  + 7" screen and a Pine64+ + 7" screen is enough to take on the project, or not.

 

I want to build a Squeezebox-touch replacement, including Jivelite UI, with touch and IR interfaces, providing the cleanest possible digital audio passthrough to USB DAC

 

PCM over USB support up to at-least 192kHz/24bit  - 352kHz/32 bit nice to have.

DSD native (not DoP) over USB up to at-least  DSD128 (5.6448 MHz) - DSD512 (22.5792) nice to have.

 

 

Why the Pine64?

 

Within my budget it ticks a lot of boxes:

• Plenty of processor and RAM headroom
• Gb ethernet interface (when it works) that is independent of the USB bus
• Two, dedicated USB ports, hardwired to the soc (no onboard hubs)
• A cheap 7" touchscreen that doesn't use USB for touch.

 

Why Armbian?

 

Probably the best support "out-there" for the board

Active, dynamic community

Fully packaged (Debian/Ubuntu .debs)

Supports LCD and touch "out-of-the-box" (with legacy kernel).

Provides tools/framework for kernel-compilation.

 

 

Current challenges:

 

Touchsceen  (gt9xxf_ts) is not working well with Jivelite. I have managed to compile/install tslib, but am having problems getting tslib to recognise the touchscreen:

"tslib: Selected device is not a touchscreen (must support ABS and KEY event types)"

Armbian is not tweaked for audio:

• I was planning to compile a RT kernel, removing anything I don't need. I successfully applied the RT patches from kernel.org and have compiled a basic kernel using the Armbian kernel compiling toolkit,  but am having trouble with the .deb creation step, which is failing with very little logging. I'm wondering whether it might have to do with the kernel name not being accepted by the script.
• I have found a beta version of a headless distro ("volumio") that boots up and contains many of the audio-tweaks I'd like to apply. The kernel appears to be RT (but is not packaged) and some audio-centric module options are applied. I have not yet found a way to activate the LCD and touchscreen in volumio.
• Current plan is to take the best from both distros and try to use them to create a hybrid. I am not yet sure whether this should be Armbian, with volumio tweaks or volumio with Armbian tweaks

 

I'd like to use this thread, if possible, to try to solve issues from an Armbian-Centric perspective.

 

Any advice regarding :

 

1. understanding why tslib is refusing to recognise the touchscreen

2. using the kernel build script to create a .deb package of the RT-patched kernel

 

and other problems that I'm sure will come up

 

would be greatly appreciated.

 

  BR.

 

Marius 

 

 

[Learnincurve]

More info on tslib issue:

 

 

I compiled and install 

Running eg. ts_test or ts_calibrate, I see the crosshairs but the screen is not reacting to my touches.

I'm, also seeing plenty of

"tslib: Selected device is not a touchscreen (must support ABS and KEY event types)"

here is the content of input6/uevent:

I: Bus=0018 Vendor=dead Product=beef Version=28bb
N: Name="gt9xxf_ts"
P: Phys=input/goodix-ts
S: Sysfs=/devices/virtual/input/input6
U: Uniq=
H: Handlers=event5 autohotplug cpufreq_interactive
B: PROP=2
B: EV=b
B: KEY=400 0 0 0 0 0
B: ABS=265000000000000

As can be seen, the device specifies both "KEY" and "ABS"

Can anyone suggest a next step?

 

BR.

 

--Marius--

[@lex]

Have you tried to apply the suggested modification from stackoverflow answer?

Try to add
input_dev = input_allocate_device();
[..]
set_bit(EV_ABS, input_dev->evbit);
set_bit(EV_KEY, input_dev->evbit);

This reading may help you get an idea how this would possibly work: http://forum.pine64.org/showthread.php?tid=2843&pid=24186#pid24186

After you get tslib to work on FB you need to tell X11 to use it otherwise you calibrate the touch and no application will actually use this calibration, unless you don't use X11.

 

I am doing some experiments with TS, if i get this working i will post my findings.

[Learnincurve]

Thanks very much Alex,

 

I read about that but wasn't sure where to put it.

 

Looking at your link, I see now that it is the Xorg tslib input driver that needs to be compiled into the kernel.

 

I then tried starting jivelite using sudo from the logged in user's session and bingo, the touch screen worked after all, so maybe I don't need tslib after all.

 

I'll mess about a bit and see if I can get it to work.

 

 

BR.

 

--Marius--

[Learnincurve]

Thanks lex for the precompiled tslib for X .debs.

 

Installed them and tslib works a treat.

 

  Unfortunately I'm still not able to launch jivelite as root (as a service) and have the touch events picked up correctly on the screen, but definitely one step closer.

[@lex]

I don't have any experience with jivelite and have not looked at the code, but i think it uses FBDEV and you need to tell jivelite to use TSLIB to get the events. Ok, nothing new here.

 

Try to export it at boot:

export TSLIB_TSDEVICE=/dev/input/eventX (or you current input event number) and adapt the code to get the events from this.

Look at ts_print code on how to get  the events.

 

In my case:

sudo su

export TSLIB_TSDEVICE=/dev/input/event6

ts_print (and touch the screen to see the events)

 

or look at the code for ts_calibrate.

ts_calibrate , but remove /etc/pointercal after calibration.

 

Maybe you need to adapt jivelite way to get the events from touch.

 

hope this helps somehow.

[Learnincurve]

Thanks @lex,

 

What you describe is exactly the way jivelite is supposed to work with tslib.  In think that my problem is more to do with the user context in which Jivelite is started than recognition of the touch events as they are recognised fine if I start jivelite from within the session of the user running X, but jivelite can also be started as a service, spawning a fb session. In that case, touch events are completely whacky (although recognised if I start it as recommended using tslib). Ordinary mouse events are completely fine.

 

For the moment I'm simply starting it the first way, as the login user, although there may be advantages with the service approach.

[Learnincurve]

Back to the main topic of the thread. I do now have a working (beta) pine64 / Armbian based system that can connect to a Logitech Media Server and output PCM streams up to 24/384.

 

I made a mistake regarding native DSD as this is not supported in kernel 3.10.  Squeezelite/alsa is silently converting to PCM (which still sounds pretty good).

 

I have a thread on the slimdevices forums if anyone is interested in a cheap, audiophile quality device feeding a USB dac.

 

Edited March 8, 2017 by Learnincurve
Mistake regarding DSD

[Learnincurve]

I'd like to request some help and advice here, as I'm not a coder by any stretch and have hit some problems with the kernel.

 

Here's the challenge.

 

The Legacy 3.10.104 Armbian kernel, based on Longsleep's work, supports the parts of the hardware that I need.   I can run the CPU at full speed and support the LCD (DSI)output and IR.

 

3.10 is quite old regarding sound and specifically doesn't support native DSD audio output.  There are also some later improvements to the USB stack (some of which I can patch in) that improve throughput and reliability.

 

Vanilla is far better regarding Alsa, but is currently limited regarding CPU frequency scaling, has no DSI output or IR port.

 

The question is which way to try to go?  How much work would be needed to get DSI and IR working in Vanilla? What are the challenges and where is the code in 3.10 that would need to be brought in line with 4.10?

Alternatively: is there any chance of backporting the Alsa stuff into 3.10? It seems not as I see no backports after the 2 series that contain the sound tree.   I'll try to join an ALSA forum to discuss that.

 

Solving this would make the Pine64 an almost perfect choice as a touchscreen audio player.

 

 The limit of my abilities is patching existing code, making small edits to the kernel code (with guidance) and compiling.  How can I help to resolve the issues?

 

BR.

 

--Marius--

 

[@lex]

Could you please make a short video of your running Squeezebox (with sound)? Looks like a very nice project.

 

I am not an audiophile, is it easy to hear/see how much better ALSA is on vanilla kernel? 

I will be introduced to the 4.x in the following months, maybe if i get interested i can try to help on the ALSA thing (backport).

Regarding DSD i came across this reading: http://www.mojo-audio.com/blog/dsd-vs-pcm-myth-vs-truth/

 

[Learnincurve]

Thanks @lex,

 

I currently only have headphones attached direct to my DAC (not even through a headphone amplifier) as the system is hooked up to a testbed at work

Thank you for the very interesting article!  I had rad a little about the problems of DSD, but haven't seen them presented in such an easily read way before.

 

My project, which started as an attempt to replace my ageing squeezebox touch, is turning (with the help of my colleague) into a potentially commercial venture. I say potentially, because we still have a lot of work to do and a lot of problems to solve, before we have a working prototype. For the moment, I just have pine screen on a stand, with basic touch-like functionality, running only slightly modified squeezelite/jivelite. The plan is to develop a new control interface and to make sure that we are passing through /or processing the original stream as authentically as possible.  That is the main reason for the interest in DSD, as format conversion is generally considered a bad thing, yet another conversion to PCM is best avoided.  The other reason is that if we ever plan to become commercial, we need to support as many DAC input technologies as possible, as some DACs only support native DSD, while some support DoP.

 

Some pics and very basic/poor video uploaded to my Google drive at  

https://drive.google.com/drive/folders/0B1XH4Yuu5-Nyc2luSEJzTTBmNEU

 

It doesn't give any impression of sound quality, but will show that the device exists and works (as far as it goes). 

 

There are various files in the lower folder, including a compressed, 32GB system image and there is also a folder containing kernels as I play with them.  The kernel in the image does not have the nrpacks fix applied.

 

Regarding kernel:

 

3.10 is a little early in terms of USB throughput (I have patched the Armbian kernel with an nrpacks fix from 3.13 described here), there have been significant changes to the alsa tree, especially regarding DSD. I'm not sure that any of this is sonically significant but it does mean that I am prevented from using some of the output options that are available in the latest squeezelite versions.

 

I wish I were up to doing the backporting work myself, but am not.  If anyone volunteers and needs a monkey for producing diffs or anything similarly dumb, I'd be happy to help and to test as far as my equipment allows.

 

The alternative is obviously to wait for the mainlining effort to catch up.  As of 4.10, I'm missing DSI (lcd) support, higer clock frequencies, IR and USB.. all pretty much show-stoppers, but I do know of and am vary grateful for the community working so hard to bring better mainline support to these allwinner chips., which represent fantastic hardware bang-for-the-buck, coupled with terrible driver support from the manufacturer.

 

 

[Learnincurve]

A little update:

 

   My device is now in daily use at home and works and sounds well.

 

I have two DACS:

• The CMedia CM6632A based S.M.S.L  Sanskrit Pro, which sounds great, but due to limitations in the ALSA DSD stack and the CMedia chip, can neither play native DSD nor DoP, so is PCM only
• The Xmos based Douk Audio DSD1796 XMOS U8 OTG 384K/32bit. Which I bought as a proof-of-concept for DSD. The DAC isn't as good as the S.M.S.L, but does work with DoP. I can't test native DSD with this either, due to the ALSA driver version in the 3.10 kernel.

It would be really good to know if there is any chance of DSI, IR and USB making it into mainline any time soon, as there would then be a real chance of making the unit fully DSD capable.

 

I'm looking into a modular design for a complete, network to Line-out appliance, using

• a "Clearfog Base" for LMS backend/storage/internet connectivity
• a Pine64 for squeezelite/jivelite (frontend) - already built
• an xmos based DAC combo from jsounds

[zador.blood.stained]

48 minutes ago, Learnincurve said:

It would be really good to know if there is any chance of DSI, IR and USB making it into mainline any time soon, as there would then be a real chance of making the unit fully DSD capable.

 

https://linux-sunxi.org/Linux_mainlining_effort#Status_Matrix

[Learnincurve]

According to the list for A64:

IR is ?

USB is WIP and I can't find DSI (although it might go under a different name.

 

Was just hoping that the Armbian devs knew more about the status

 

Thanks for all the good work and I look foward to the next version!