Hello!

I noticed a small problem with my rock64 and I can't get to fix it.
So basically I installed LibreELEC on my Rock64 and I noticed that if I don't turn on my tv/monitor within the first minute then there is no output signal.
I tried searching for the problem however I could not find specifics.
The only solutions I found were for the RPi, which did'nt work.

Is this a known issue? Has anobody else noticed this? Suggestions?

Thanks!

I have two things I would like to find benchmarks/information for. I apologize ahead of time if they are in another thread. I couldn't find them via google or the search function on this forum.

1. Does using a higher quality pci to NVMe adapter improve the performance? Ideally, the PCI lanes should each be able to contribute 400 MB/s for a total of 1.6 GB/s. The only benchmarks i've seen cap out at 540 MB/s write and 1.3 GB/s read. The SSD being tested in those is rated to be able to achieve much higher performance in both areas. I don't know if the difference is due to internal limitations of the processor or the PCI adapter itself. Hence my question.

2. I would also like to know if using a USB type C to ethernet adapter improves the network performance compared to using the built-in ethernet port.

Hi.

                 Having recently purchased several rock64 boards and a pine A64 , i am horrified to find it supports node red but has no GPIO nodes.( the main reason for using node red ).

     It either doesn't exist or i've got to take a linux degree to do it. ( unfortunately im a PLC engineer and my brain is fuddled as it is ).
ive scanned this forum and the internet for hours......no joy

please put me out of my misery, or shall i ebay the lot???

Little owl...

This card is not happy......Anyone know what is going on?? I have a RockPro64 V 2.1 ,ASMedia ASM1061 (THe one that Pine sells) and a, Samsung 860 EVO SSD 1TB

I began this thread (mistakenly?) on the release GitHub page for ayufan-rock64, found here:

https://github.com/ayufan-rock64/linux-build/issues/270

After a few days of no answer there, I figured I should post what's been going on over here in the forums.

Hello all. Big, big fan of your hard work and determination, ayufan.

The following occurred using both of these images:
1: stretch-openmediavault-rockpro64-0.7.9-1067-arm64.img.xz
2: stretch-openmediavault-rockpro64-0.7.9-1067-armhf.img.xz

The title says it all. On first boot, the console shows the following error more than once (at least twice):

Hi,

I have a RockPro64 with the sata drives being used for a file server. It serves my movies to my three kodi boxes running on Raspberry Pi 3.


the problem I face is when I try to stream a movie, every kodi box freezes at around 51 seconds. The error is a connection timeout with the RockPro64 box.

I have tried OpenMediaVault and a plain Debian install with NFS on my Rockpro64 box, and both experience the exact same issue. I have also tried multiple hard drives. I know the problem is not with the Kodi boxes because it is happening to all three of them, and my original Windows PC that is acting as a file server now does not have this issue.

What could be the problem here? The RockPro64 should have plenty of resources to do this. Did I just get a lemon?

Thanks!

I placed an order that has rockpro64 4GB and a 64GB emmc.
But I forgot to buy an emmc usb reader.

Do I really need the emmc usb reader to flash a linux os?

I can't figure out if there is an easy way to flash the emmc from the NOOB wiki topic
http://wiki.pine64.org/index.php/NOOB#In...MC_Modules

Is there a way to flash the emmc with a SD Card?


Is there any way to add, additional item to an existing order (in order not to have double shipping costs)?

P.S. First time with an sbc, total noob...

Hello,

I'm little confused about what information is in Baseboard datasheet for Sopine.
For example, there is shown that on baseboard is Micro USB connector as power supply, but real on baseboard is barrel jack connector.


Or in datasheet eMMC page, there is no connector for eMMC, only some connections.

Is there datasheet of board which is on production?

Thank you

Hi people

For the (probably a minority) who need to use the RTC backup with a coin cell:

The RTC is powered from a 3V supply via a Schottky diode when the Pine64 or Sopine is powered. In theory, a coin cell should be able to back up the RTC when power is off so that a reasonable time reference is available even when there is no network.

Lithium coin cells when new are significantly above 3V, and depending on temperature and newness could be up to 3.3V. This means that if the coin cell is connected via a similar diode, then the RTC will be powered from the coin cell even if the Sopine is fully powered, until the coin cell is partly discharged. 

A possible solution to this would be to increase the supply fed to the diode connected to the RTC pin to 3.3V. 

A solution we are testing for Buffalo Grid, on a custom baseboard for a Sopine, is to use a simple circuit with a P channel MOSFET (connected to conduct in the reverse direction to normal) and a P channel JFET, which is switched off (because it is depletion mode) by the 5V supply connected via a resistor to its gate. When the 5V supply falls below the threshold of the depletion fet, it switches on and that switches on the MOSFET, connecting coin cell to RTC pin.

This only works for cells with a voltage slightly above 3V, because there is still the body diode of the MOSFET which can conduct if there is too large a voltage difference. However this is a junction diode so has a higher forward voltage and lower conduction at low voltages than a Schottky diode. We expect this to make the coin cell last a useful amount longer in its backup role.

It might be a good idea to incorporate a fix for this problem on any new editions of Pine boards.

-Andrew

Greetings,

Hopefully this will shorten the learning curve for someone.  If not, at least I can search the forum for my own post at some point if I have a disaster.

Setting up multi room audio with multiple pine devices.  Want to play internet radio, a small audio library, and Spotify through the house.

The journey starts with Volumio - distros are available for most of our devices. The Volumio forum has the latest links.  gkkpch has done a lot of work.  I need to buy him a beer.  You do too.  

Rock64:  https://volumio.org/forum/volumio-rock64-t9467.html
Pine64/LTS-SOPINE:  https://volumio.org/forum/volumio-pine64...t9465.html

Burned these onto their respective flash cards.  Decided to have a Rock64 as the server and a Pine64 as the client.  

Initial install was pretty straight foward.  There is a guided setup for the software through the web interface once you launch.  

Now you have two media boxes.  They show up together in Volumio but they play different streams.  To connect the boxes together you need a way to synch the audio.  I choose Snapcast.  You need to install both the Snapcast application and the Volumio Snapcast plugin for command and control.

At the time of writing the latest version was here:
https://github.com/badaix/snapcast/releases/tag/v0.15.0

You will need the client and the server.  The server will need to install both but for the client . . . only the client.

Grab the arm versions (armhf).  Get them to your pines in the manner you see fit.  To install:

sudo dpkg -i snapclient_0.15.0_armhf.deb
sudo dpkg -i snapserver_0.15.0_armhf.deb
sudo apt-get -f install

The Snapcast app and overview is described on Github:  https://github.com/badaix/snapcast  

Now you need the plugin.  As it is not an official Volumio plug in you need to load it manually.  Instructions are here: https://github.com/Saiyato/volumio-snapcast-plugin.  In short:

git clone https://github.com/Saiyato/volumio-snapcast-plugin.git
cd volumio-snapcast-plugin/
rm volumio-snapcast-plugin.zip

Now . . . there is currently an issue.  It may be fixed but you need to put in one more command before the plugin install.

npm i

Then:

volumio plugin install

On the server, go to the snapcast plugin.  Enable the server, pick any sample rate that you want as long as it is 44,100Hz, 16 bits, 2 channels.  For both the server and client enable the client.  Server's host should be local while client's host should be server.  (Duh)  Pick the right sound port.  Especially if it's 2am and you're pulling your hair out.  MPD choose the same sample rate, bit depth, all that everywhere.  For the server select FIFO only.  For the client select ALSA.

Spotify Integration.  (Still in the Snapcast Plugin.)  I used no dedicated stream - and the spotify web connect.  The sample rate, bit depth, channels should be the same for server and client and mpd.  Don't dinker with Librespot.

Leave the rest of the stuff alone if you value your sanity.

Reboot your devices for good measure. 

To test your masterpiece try this on the server:

sudo cat /dev/urandom > /tmp/snapfifo

Dumps white noise out your speakers.  All your stations should start and end at the same time.  If not . . . problems.  You should hear a delay.

Next see if you can play a webradio from server to client.  Does it sound good?  Nice.  Do you want Spotify too?  Probalby not working yet.

What I did that works:

On the server go to /data/plugins/music_service/volspotconnect2 and find the volspotconnect2.tmpl file.

Replace the one meaningful line in the file with the below:
./librespot -b 320  -c /tmp ${shared} ${normalvolume} --name '${devicename}' --backend pipe --device /tmp/snapfifo --disable-audio-cache --initial-volume ${initvol}

Save.  Go to the Spotify plug in, make a change, and save.  This will burn a new startconnect.sh file with your changes.  The original version had the backend as alsa and the output device as a local device.  So the music only played to the server's device.

Try Spotify.  Cross your fingers real hard.  Open your Spotify client, find your server under "connect to device" and play some nice tune.

If you have done everything right you will get beautiful music out of all your speakers.  If you have not lived life on the straight and narrow bad stuff will happen.  Now it's time to swear a bit and figure out what went wrong.


Gotchas / notes
The default sample rate of 48kHz and 16 bits works just fine for web radio.  For Spotify it sucks out loud.  The audio is higher pitched and warbles.  It's a sampling rate problem between the Spotify stream and the resampling.  (I read this somewhere, maybe I will find it again some day.)  There might be another way around it, but just be sure everything matches up and you should be fine.

If there is a volumio update and you want to upgrade - you can do it through the app but you need to go enable "test" softare.  Go to your volumio box url and add "/dev" after the address.  Push the right button.  Turning on SSH while you're there probably is smart.

The Rock64 Volumio build does not support the rtl8812au based wifi adapter sold in the Pine store.  There has been discussion on this but it still is not there.  I tried cheating a bit to build a driver but not all the bits were in the load to make that happen.  Left this for another day.

---
Bonus Round!  Making a Rock64 Ubuntu Bionic Client

This is pretty easy as well.  Grab the 64 bit version of your choice from ayufan's git.  Burn it to a memory thingie and start the silly thing up.

EvilBunny has done the WiFi driver work for you.  Grab the file, load it, be sure you've got python installed.  (sudo apt install python)

sudo dpkg -i drivernameofyourchoice.deb

sudo depmod
sudo modprobe 8812au

Configuring WiFi - you're on your own.  

There is no arm64 bit Snapcast on Git, you you need to build your own.  Luckily there are step by step instructions on the site.  
https://github.com/badaix/snapcast/blob/...nux-native

The instructions work. Start at the top then follow the Debian instructions.  The build runs on one core so it takes a bit.

Repeat the dpkg stuff from above and . . .

Craft the command for the snapcast client.  Check the plug names with aplay -l and choose which one you want to use.  (You should be able to have more than one client running but my testing has ended poorly on that front.  More work to be done there.) 

The client command documentation is a little light.  "snapclient --help" gives you the basics.  I used the following with a static internal IP address as the server.

sudo snapclient -s I2S -h 192.qq.yy.xx -d --user snapclient:audio

This will automagically run at startup.  I haven't figured out how to kill it actually . . . but that's for another day (and more edits).

---

Yeah I should still do some more experimenting and close the loop with some folks.  But for now I'm going to take a break from pulling my hair out and enjoy the sweet sound of success.  

I will maintain this post based upon learnings, feedback is appreciated and welcomed.  

Best Regards,


Matthew