gregvp

Right ! I've more than 10 around : some FT232, some CH340, some PL2303 and some CP2102 ...

Hello,
 
I wish to share my research on getting OpenGL to work on Mali GPU. I realize Armbian focuses on server images, but I suppose many people would be interested nevertheless. I have a Banana Pi Pro and an Orange Pi PC, which both have a compatible GPU. Perhaps it will work on other boards as well.
 
Here are the commands I used to get OpenGL to work.
 
1. Install:
# install GLX Gears, mesa GL and GLU libraries apt-get -y install mesa-utils # install development tools apt-get -y install build-essential automake pkg-config libtool ca-certificates git cmake subversion # install required libraries apt-get install libx11-dev libxext-dev xutils-dev libdrm-dev x11proto-xf86dri-dev libxfixes-dev # get source code git clone https://github.com/robclark/libdri2 git clone https://github.com/linux-sunxi/libump git clone https://github.com/linux-sunxi/sunxi-mali git clone https://github.com/ssvb/xf86-video-fbturbo git clone https://github.com/ptitSeb/glshim # install mali driver cd sunxi-mali                                                                    git submodule init                                                               git submodule update                                                             git pull                                                                         wget http://pastebin.com/raw.php?i=hHKVQfrh -O ./include/GLES2/gl2.h             wget http://pastebin.com/raw.php?i=ShQXc6jy -O ./include/GLES2/gl2ext.h    make config ABI=armhf VERSION=r3p0                                               mkdir /usr/lib/mali                                                              echo "/usr/lib/mali" > /etc/ld.so.conf.d/1-mali.conf                             make -C include install                                                          make -C lib/mali prefix=/usr libdir='$(prefix)/lib/mali/' install            cd .. 2. Build
# Step 1: build and install helper libraries cd libdri2 autoreconf -i ./configure --prefix=/usr make make install cd .. cd libump autoreconf -i ./configure --prefix=/usr make make install cd .. # Step 2: build video driver cd xf86-video-fbturbo autoreconf -i ./configure --prefix=/usr make make install cd .. # Step 3: build GL wrapper cd glshim cmake . make cp lib/libGL.so.1 /usr/lib/ # replace the software GL library with the wrapper cd .. 3. Configure your system
- configure your kernel to allocate memory for the GPU
- make sure mali and mali_drm kernel modules are loaded
- give your user permissions to access /dev/ump and /dev/mali
- configure Xorg to use fbturbo driver
 
4. Test:
# run a basic test glxgears # install and run a GL benchmark apt-get -y install globs /usr/lib/globs/benchmarks/GL_pointz/gl_pointz # try to run a real game apt-get -y install billard-gl billard-gl This all worked out for me rather nicely. The only issue I have encountered is a segfault that many GL programs get when they shut down. I'm currently debugging this issue, but it would be helpful to know others experience it as well, and perhaps get some advice from people experienced in GLX or SDL.
 
Edit: I know glxgears is not a real benchmark, but let me give you some numbers to make it clear what I'm talking about. Results are from Orange Pi PC clocked at 1296000 Hz (and are CPU-bound):
user@bananapi:~$ glxgears LIBGL: Initialising glshim libGL: built on Jun 12 2016 06:12:01 LIBGL: Current folder is:/home/user libGL:loaded: libGLESv1_CM.so libGL:loaded: libEGL.so 2074 frames in 5.0 seconds = 414.688 FPS 2071 frames in 5.0 seconds = 414.085 FPS 2070 frames in 5.0 seconds = 413.915 FPS ^C

Armbian implements some basic 'system logging' at every startup and shutdown and contains a little utility to provide this collected information combined with some more useful debug info from user installations. All that's needed is executing 'sudo armbianmonitor -u' (or armbian-config --> Software --> Diagnostics) and then all this support related information is uploaded to an online pasteboard service automagically (see example output) 
 

 
How to interpret this wall of text? The output is best read from bottom to top since the most important information is collected during upload:
 
At the bottom /proc/interrupts contents to check for IRQ affinity problems (interrupt collissions on some CPU cores negatively affecting performance) Then last 250 lines dmesg output are included. Here you might find important information wrt the last (kernel) events that happened on the machine uptime output including average load statistics (1, 5 and 15 min) free output telling how much physical memory is available and how much swap and/or zram is used (you need to look directly above whether zram is active or not to interpret the 'Swap:' line) vmstat output contains virtual memory usage information since last reboot iostat output contains the same but allows for a 'per device' view since all devices are listed with individual statistics (so it's easy to spot IO bottlenecks by looking at these numbers and also looking at %iowait value) 'Current system health' displays what the system is actually doing while uploading the debug log (on systems where DC-IN monitoring is available also allowing for underpowering diagnosis -- if you read here numbers below 5.0V stop reading the log and tell the user to fix his underpowering issues first) In case the installation has been moved from SD card to other storage nand-sata-install.log will be included in the output 'Loaded modules' allow to look for module related problems If it's an Allwinner board running legacy kernel the whole script.bin contents are included 'Installed packages' shows version numbers of relevant Armbian packages 'Group membership of' should list all groups the user is member of. If this line is missing ignore the whole contents and ask the user to re-submit debug info, this time doing it correctly not as root but using 'sudo armbianmonitor -u' (group memberships are important to understand certain problems, eg. users not being member of audio group won't have success getting noise out of their devices) If the board is PCIe capable list of attached PCIe devices is included The lsusb output lists all connected USB devices and also information about speed (12M, 480M, 5000M) and protocol/connection details (mass-storage vs uas for example) If the user installed the lshw utility and verbosity is set to 4 or above in /boot/armbianEnv.txt some more disk related information will be included  
Important: The debug output also contains all collected support files that follow this naming scheme: /tmp/armbianmonitor_checks_* -- so if a user complains about 'transmission so slow' or 'latest files are always missing' ask him to run 'armbianmonitor -c /path/to/torrent-storage' and afterwards 'sudo armbianmonitor -u' without a reboot in between since then the checking results will also be contained.
 
Everything above of this information at the output's bottom is result of regular logging at startup and shutdown (the contents of /var/log/armhwinfo.log). 
 
At startup the following items are logged: dmesg output, /etc/armbian-release and /boot/armbianEnv.txt contents, lsusb and lscpu output, /proc/cpuinfo and /proc/meminfo contents, network interface information, available partitions and filesystems, on Allwinner boards where /boot/script.bin points to, some metadata information for all MMC media connected to the host (eg. SD card and/or eMMC) and some system health information.
 
At shutdown iostat, vmstat and free output are added to /var/log/armhwinfo.log as well as the last 100 lines from dmesg output. If these '### shutdown' entries are missing after reboots the system crashed while shutting down.

Hi All,
 
I recently bought a cheap 16 character, 2 row LCD display from aliexpress.com for use with my Orange Pi PC. I got it to work without too much pain, but I thought I would document it here for the benefit of others. Some good instructions are already available on the internet, but there are some tweaks required for the Orange PI.
 
Armbian I believe already has the I2C module compiled into the kernel directly. So no Linux Kernal insmod work required, unlike what many Raspberry PI guides seem to imply.
 
Step 1) Buy the things you will need.
 
1. You obviously need a 1602 LCD module which also comes with the the I2C converter. You can buy a 1602 LCD and wire it directly to the 16 GPIO pins required if you want, but that isn't the point of this guide.
2. You will need a level shifter. The LCD display works on +5volts. The OrangePI/H3 GPIO pins are 3.3 volts. I have seen guides stating that you don't need a level shifter, but I'm sure you're slowly frying some transistors in your OrangePI over time.
3. You will need a bunch of jumper cables etc. Like these, female to female only required really.
 
Step 2) Wire things up accordingly.
Thanks to this fantastic guide, the instructions on wiring the Orange PI to the Level Shifter LV ('low voltage') pins, and then the Level Shifter HV ('high voltage') pins to the 1602 I2C module is pretty clear: http://www.raspberrypi-spy.co.uk/2015/05/using-an-i2c-enabled-lcd-screen-with-the-raspberry-pi/
 
 
Level Shifter OrangePI 1602 I2C Backpack LV 3.3V (pin 1) – LV1 SDA (pin 3) – LV2 SCL (pin 5) – GND GND (pin 6) GND HV 5V (pin 2) VCC HV1   SDA HV2   SCL  
Note, you connect the 1602 I2C module/backpack directly to the 5Volt Pin on the PI (Pin 2 or 4) and Ground (Pin 6) respectively.
 
Note: For some strange reason the level shifter works if you don't connect the ground pins to either side of it (i.e. Use the LV, LV1, LV2, HV, HV1 and HV2 pins only). No idea why - electrical engineering degree required I think.
 
If all works well, you should see the LCD module light-up with the top row being a bunch of white bars (you might need to check the contrast setting of the module as well). White bars = uninitialised LCD screen.
 

 
Step 3) Install the required packages int Armbian
Reference:  https://www.abelectronics.co.uk/kb/article/1061/i2c--smbus-and-armbian-linux
sudo apt-get install -y python-smbus i2c-tools Step 4) Check to see what the address of the LCD Screen is:
 
Reference: http://www.raspberrypi-spy.co.uk/2014/11/enabling-the-i2c-interface-on-the-raspberry-pi/
user@orangepipc:~/Downloads/i2c$ sudo i2cdetect -y 0 [sudo] password for userpi: 0 1 2 3 4 5 6 7 8 9 a b c d e f 00: -- -- -- -- -- -- -- -- -- -- -- -- -- 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 3f 40: -- -- -- -- -- -- -- -- UU -- -- -- -- -- -- -- 50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 70: -- -- -- -- -- -- -- -- user@orangepipc:~/Downloads/i2c$ sudo i2cdetect -y 1 0 1 2 3 4 5 6 7 8 9 a b c d e f 00: -- -- -- -- -- -- -- -- -- -- -- -- -- 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 70: -- -- -- -- -- -- -- -- Looks like it's 0x3f as the address on I2C bus 0 (which is apparently right according to the aliexpress buyer feedback comments)
 
Step 5) Download Example Script
 
Reference: http://www.raspberrypi-spy.co.uk/2015/05/using-an-i2c-enabled-lcd-screen-with-the-raspberry-pi/
 
The example script will allow you to send text to the screen via I2C. It is very similar to my scripts for the normal 16×2 screen. To download the script directly to your Pi you can use :
 
wget https://bitbucket.org/MattHawkinsUK/rpispy-misc/raw/master/python/lcd_i2c.py  
Step 6) Adjust the Sample Script
 
I need to adjust the script to reference a 1602 LCD device with address 0x3f, on Orange Pi PC I2C Bus, 0. The script as it is references a device of 0x27 on Bus 1 - it won't work. You might have a LCD device of address 0x27 (you'll know from the previous step), but it seems many of the cheap LCD modules from aliexpress are 0x3f for some reason.
 
Adjusted script below:
 
#!/usr/bin/python #-------------------------------------- # ___ ___ _ ____ # / _ \/ _ \(_) __/__ __ __ # / , _/ ___/ /\ \/ _ \/ // / # /_/|_/_/ /_/___/ .__/\_, / # /_/ /___/ # # lcd_i2c.py # LCD test script using I2C backpack. # Supports 16x2 and 20x4 screens. # # Author : Matt Hawkins # Date : 20/09/2015 # # http://www.raspberrypi-spy.co.uk/ # # Copyright 2015 Matt Hawkins # # This program is free software: you can redistribute it and/or modify # it under the terms of the GNU General Public License as published by # the Free Software Foundation, either version 3 of the License, or # (at your option) any later version. # # This program is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the # GNU General Public License for more details. # # You should have received a copy of the GNU General Public License # along with this program. If not, see <http://www.gnu.org/licenses/>. # #-------------------------------------- import smbus import time # Define some device parameters I2C_ADDR = 0x3f # I2C device address LCD_WIDTH = 16 # Maximum characters per line # Define some device constants LCD_CHR = 1 # Mode - Sending data LCD_CMD = 0 # Mode - Sending command LCD_LINE_1 = 0x80 # LCD RAM address for the 1st line LCD_LINE_2 = 0xC0 # LCD RAM address for the 2nd line LCD_LINE_3 = 0x94 # LCD RAM address for the 3rd line LCD_LINE_4 = 0xD4 # LCD RAM address for the 4th line LCD_BACKLIGHT = 0x08 # On #LCD_BACKLIGHT = 0x00 # Off ENABLE = 0b00000100 # Enable bit # Timing constants E_PULSE = 0.0005 E_DELAY = 0.0005 #Open I2C interface bus = smbus.SMBus(0) # Rev 1 Pi uses 0 (and Orange PI PC, for pins 3 and 5) #bus = smbus.SMBus(1) # Rev 2 Pi uses 1 def lcd_init(): # Initialise display lcd_byte(0x33,LCD_CMD) # 110011 Initialise lcd_byte(0x32,LCD_CMD) # 110010 Initialise lcd_byte(0x06,LCD_CMD) # 000110 Cursor move direction lcd_byte(0x0C,LCD_CMD) # 001100 Display On,Cursor Off, Blink Off lcd_byte(0x28,LCD_CMD) # 101000 Data length, number of lines, font size lcd_byte(0x01,LCD_CMD) # 000001 Clear display time.sleep(E_DELAY) def lcd_byte(bits, mode): # Send byte to data pins # bits = the data # mode = 1 for data # 0 for command bits_high = mode | (bits & 0xF0) | LCD_BACKLIGHT bits_low = mode | ((bits<<4) & 0xF0) | LCD_BACKLIGHT # High bits bus.write_byte(I2C_ADDR, bits_high) lcd_toggle_enable(bits_high) # Low bits bus.write_byte(I2C_ADDR, bits_low) lcd_toggle_enable(bits_low) def lcd_toggle_enable(bits): # Toggle enable time.sleep(E_DELAY) bus.write_byte(I2C_ADDR, (bits | ENABLE)) time.sleep(E_PULSE) bus.write_byte(I2C_ADDR,(bits & ~ENABLE)) time.sleep(E_DELAY) def lcd_string(message,line): # Send string to display message = message.ljust(LCD_WIDTH," ") lcd_byte(line, LCD_CMD) for i in range(LCD_WIDTH): lcd_byte(ord(message[i]),LCD_CHR) def main(): # Main program block # Initialise display lcd_init() while True: # Send some test lcd_string("RPiSpy <",LCD_LINE_1) lcd_string("I2C LCD <",LCD_LINE_2) time.sleep(3) # Send some more text lcd_string("> RPiSpy",LCD_LINE_1) lcd_string("> I2C LCD",LCD_LINE_2) time.sleep(3) if __name__ == '__main__': try: main() except KeyboardInterrupt: pass finally: lcd_byte(0x01, LCD_CMD)  
Step 7) ADD YOUR USER ACCOUNT TO 'i2c' GROUP
 
This is a really useful thing to do, otherwise you'll need to run the python script as ROOT (via. sudo etc.) every  time. No good if you want to write a python script that runs using your normal user account and sends messages over I2C to the LCD.
 
Reference: https://www.abelectronics.co.uk/kb/article/1061/i2c--smbus-and-armbian-linux
sudo adduser <YOUR_USER_ID> i2c eg: sudo adduser johnsmith i2c  
Step 8) Run your script!
 
python lcd_i2c.py Amazing!
 

 
Please note: You can probably use a more advanced library to output data to the LCD, but for now, it probably isn't required:
https://gist.github.com/DenisFromHR (you will need to adjust the code in 'RPi_I2C_driver.py' to refer to port=0, not port=1 to get this to work. Also change the address of the LCD device if required)
http://www.circuitbasics.com/raspberry-pi-i2c-lcd-set-up-and-programming/ 
 
What a level shifter looks like:
 

I do not know if i understand this question the right way. After you have connected the DAC there are three soundcards
aplay -l will show us this:
root@orangepipc:~# aplay -l **** List of PLAYBACK Hardware Devices **** card 0: audiocodec [audiocodec], device 0: SUNXI-CODEC sndcodec-0 [] Subdevices: 1/1 Subdevice #0: subdevice #0 card 1: snddaudio [snddaudio], device 0: SUNXI-TDM0 snddaudio-0 [] Subdevices: 1/1 Subdevice #0: subdevice #0 card 2: sndhdmi [sndhdmi], device 0: SUNXI-HDMIAUDIO sndhdmi-0 [] Subdevices: 1/1 Subdevice #0: subdevice #0 In this case it is possible to access the i2s card with hw:1 or better  hw:snddaudio in your audio applications. (Be aware , that you can see this three cards even when only the Modules are loaded,[pcm0]
daudio_used = 1 is changed in the fex File and there is no Card connected)
 
Regards

tkaiser has built a new Kernel with i2s Modules. With this Kernel and some cheap DAC  e.g. (http://www.ebay.de/itm/Audiophonics-I2S-DAC-ES9023-Sabre-to-Analog-24bit-192KHZ-fur-Raspberry-PI-/291573327639?hash=item43e31fe717:g:TTwAAOSw~OdVZXtm)  it is possible to get good quality sound  out of the Orange Pis. After installing the Kernel
Two Things have to be changed in the fex File:
 
Change Directory to boot:
cd /boot Turn the script.bin to a fex-File and open it in an Editor
sudo bin2fex script.bin script.fex sudo nano script.fex Now change the following Entries:
[twi1] twi_used = 1 to
[twi1] twi_used = 0 and
[pcm0] daudio_used = 0 to
[pcm0] daudio_used = 1 Save your changes and do :
sudo fex2bin script.fex script.bin After a reboot your done.
 
 
I do not know for what the Section [twi1] is good for, i hope nothing serious..
This connections have to be made:
 
5V > Pin 2
Gnd > Pin6
BCK > Pin 27
LRCK > Pin 28
Data > Pin37
 
(according to the Picture "giachi" has posted on the diyaudio Forum http://www.diyaudio.com/forums/pc-based/285427-i2s-connection-orange-dac.html#post4587580
see below)
 
The second Picture is only for orientation on an Orangepi PC, the red Wire is 5V ! Be aware that the Header is rotated by 180°on the One!
 
That´s all .
 
Regards

Had the same issue...
 
underneath ipc_key 1024 for both hdmi and analog
put ipc_perm 0666
this will give all users permission.
reboot and enter command speaker-test to verify

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.      

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