Onion Omega Media Center

Project Logs

Collapse

Project moves forward after rather long break
andriy.malyshenko • 04/15/2024 at 10:20 • 0 comments

I decided to move this project forward after the rather long break. I'm seeing some king-of-the-line media center products that would share similar form factor, but based on different hardware platforms would address different use cases.

It started with ESP32, which is the smallest of the lot, then Onion, then Raspberry Pi zero, and then Orange Pi.

Onion is not a powerhouse compared to the Raspberry, but it is much easier to work with, compared to the ESP platform. It has both Ethernet and WiFi onboard (which both Raspberry Pi Zero and Orange Pi One don't), also it doesn't rely on the SD card, which makes it indestructible in the long run.
All and all I think this is a fun platform to tinker with (although slightly forgotten these days), with a lot of potential yet to be discovered and developed.
Project update
andriy.malyshenko • 06/06/2021 at 20:12 • 0 comments

It's been a while since I worked on the project, since I'm a bit carried away by other projects at the table. But no worries, it is not abandoned. Actually I'm trying to push some minor improvements each time I order PCBs for other projects.
So for new version few improvements are done:
- I've prepared version with Onion Omega2S.
- I've soldered on the board ¢50 UART chip to make my life simpler during development and debugging
- Fixed few minor issues with power circuitry
Hope I'd have enough time to test and verify all the board functions after latest updates.
Streaming audio over network
andriy.malyshenko • 01/28/2021 at 22:16 • 0 comments
Below are the steps that I took to configure Onion Omega Hi-Fi as network streaming node.

As I've mentioned before I use mopidy as music server. It runs in docker actually on one of the SBCs within my network. As I did describe before I use pulseaudio on raspberry or orange pi connected to DAC and them to amp. Therefore it looks like this

[Music Server with Mopidy] => [pulsesink] -> [ethernet] -> [pulse-daemon] => [Raspberry with DAC] -> [Power Amp].

Now here with Omega this setup is failing unfortunately. Pulse (or rather alsa) is somehow broken on Omega, and as long as you install it Omega will go into boot loop with kernel panic message as soon as pulseaudio starts.

Therefore I was looking for alternative solution. Luckly mopidy uses GStreamer, which is extremely flexible in possibilities.

First let's prepare Omega to accept network stream with Gstreamer
```
# you may need to uncomment feeds in /etc/opkg/distfeeds.conf
root@Omega-365D:~# opkg update
root@Omega-365D:~# opkg install gstreamer1 gstreamer1-utils gst1-plugins-base gst1-mod-udp
```
Now let's make sure that we already have configured I2S audio that is working fine
```
root@Omega-365D:~# aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: AudioI2S [Audio-I2S], device 0: ralink-i2s-HiFi HiFi-0 []
  Subdevices: 1/1
  Subdevice #0: subdevice #0
```
Test if gstreamer able to speak to alsa
```
# this should produce tone sound in the speakers
root@Omega-365D:~# gst-launch-1.0 audiotestsrc ! audioconvert ! audio/x-raw,format=S16LE,channels=2,rate=44100 ! alsasink -v
```
Here we have to do audioconvert to format that kernel module would accept. Unfortunatelt at ths stage this is the only format it would accept actually. Every other will crach gstreamer at best and leads to kernel panic at worst. But for now this will do.,

Now let's start gstreamer listening on udp for data to come
```
# we start listening on udp port 5000 and expect to have specific format that alsa would accept
# then stream is sent to alsa device, since we have just one, no parameters needed
root@Omega-365D:~# gst-launch-1.0 -v udpsrc port=5000 caps="audio/x-raw, rate=(int)44100, format=(string)S16LE, channels=(int)2, layout=(string)interleaved" ! audioconvert ! alsasink -v
```
If it wouldn't crash it is a good sign, now it is ready to accept the data.

Now let's start test audio on any node within network where Onion is sitting. My Onion has ip 192.168.1.82 therefore this is the commend i run on my laptop
```
# this should produce the same sine tone, but this time it is generated on laptop and rendered on Onion
dronische@dronische-desktop:~$ gst-launch-1.0 -v audiotestsrc ! audioconvert ! audio/x-raw,format=S16LE,channels=2,rate=44100 ! udpsink host=192.168.1.82 auto-multicast=true port=5000
```
If you hear tone again than it works,

Now back to Omega. Below lines I add to /etc/rc.local
```
omega2-ctrl gpiomux set i2s i2s

gst-launch-1.0 udpsrc port=5000 buffer-size=102400 caps="audio/x-raw, rate=(int)44100, format=(string)S16LE, channels=(int)2, layout=(string)interleaved" ! audioconvert ! alsasink &

exit 0
```
Additinal property added here is buffer-size that makes streaming over wifi a bit smoother

And last configuration for mopidy should have this line on the audio output section
```
[audio]
    output="audioconvert ! audio/x-raw,format=S16LE,channels=2,rate=44100 ! audioconvert ! rtpL24pay ! udpsink host=192.168.1.82 auto-multicast=true port=5000"
```
Once again buffer is added. And also we need to convert audio to format that is accepted by Onion. Conversion is possible on the Omega side, but it takes half CPU time, therefore leave it for big machines

TODO:

- Instead of rc.local we should use service script in /etc/init.d

- I need to figure out how to feed 24 or 32 bit format, since PCM5102 happily supports it. It is not that I'm not happy with 16 bits (Audio CD quality), but it is a shame not to use DAC fully

- I need to stream audio via rtpL24pay and rtpL24depay converters,...
Read more »
Revision C PCB, Raspberry Pi case sized
andriy.malyshenko • 11/12/2020 at 15:05 • 0 comments

Small update, assebmled new revision of PCB (rev. C so far). This has few minor improvements and fixes, and most importantly, it is size compatible with Raspberry Pi case, which you can by anywhere for few bucks.
I did some audio tests and at this stage I don't have any issues with sound quality. Noises are at good (unhearable) level, audio lacking any hearable issues and weel compares with other PCBs I've made with the same DAC (and actually sonds better than same DAC sold as module in chinese stores)
Testing oled screen
andriy.malyshenko • 08/24/2020 at 19:37 • 0 comments

Today i finally booked myself to test oled screen.
Initially i soldered out headers for both SPI and I2C screens to test them both.
First discovery - I've soldered out SPI pins wrong, MISO and MOSI are switched places, but what is more important, with oled display connected to SPI bus it won't boot. Kind of a bummer.
According to docs GPIO7 and GPIO8 being SPI CLK and SPI MOSI must be left floating at boot, and clearly that's not the case with screen connected. Of course I'd be able to make it work with buffer IC between omega and screen, but since i was ready to have it only for free, I'm dropping SPI idea alltogether,
As for I2C screen - it works perfectly normal. Once again in the docs there is a great info how to jump start it and even nice command line tool is bundled in.
So there it is, i'm keeping I2C version of the screen for next revision and SPI has to go.
Revision B PCB came in and soldered
andriy.malyshenko • 08/06/2020 at 19:48 • 0 comments

Revision B just came and i had a chance to solder it and do a quick test.
Compared to a previous one, there are few key changes
- I completely changed power source part. rev A was planned to be used in combination with 2.5 inch HDD and therefore i estimated it to use at least 5W. For this one i decided to keep it simple and replaced it with simple AMS1117 linear reg for digital part, and LP2992 low noise linear reg for digital part.
- I made it smaller, to be more specific I tried to make it raspberry pi case compatible. This is yet to test since I'm still waitinf for case to be delivered.
- I moved all the parts to front side to simplify assembly and replaced barrel caps with pcb mounts for the same reason.
- I removed some unused pereferial, instead broke out SPI and I2C headers to plug in OLED screens. Just because why not, it is free:) Yet to test.
- Added 4 gpio leds, again why not.
In terms of software so far no change, all works same way as before. Key part is audio DAC, and it works like a charm. So far just an headphones audio test and i'm quite happy with the result, however more test to come.
As for OLED screen - placement could be better, and testing to do.
Overall, quite pleased with the result, no major flows, however probably one more revision to come to fix minor issues.

Setting up I2S sound output

andriy.malyshenko • 07/09/2020 at 22:16 • 0 comments

I pretty much followed the official tutorial.

Only pitfall is that you need to use firmware build before b195. I used b193 to be more specific. Full list of old builds can be found here, and instruction on how to flash custom firmware is here.

Issue with later versions is that at some point I2S was disabled in favor of PWM working on the same pins.

As soon as you have proper firmware installed you need to issue following commands

# install necessary packages
opkg update
opkg install alsa-utils mpg123
# enable I2S
omega2-ctrl gpiomux set i2s i2s

Verify that souncard is present

aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: AudioI2S [Audio-I2S], device 0: ralink-i2s-HiFi HiFi-0 []
  Subdevices: 1/1
  Subdevice #0: subdevice #0

Presense of this device doesn't imply that souncard is working, it will bang I2S pins even if they hang in the air. But to have the sound device listed is a good sign.

Next you test audio with any audio file or stream, I used my local stream here

mpg123 http://192.168.1.42:8000/fgHigh Performance MPEG 1.0/2.0/2.5 Audio Player for Layers 1, 2 and 3
	version 1.22.3; written and copyright by Michael Hipp and others
	free software (LGPL) without any warranty but with best wishes

Directory: http://192.168.1.42:8000/
Playing MPEG stream 1 of 1: fg ...
ICY-NAME: Fabio & Grooverider
ICY-URL: http://www.icecast.org/

MPEG 1.0 layer III, 128 kbit/s, 44100 Hz joint-stereo

ICY-META: StreamTitle='ÿþR - ÿþF';

Voila, we have a sound!

TODO:

- I want to build latest firmware version with I2S support enabled

- I found board hanging on wifi initialisation. I soldered 100uF cap to power pins directly and the issue went away. Now i need to adjust PCB design to have decoupling caps closer to Onion board.

- Today found an article on separating digital and analog grounds, need to try that as well:)

Soldering in pcm5102 and basic testing
andriy.malyshenko • 07/08/2020 at 20:16 • 0 comments

Soldered in pcm5102, testing it with external i2s source for now, just to verify setup and soldering. Started to work after 2nd attempt. Comparing to known working module (yellow one)

(Sorry for picture quality, i only posses DS0138 toy oscilloscope)
10khz on yellow module (known good)
10khz on my pcb

20khz on yellow module (known good)

20khz on my pcb

Looks very similar, relatively clean (oscilloscope is strugling here, actual waveform is really clean).
Next on setting up Onion and I2S.