AnonymousPi

I think I have figured it out and it again goes to show what a black box these Chinese H3 devices are. I have been using a 8GB Class 4 SD Card with this device without any issues, other than with Ethernet performance being dismal when using full duplex either at 100mbps or 10mbps port speed. It seems this has been resolved with the use of a Transcend 32GB Class 10 SD Card!?? Although I am also using Armbian 5.20 now, instead of 5.14 on the Class 4 SD Card - so maybe that was it. Who knows how these devices work. Maybe the bus frequency is reduced to match the frequency of the SD Card, which inadvertently kills the Ethernet? Maybe the Armbian 5.20 fixed something. Another one of life's mysteries. Edit: Absolutely nothing to do with the SD Card. Looking like my ISP provided an Over the Air update of my Router/Modem which fixed this bizarre Ethernet issue with the Orange PI PC. I can't seem the replicate the problem, even with the old SD Card or older version of Armbian.

Wouldn't have the slightest clue. Your first battle will be seeing if such a piece of hardware is even supported by Linux. If not, no amount of ALSA configuration is going to help. In any case, the configuration above is for audio output only.

Can you provide a link to the USB Bluetooth adaptor that you bought (aliexpress etc)? I wish to buy one for my Orange PI PC.

Perform 'Step 1' per my guide above, then copy-paste the /etc/asound.conf file to be: pcm.!default { type plug slave.pcm "dmixer" } pcm.dmixer { type dmix ipc_key 1024 slave { pcm "hw:0,0" # "hw:1,0" means HDMI change to "hw:0,0" for analog lineout jack output period_time 0 period_size 1024 buffer_size 4096 rate 44100 } bindings { 0 0 1 1 } } ctl.dmixer { type hw card 0 } ctl.!default { type hw card 0 } The hint on what to do was in my comment within the suggested asound.conf in my original post: # "hw:1,0" means HDMI change to "hw:0,0" for analog lineout jack output

Hi All, After I accomplished my IR Red Key Rick Rolling experiment the other day with much success, and from general end-luser use with Armbian, there were two things which irritated me, which are namely due to the default ALSA configuration that comes with stock Debian and that Armbian inherits. These were: Update: 11 September 2017. This guide will not work for newer Armbiam (Debian) installations which comes with Pulseaudio by default. If you really want what this tutorial provides, you will need to uninstall pulseaudio first: sudo apt-get remove pulseaudio 1) You can't have simultaneous applications using an Audio device. So, how about if I want to stream Internet Radio with 'Radio Tray' but also get system alert sounds, or anything else? Out of luck, you'll get (for example): [ao/alsa] Playback open error: Device or resource busy 2) I want to actually have audio going out of the 3.5mm jack (don't really care about video out), better still if it's the same/simultaneous to what is going out via. HDMI. That means if I have a HDMI TV connected then I can get the sound from the TV, if I don't, then I can just use the 3.5mm jack (i.e. If I'm using my Pi to play Rick Astley headless/without a TV). No need to keep editing /etc/asound.conf every time. Solution? Step 1) Fix the mute on the analog Line-Out in alsamixer (for a start) There's a lot of noise out there about people not being able to get any sound our of the analog Line-Out jack even when having changed /etc/asound.conf. The reason for this is likely due to a mute by default on the analog audio line-out (i.e. the 3.5mm headphone jack) in alsa that you would unlikely to be aware of. I only found this out thanks to a comment here, otherwise I would have thrown by Pi PC out the window today. So to fix, you need to type in the console: sudo alsamixer Then F6 select the 'audiocodec', then tap the right arrow key to select the 'Audio lineout [Off]' item. Press 'm' and you'll get the green 'OO', which means it's now active. Exit alsamixer, and when you're back at the console type: sudo alsactl store 0 ... to store you mixer settings. For your information, the mixer settings are stored to the file: /var/lib/alsa/asound.state ... and if you do a diff of this file after having made the changes in alsamixer, this is what is changed in the alsa asound.state file: control.9 { control.9 { iface MIXER iface MIXER name 'Audio lineout' name 'Audio lineout' value false | value true comment { comment { access 'read write' access 'read write' type BOOLEAN type BOOLEAN count 1 count 1 } } } } Step 2) Change the /etc/asound.conf file As you might or might not be aware, the default /etc/asound.conf file looks something like this: pcm.!default { type hw card 1 } ctl.!default { type hw card 1 } All it is configured to do is give applications direct access to the hardware audio device, and pump the sound either out to the analogue line-out ('card 0') or via HDMI ('card 1'). Pretty basic, but does the job. However, what I wanted was two things: Software mixing before the resulting PCM/Sound is sent to the hardware audio device - This enables me to listen to Internet Radio and Youtube at the same time... Simultaneous Output to both HDMI and analog line-out. If you want only (1) above, and only via HDMI, then the /etc/asound.conf file is this: pcm.!default { type plug slave.pcm "dmixer" } pcm.dmixer { type dmix ipc_key 1024 slave { pcm "hw:1,0" # "hw:1,0" means HDMI change to "hw:0,0" for analog lineout jack output period_time 0 period_size 1024 buffer_size 4096 rate 44100 } bindings { 0 0 1 1 } } ctl.dmixer { type hw card 0 } ctl.!default { type hw card 0 } If you want (1) and (2) (which of course you do), then the /etc/asound.conf file is this: # Thanks to: http://alsa.opensrc.org/Asoundrc#Dupe_output_to_multiple_cards # https://sourceforge.net/p/alsa/mailman/message/33476395/ # Check that a MUTE doesn't exist on the Audio Line Out for Orange PI PC # or you'll get no sound other than via HDMI pcm.!default { type plug slave.pcm "duplicate" } ctl.!default { type hw card 0 } # Create the Software Mixer for HDMI and then link to hardware pcm.hdmi-dmixer { type dmix ipc_key 1024 slave { #pcm "hw:0,0" # pcm "duplicate" pcm "hdmi-hw" # pcm "analog-hw" period_time 0 period_size 1024 buffer_size 4096 rate 44100 } bindings { 0 0 1 1 } } ctl.hdmi-dmixer { type hw card 0 } # Create the Software Mixer for Analogue Out and then link to hardware pcm.analog-dmixer { type dmix ipc_key 2048 slave { #pcm "hw:0,0" # pcm "duplicate" # pcm "hdmi-hw" pcm "analog-hw" period_time 0 period_size 1024 buffer_size 4096 rate 44100 } bindings { 0 0 1 1 } } ctl.analog-dmixer { type hw card 0 } # Route the audio requests to both hardware devices via the mixer. # For some reason we can't have one mixer and then route to two hardware # devices (would be more efficient). pcm.duplicate { type route slave.pcm { type multi slaves { a { pcm "analog-dmixer" channels 2 } h { pcm "hdmi-dmixer" channels 2 } } bindings [ { slave a channel 0 } { slave a channel 1 } { slave h channel 0 } { slave h channel 1 } ] } ttable [ [ 1 0 1 0 ] [ 0 1 0 1 ] ] } ctl.duplicate { type hw; card 0; } # Physical Output Device Mappings - Analogue and HDMI for Orange PI PC pcm.analog-hw { type hw card 0 } pcm.hdmi-hw { type hw card 1 } There you have it. The only downside is that CPU usage for playing music will increase a bit as ALSA will essentially route inputs from applications to two Software Mixers, which are connected to the HDMI and Analog Line-Out hardware devices separately. For some reason you can't have a single Software Mixer route to two hardware devices (or I couldn't get it to work), but whatever. We're talking 20% CPU usage vs. 10% on one core, to play music.

Note: Guide Updated May 2017, as I realise that /dev/input/event3 may not always be the IR receiver device on your armbian installation. Hi All, I recently bought an Orange PI PC and the best thing I ever did was install Armbian straight away (and donate). Now that I have a bit of spare time, I wanted to configure my Orange PI PC to do something ridiculous like play Rick Ashley 'Never going to give you up' upon pressing the 'red button' on some generic Chinese IR remote for an LED light strip I have in my living room. Thanks to Armbian, most of the pieces are in place (such as the SunXI IR package) with the distribution, you just need to glue it all together. However there are few configuration issues with the default Armbian install on the Orange PI PC that need to be adjusted, otherwise you'll encounter infuriating issues such as: No IR device existing or being detected (root cause: sunxi-cir module not loaded) No LIRC 'irw' output even after successfully using irrecord (root cause: DRIVER=devinput doesn't work, though it could be my remote), like this poor sod was experiencing. I should also note that this guide on the terrible Orange PI forums, helped me with my issues. Step 1) Adjust /etc/lirc/hardware.conf Updated: This guide was originally written for Armbian based on Debian 'Jessie'. The latest Armbian (as at September 2017) is now based on Ubuntu Xenial. This introduces a new lirc package which yet again comes with a broken hardware.conf For Ubuntu Xenial (September 2017): The default hardware.conf that comes with Armbian is broken. It's assigning the 'remote' and 'transmitter' to the same device, this breaks everything. Ensure the TRANSMITTER_MODULES="" and TRANSMITTER_DEVICE = "" # /etc/lirc/hardware.conf # #Chosen Remote Control REMOTE="None" REMOTE_MODULES="sunxi_cir" REMOTE_DRIVER="default" REMOTE_DEVICE="/dev/lirc0" REMOTE_SOCKET="" # FYI - /run/lirc/lircd will probably be the socket that the system uses REMOTE_LIRCD_CONF="" REMOTE_LIRCD_ARGS="" #Chosen IR Transmitter TRANSMITTER="None" TRANSMITTER_MODULES="" TRANSMITTER_DRIVER="" TRANSMITTER_DEVICE="/dev/null" TRANSMITTER_SOCKET="" TRANSMITTER_LIRCD_CONF="" TRANSMITTER_LIRCD_ARGS="" #Disable kernel support. #Typically, lirc will disable in-kernel support for ir devices in order to #handle them internally. Set to false to prevent lirc from disabling this #in-kernel support. #DISABLE_KERNEL_SUPPORT="true" #Enable lircd START_LIRCD="true" #Don't start lircmd even if there seems to be a good config file #START_LIRCMD="false" #Try to load appropriate kernel modules LOAD_MODULES="true" # Default configuration files for your hardware if any LIRCMD_CONF="" #Forcing noninteractive reconfiguration #If lirc is to be reconfigured by an external application #that doesn't have a debconf frontend available, the noninteractive #frontend can be invoked and set to parse REMOTE and TRANSMITTER #It will then populate all other variables without any user input #If you would like to configure lirc via standard methods, be sure #to leave this set to "false" FORCE_NONINTERACTIVE_RECONFIGURATION="false" START_LIRCMD="" For Debian Jessie (~year 2016): By default Armbian doesn't have the suxi-cir module enabled at boot-up, but it is available, so you will need to edit hardware.conf to enable this, as well as correct the DRIVER= line and the DEVICE= line, as the defaults in there are WRONG. Also I suggest commenting out Igor's code in the top five lines. A hardware.conf that works: # Cubietruck automatic lirc device detection by Igor Pecovnik #str=$(cat /proc/bus/input/devices | grep "H: Handlers=sysrq rfkill kbd event" | awk '{print $(NF)}') #sed -i 's/DEVICE="\/dev\/input.*/DEVICE="\/dev\/input\/'$str'"/g' /etc/lirc/hardware.conf # /etc/lirc/hardware.conf # # Arguments which will be used when launching lircd LIRCD_ARGS="" #Don't start lircmd even if there seems to be a good config file #START_LIRCMD=false #Don't start irexec, even if a good config file seems to exist. #START_IREXEC=false #Try to load appropriate kernel modules LOAD_MODULES=true # Run "lircd --driver=help" for a list of supported drivers. # 'devinput' driver on Orange PI PC causes NO EVENTS TO OCCUR # via irw for some reason. DRIVER="default" # usually /dev/lirc0 is the correct setting for systems using udev DEVICE="/dev/lirc0" MODULES="sunxi-cir" # Default configuration files for your hardware if any LIRCD_CONF="" LIRCMD_CONF="" Step 2) Restart lircd service As lirc is actually already running and installed in Armbian, do the following: root@orangepipc:/etc# /etc/init.d/lirc stop root@orangepipc:/etc# /etc/init.d/lirc start To reboot the service. Then perform an 'lsmod' to see if it loaded the sunxi_cir module (because otherwise nothing will work): user@orangepipc:~$ lsmod Module Size Used by mali_drm 2732 1 drm 178255 2 mali_drm mali 123208 0 ump 29379 3 mali sunxi_cir 1601 0 8189es 1076034 0 Step 3) Find out what '/dev/input/eventX' device is your IR receiver If you do a: ls /dev/input/event* You will most likely get a bunch of possible event devices to choose from, for example: anonymouspi@orangepipc:~$ ls /dev/input/event* /dev/input/event0 /dev/input/event2 /dev/input/event4 /dev/input/event1 /dev/input/event3 /dev/input/event5 For my installation, /dev/input/event3 is the IR receiver, but if you have other devices installed (i.e. USB cameras, keyboards etc.) then the number could be different. For example, executing 'evtest /dev/input/event3' reveals: Input driver version is 1.0.1 Input device ID: bus 0x19 vendor 0x1 product 0x1 version 0x100 Input device name: "sunxi-ir" A device name of 'sunxi-ir' means that we are using the right device for the purposes of evtest Step 4) Do a quick test with with 'evtest' (OrangePI PC armbian seems to use /dev/input/event3 for IR input ) Armbian has the 'evtest' program installed, point the IR remote (in my case a LED colour remote) at your Orange PI PC and as root 'evtest /dev/input/event3'. root@orangepipc:/etc# evtest /dev/input/event3 Input driver version is 1.0.1 Input device ID: bus 0x19 vendor 0x1 product 0x1 version 0x100 Input device name: "sunxi-ir" Supported events: Event type 0 (EV_SYN) Event type 1 (EV_KEY) Event code 152 (KEY_SCREENLOCK) Event type 4 (EV_MSC) Event code 4 (MSC_SCAN) Key repeat handling: Repeat type 20 (EV_REP) Repeat code 0 (REP_DELAY) Value 500 Repeat code 1 (REP_PERIOD) Value 125 Properties: Testing ... (interrupt to exit) Pressing the remote reveals events like: Testing ... (interrupt to exit) Event: time 1472917554.113967, type 4 (EV_MSC), code 4 (MSC_SCAN), value 58 Event: time 1472917554.113981, -------------- EV_SYN ------------ Event: time 1472917554.464390, type 4 (EV_MSC), code 4 (MSC_SCAN), value 59 Event: time 1472917554.464398, -------------- EV_SYN ------------ Event: time 1472917554.842832, type 4 (EV_MSC), code 4 (MSC_SCAN), value 45 Event: time 1472917554.842839, -------------- EV_SYN ------------ Event: time 1472917555.345584, type 4 (EV_MSC), code 4 (MSC_SCAN), value 58 That was the red, green, blue and white buttons being pressed. This is a good news. Step 5) Configure lirc to map IR input to key presses or events. Again, Armbian has irrecord installed (great work Igor), but given I'm re-using this remote to configure the output of a LED strip I have, I'll need to map the IR data sent, to something more meaningful. In other use-cases this isn't generally required as lircs provides a database of media remotes which is pre-mapped to Linux commands/keyboard keys. There's plenty of information on how to use irrecord, command I used was: /etc/init.d/lirc stop ...to first stop the service, then: irrecord -H default -d /dev/lirc0 /etc/lirc/lircd.conf ... to record my remote and bind to 'keys'. Step 6) Test with irw Now that I recorded my configuration file with irrecord: /etc/init.d/lirc start .. to start lird service again then type 'irw' and check that the key mapping works when I point the remote at the Orange PI PC and press a button: root@orangepipc:/etc# irw 0000000000ff1ae5 00 KEY_R /etc/lirc/lircd.conf 0000000000ff1ae5 01 KEY_R /etc/lirc/lircd.conf 0000000000ff9a65 00 KEY_G /etc/lirc/lircd.conf 0000000000ff9a65 01 KEY_G /etc/lirc/lircd.conf 0000000000ffa25d 00 KEY_B /etc/lirc/lircd.conf 0000000000ffa25d 01 KEY_B /etc/lirc/lircd.conf 0000000000ff22dd 00 KEY_W /etc/lirc/lircd.conf 0000000000ff22dd 01 KEY_W /etc/lirc/lircd.conf Hoo Ray! Step 7) Create a /etc/lirc/lircrc file to run commands sudo vi /etc/lirc/lircrc I'd actually call mpv here and call the player: # http://www.lirc.org/html/configure.html begin button = KEY_R prog = irexec config = mpv /home/root/Rick\\ Astley\\ -\\ Never\\ Gonna\\ Give\\ You\\ Up.m4a & echo "COMMENT RICK ROLLING" & end begin button = KEY_W prog = irexec config = killall mpv & echo "SADFACE!" & end begin button = KEY_B prog = irexec config = mpv http://sj256.hnux.com & end You could also create a file for each user of the system if you want, eg: /root/.lircrc, /home/userXXX/.lircrc However if you do this, you will need to start the irexec service manually. If you have a /etc/lirc/lircrc file, the irexec service will start automatically at boot - this service is what actually converts the key press to the command. So there you go, Rickrolling with a simple press of the red (KEY_R) button :-) Additional References: [Guide] Android + InfraRed (IR) + Kodi How to setup Remote Control for Linux

It shouldn't be the power supply as I have bought the official one from the Orange Pi Ali express shop. Running any stress testing doesn't cause any problems, other than the CPU getting a bit hot, which I'm waiting for a heat sink to resolve. I think there is something wrong with my board.

Hi All, As tkaiser said, this in Orange Pi PC, so no Gigabit Ethernet, stock standard 100baseT. I am using the power supply from the official Orange Pi shop: http://www.aliexpress.com/store/product/orange-pi-orange-pi-plus-Europe-Power-Adapter-5V-2A-Europe-Power-Supply/1553371_32281484383.html?spm=2114.12010108.0.99.x7sufL There is definitely something wrong with this device and I am going to request a refund. For the time being, I have had to stick a 'post-up' line in the /etc/network/interfaces file to force it to 10baseT/Half ! # Wired adapter #1 allow-hotplug eth0 # iface eth0 inet dhcp iface eth0 inet static pre-up ethtool -s eth0 speed 10 duplex half autoneg off address 192.168.1.10 netmask 255.255.255.0 gateway 192.168.1.1 post-up sleep 6; /sbin/ethtool -s $IFACE speed 10 duplex half autoneg off # hwaddress ether # if you want to set MAC manually # pre-up /sbin/ifconfig eth0 mtu 3838 # setting MTU for DHCP, static just: mtu 3838

Edit: Nothing was wrong with the Orange PI. I turned out to be my switch. Hi All, Firstly, Armbian is just fantastic. Secondly, this issue is highly likely to have nothing to do with Armbian, but just the cheap crap you'd expect from a cheap SBC. Essentially, after much pain and anguish having bizarre Ethernet connectivity issues with a shiny new Orange PI PC I bought a couple of days, which was: 1. When OPI was connected my network switch (which has four other devices connected to it: two Ethernet and two WiFi), none of the other devices can reliably 'ping' or SSH to the OPI... 25% to 100% packet loss. 2. When connecting the OPI physically directly to existing devices (i.e. PCs) with a crossover cable and using a static IP (same as in 1) above), I can use the Orange PI PC without issue. It's fast. 3. When using the OPI itself to download or connect to the internet, it performs erratically (fantastic for minutes, then slow as hell again). To ensure that it wasn't an issue with the switch or the other computers, I have tested connectivity between all of these and it has been flawless. So, I was about to throw the OPI into the bin, then I decided to force the Ethernet device to half duplex with: ethtool -s eth0 speed 10 duplex half ... and whilst I lose a whole bunch of speed, connectivity has been consistent. I don't get any interesting errors in any of the kernel logs either. Interestingly enough, if I attempted to ping other computers on my LAN from my OPI, the OPI would say there was about 50% packet loss. However, if I had a packet logger running on one of the machines, it would clearly log the received ICMP packet, as well as a response that the PC was sending back to the OPI. Q: Do you think I have a faulty board? Q: Is this something somebody else has experienced? Unfortunately I don't have another switch to test with to truly rule out some obscure issue with it, but given I have at least two other devices connected by Ethernet which work flawlessly, I'm not convinced it is the switch. I suspect the OPI's oscillator for the 25Mhz signal PHY rate generated for the physical CAT5e might be busted, causing incompatibility. It might be time to buy a cheap crap RealTek USB WiFi dongle instead - I'm sure that'll be a saga in itself. Thanks for any advice in advance.

Hi, Just joined to say thanks to all to those that are involved in the development of Armbian. I recently bought an Orange Pi PC after reading the internet full of people bitching about non-booting devices, HDMI issues, overheating and general crapness. Decided to buy a Orange Pi PC nonetheless, found an old crap micro SD card, burnt Armbian (the internet has made it clear to not bother with the crap on the official Orange Pi website!) onto it and the thing booted without any issues! Typing this message from it as we speak in Iceweasel! The thing only cost me 9 quid, so decided to donate what I would have wasted in cash on a Raspberry Pi 3 (which is anything but the 25 dollar SBC it seems to be advertised) as a donation to Igor and co. I just run the Orange Pi PC out of the plastic static bag it came in LOL! Once again, great work.