Orange Pi for my audio system

Status
This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.
HOW TO GET THE ONBOARD SOUND WORKING

My Orange Pi PC came with the onboard audio muted. Here are the steps I took to get the sound working from the mini-plug audio jack on the Orange Pi PC and set it be the default playback device.

I access sound via ALSA. First, I unmuted the audio in alsamixer:
1. Run alsamixer. At the command prompt, type:
alsamixer
2. Unmute the Line Out
Move the focus (use right/left mouse keys for this) to the control with the name "Audio Lineout". On my system this was the 6th control over from the leftmost control (the LineOut level). It is a small square that is shown with the partial name "Audio li". When in focus, the full name will appear at the top left of the screen next to the text "Item". With the "Audio Lineout" control in focus, press the "m" key on the keyboard to unmute.
3. Check the level of the Line Out:
Move back to the first control that looks like a vertical bar. This sets the volume for the Line Out. I typically set this to 100% and then turn down the audio in my software. It should not be at zero or all audio passed to line out will be attenuated to the point of being inaudible. Use the up and down arrow keys to change the control to the desired level if necessary.
4.Save changes:
press the escape key to exit and save your changes.

Let's check the audio devices seen by ALSA before proceeding. Type:
aplay -l
(that's a lower case "L") at the command prompt in any directory. The output from aplay should look something like this:
Code:
**** List of PLAYBACK Hardware Devices ****
card 0: audiocodec [audiocodec], device 0: SUNXI-CODEC sndcodec-0 []
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 1: sndhdmi [sndhdmi], device 0: SUNXI-HDMIAUDIO sndhdmi-0 []
  Subdevices: 1/1
  Subdevice #0: subdevice #0
Make a note of the card and device listed for "audiocodec", the audio subsystem included onboard the Allwinner H3 chip.

Next, set the audiocodec to be the default device in the .asoundrc configuration file located in your home directory. Type (only the text after each number):

1. Change to your home directory:
cd ~
2. Open the file in the nano editor:
nano .asoundrc
3. You should be looking at an empty file in the nano editor at this point. Type or copy-and-paste the following into the file:
Code:
pcm.!default {
	type hw
	card 0
	device 0
}     
ctl.!default {
	type hw
	card 0
}
4. Save the file and exit the nano editor by typing, in order:
control-X
y
(enter/return to keep the same filename)

5. you can check that the file was created correctly by typing:
cat .asoundrc
you will see the file contents on the screen.

Now when you start an audio application it should automatically try to use this output for sound.
 
UPDATE ON ORANGE PI AUDIO CODEC:

I've been listening to the audio output via headphones from my Orange Pi. I have to report that I have experienced an occasional problem with playback.

Audio works fine 99% of the time. The sound is a little thin through my headphones, although I have not idea if they are a good load match for the output (32 ohms for each channel). Perhaps the low end roll off is a bit higher. Not sure - I would have to measure the response. It definitely sounds a bit weak below 150Hz.

The problem that has occurred several times now is a sudden and unending stuttering of the audio, as if about 0.05 to 0.1 sec of audio is being repeated over and over again machine gun style, and once it starts it doesn't seem to stop on its own. If I stop and then restart the player (VLC) everything is fine. This isn't happening when I listen thru a USB DAC, so I think it is related to the Allwinner codec specifically.

I haven't seen this problem reported before about the Orange Pi. As the kernel and other systems mature, this problem might just go away.
 
Last edited:
Ah, back again with some news about the Orange Pi (sorry if I am getting carried away with posts in this forum!)...

I for one am reading with interest. I'd not heard about this board prior to seeing this thread but the whole range looks exceptionally good value for money. I have my eye on the Orange Pi Plus 2 (because I feel 2G of RAM is a minimum) - is it similar enough to the Pi PC for your comments here to apply to it too? The Plus 2 is about 300rmb here ($45).
 
I for one am reading with interest. I'd not heard about this board prior to seeing this thread but the whole range looks exceptionally good value for money. I have my eye on the Orange Pi Plus 2 (because I feel 2G of RAM is a minimum) - is it similar enough to the Pi PC for your comments here to apply to it too? The Plus 2 is about 300rmb here ($45).

If I look at the RAM usage through the system monitor when playing back audio (using the desktop, nothing else going on in the OS except the system monitor) I see only about 325MB in use. There seems to be plenty of extra memory for other stuff... this isn't Windoze after all!

I can only comment on the O-PI PC. I haven't tried any of the other Orange Pi models because they don't seem (to me) to have the same amount of "value" as the 'PC.

I Think member jplesset mentioned he purchased an Orange Pi plus in the opening post. He might post his thoughts about your choices...
 
USB WIRELESS DONGLE FOR THE ORANGE-PI (all models)

As I mentioned in an earlier post in this thread, the currently available operating systems for all Orange Pi models comes with only one wireless adapter driver, for devices using either the 8188eu or 8192cus chipset.

I found an adapter on Ebay that used one of these and bought it:
150Mbps Mini USB Realtek RTL8188EU ETV WiFi Wireless Adapter LAN 802 11n G B | eBay
Plugged it in an immediate got a message that wireless networks were available. This dongle is very inexpensive (I paid $6 from a local seller but you can find even better deals), widely available, and is plug and play. I finally have networking on my Orange Pi PC! My earlier attempts at installed drivers for the USB WiFi dongle that I already had lying around were unsuccessful, so I am glad to find such an inexpensive one that works right out of the box.

I thought I would post this in case others are trying to get WiFi working on their Orange Pi boards.
 
It turns out that the SATA connection is actually done through the USB controller, and is _SLOW_. I have yet to find a way to actually use it, but I doubt I'll be happy with the performance rsync-ing new files at 20 megs/sec.

The network performance is very good, and so, I've mounted the drive in another Linux box (the one that's currently hosting my mail server's spam program), and will attempt to run the pi plus over the ethernet. I do have both the wireless and wired networks operational, but haven't attempted to connect the audio USB yet. Maybe tonight.
 
Status update on the Orange Pi:

Found the magic trick to get the network working. The Linux distributions mostly have three boot files. Gotta pick the right one.

None of 'em seem to have the kernel module needed for NFS, though, but Samba is there, so I'm able to mount my remote music drive.

I've installed MPD and Ecasound. No problem with either. Hoping to connect my USB sound DAV tomorrow. My old TB Amiga was instantly recognized, so I'm hopeful that my much more modern 7.1 dac will be too.

The system seems pretty snappy both via GUI and via SSH. At least on a par with my old PC...
 
Update:

Orange Pi Ubuntu dist was happy to recognize my "no-name" USB sound card. It's actually the same designation as it was on my desktop PC, so my MPD configuration is nearly unchanged.

It does work. Listening through headphones right now, to confirm that the network mount is satisfactory, and that the unit has enough computing power to run it all.

I'm just a tiny bit concerned with the load average of 3.25, though the cpu is over 90% idle. Maybe I just need to dive the LA by 4 for the 4 cores?

anyway, this experiment is looking to be successful!
 
Update:

Orange Pi Ubuntu dist was happy to recognize my "no-name" USB sound card. It's actually the same designation as it was on my desktop PC, so my MPD configuration is nearly unchanged.

It does work. Listening through headphones right now, to confirm that the network mount is satisfactory, and that the unit has enough computing power to run it all.

I'm just a tiny bit concerned with the load average of 3.25, though the cpu is over 90% idle. Maybe I just need to dive the LA by 4 for the 4 cores?

anyway, this experiment is looking to be successful!

Curious how this turns out--the faster these little guys get, the closer they get to being an all-in-one audio processor + xover system. My bet is, yes, the max load is "400".
 
Turns out that there seems to be a known bug, with nothing running, the load averageis 3.00, so the load is quite small....

I appear to be running "full up", and no logged or audible dropouts.... Crossover in place and all is working... I like it.

I was able to reduce the Ecasound buffer to a more reasonable 1024 samples instead of the 64k samples I had been using. Much more responsive than before when I change volume or start/stop the player.

I've played 3 cuts so far, with zero dropouts. That's a 2-way crossover, third stereo pair with no filter, dither by SOX (this uses more cpu than either MPD or Ecasound). It's all good.
 
Turns out that there seems to be a known bug, with nothing running, the load averageis 3.00, so the load is quite small....

I appear to be running "full up", and no logged or audible dropouts.... Crossover in place and all is working... I like it.

I was able to reduce the Ecasound buffer to a more reasonable 1024 samples instead of the 64k samples I had been using. Much more responsive than before when I change volume or start/stop the player.

I've played 3 cuts so far, with zero dropouts. That's a 2-way crossover, third stereo pair with no filter, dither by SOX (this uses more cpu than either MPD or Ecasound). It's all good.

Sounds great. I'm having no problems with my Orange Pi PC, but have not yet implemented ecasound or Sox.

Hopefully a new version of ecasound will be released in the near future that includes dithering so that piping to Sox is no longer needed. That is supposedly on the list of improvements for ecasound...
 
The only real surprise I had was that my very large ecasound buffer was causing dropouts simply filling the buffer. I turned it down from 64k to 1k, and all dropouts are gone... Monitoring the network activity, I see a spike when a new cut starts, then low consistent activity until the next music cut starts. I'm planning to remove the old PC tonight, and install the Pi.

Plan is to run the Pi 24x7, and simply switch the amps on when music is wanted. Actually, bootup is pretty fast, maybe 15 seconds or so, including starting MPD.
 
Plan is to run the Pi 24x7, and simply switch the amps on when music is wanted. Actually, bootup is pretty fast, maybe 15 seconds or so, including starting MPD.

This is exactly my plan as well - use some output of the Pi to toggle a mute or PS shutdown pin. The Pi can run 24/7 because its power consumption is very low (1W idle).

How will you be switching on your amps from the Pi (or will you do it manually).
 
I'm going to use manual switching... Much easier to set up, and it's quite convenient in my setup. My two amps are right there, one is plugged into the "trigger" outlet of a power bar that controls the rest of the outlets, so hit the switch on the first one, the rest all come on via a relay. I used to have the computer on the trigger outlet, but that meant either a big thump when the sound card came on, or manual switching of both amps....
 
I'm going to use manual switching... Much easier to set up, and it's quite convenient in my setup. My two amps are right there, one is plugged into the "trigger" outlet of a power bar that controls the rest of the outlets, so hit the switch on the first one, the rest all come on via a relay. I used to have the computer on the trigger outlet, but that meant either a big thump when the sound card came on, or manual switching of both amps....

I wrote a LADSPA plugin that can take action when the audio signal has either fallen below a threshold (e.g. -80dB) for some time, or exceeds a threshold after some inactive period (e.g. when the signal comes back on). The action can be to toggle a GPIO pin for instance, which can control an external power relay switching the amplifier mains. I also came up with a cheap circuit that can work off of an AC output from a DAC that can trigger the relay if you aren't interested in using a GPIO pin...

The idea is to run the Pi, ecasound, etc. all the time and when some audio signal shows up, turn on the amps. After the audio signal is absent for some time, turn the amps back off again.
 
Last edited:
Charlie, I really appreciate what you're doing. In my case, the setup doesn't lend itself to automatic "on" switching. Amp for the "whole house" is upstairs in my office, there's a line feed from the main system to the bedroom system, and you have to change the receiver's input to use it. Main system actually lives in the dining room, right at the opening to the living room. Very convenient to flip a switch there on the way to the living room...

I did this to eliminate the PC from sitting on a bookshelf in the dining room, eliminate the quiet fan/drive noise. The drive holding the music for the Pi is upstairs in the "exercise/computer" room... Silent Pi is a nice improvement.

I was impressed at how fast Richard's plugins compiled on it. The load of running the crossover and music server is maybe 15% of what it can do.
 
Status
This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.