Still quite a new board but just run some benchmarks as a metric if you are interested.
The 512MB with BT/Wifi is the one to go for IMHO as for $13.99 its hard to beat.
I have some mics to come and setup to do to test the embedded codec but this post is purely benchmarks.
I did some benchmarks running @ 1296000 and seems stable and doesn’t throttle. The original board comes with a conservative 1Ghz but from Rockchip and generally there claims are pretty on the mark 1.3Ghz should be no problem. I am going to stick a cheap thermal heatsink on it also, but seems fine without but my tests are relatively short.
But also if you download this one it has the benchtexts from the last RockPiS in it so you can compare before you run.
RockPiS trades very well with a Pi3B+
Benches are what they are but it gives you a metric to the RockPiS and they are included in the google drive tar which is just the raylongbottom download with each test run and corresponding txt output file of the bench.
@ 1.3Ghz its a bit faster in some than the Pi3B+ and @ 1Ghz its a bit slower in many than a Pi3B+, but its hovering around Pi3B+ costs ZeroW price and also has an internal audio codec and dsp VAD that on a single mic will wake from sleep.
If my next audio tests work and rhasspy setup then its prob the best low cost satelite SoC available, we shall have to see, but for the moment some benches that you can copare with your current Pi.
I will continue the review when the mics I have chosen turn up and give it a Rhasspy install on Debian64 that is the main image.
2x those which was a bit of a mistake as was supposed to be x4 and now have x4 I2S mics that should of had x2
There is little info apart from the Rockchip RK3308 tech document but those will be connected as single ended to the ADC via a DC blocking cap.
To be honest it doesn’t matter but did want x4 as the embedded VAD DSP can do x4. I also have some cheap electret microphones.
With yet another that has selectable hardware gain and ALC.
I have another project with a USB stereo mic soundcard.
I like the Respeaker 2mic but the drivers I really hate as they are pretty awful and likely to cause problems.
Enermax do a very cheap sound card with a ridiculously good VIA VT1620A chip on it that I want to try with the same mics as another project.
I received my Raspberry Pi Zero and my Respeaker 2mics hat and can confirm that the device CPU is pretty overwhelmed by an audio server + snowboy detection + snapcast client rendering the device unusable as a working satellite for me.
I don’t think running software AEC on top of this can work out at all.
I’ll be looking at alternatives (RPi3? RockPiS)…
If music playback is not required (no snapcast client and no AEC), it works though (the Pi0 CPU seems just enough).
It won’t AEC alone as a single process as it has a go but results are awful, then again I am surprised you got that load working on a zero.
I doubt Mycroft Precise would run well with that setup from the Pi3A+ loads I have seen.
There Picroft runs with ease on a Pi4 and the load on a Pi3 is considerable but the bonus about the EC speex AEC tested is that it auto bypasses when not playing media so yeah with a full Mycroft system then Pi3A+ and software AEC is possible but likely the datum for current minimum.
Pi3A+ is $25 and its cpu not ram that matters so it very much fits the bill.
Only problem are the drivers of the 2mic which I feel are as flakey as hell.
I am testing
card 1: Dongle [VIA USB Dongle], device 0: USB Audio [USB Audio]
Subdevices: 1/1
Subdevice #0: subdevice #0
Its quite decent with stereo ADC so 2 mic also and runs without driver. I don’t have problems with drivers but ones that are so flakey they only run on a single kernel and fallover with many other applications I do.
Typically the mic ports and the only available Mic I have is a coin battery powered one and the plug casing is too large and stops me fitting the headphone plug.
So will have to wait until Monday.
The RockPiS is looking very much like a zero on steroids with built in codec but have a load of testing to do on that.
If anyone fancies burning a trial with me on the RockPiS please do but if there are hurdles its still very new.
I know it works but how much Radxa has got right RockChip are actually very good when it comes to the kernel and opensource.
Radxa make quite good SBCs as a company a bit like Pine no where near the resources of raspberry but actually quite good.
From what I have seen playing media via AI is a common requirement by many from “play the news” to “play the radio” is a common request hence for $13.99 the RockPiS with 512gb, Wifi and built in codec and DSP 4 channel VAD and 1 channel wake from sleep VAD is probably the best fit SoC available by far.
If it works without major glitches which I think there is a fair chance then its a pi3A+ performing with built in sound card for $10 less.
I am starting to garner a small stock of satellite components and single clock playback and capture soundcards has been my biggest problem.
Hardware with Respeaker is good but there drivers are weak and why Respeaker USB models are a much better choice if the cost isn’t a problem.
Matrix voice is another option but for me they are too expensive for a satelite.
TPA3116 40watt+ amps from $5 - $25 all seem realtively good and a cone that can handle it is $10-$20 and I have a few of each now that I will review.
Its when you have built one of these and heard how good they can sound that without AEC its so disheartening that your AI will then do something so stupid as be unable to stop unless at close proximity you shout Stop! into the mic.
Its actually a bonus to be playing the media on the satelite as then you have the echo channel to filter from your mic stream.
Software AEC is high load but its much cheaper than hardware alternatives that start at aprox 2x the cost of a Pi4.
There is a SoC that should cost about the same as a RK3308 and even included hardware AEC.
The Allwinner R328 but as far as I know its only sale is in budget AI such as the < $20
But just as AI accelerators are being embedded, also DSP and they are becoming cheaper and more common.
The Allwinner R329 is one that combines both but availability is the same.
Currently with an RK3318, TPA3116, Mics, 30w Cone you can make an extremely good satellite mic/speaker/AI that audio wise kicks the butt of Amazon & Googles more expensive approx $80 models.
Its a pretty damn good WiFi speaker that as a pair with snapcast has huge appeal as an effective AI appliance, stereo speakers 40+40watt, wide array microphone system with AEC, that is my choice is to link to a Master such as a Pi4 or above that may serve several rooms of multiple satellites.
Running the same setup (Audio server + Snowboy + snapcast client + EC) on a Pi3B+ works pretty good and only uses half the Pi3B+ CPU power at peak.
The capture performance of the Respeaker 2 mics Pi Hat are weaker than its more expensive counterpart the Respeaker Mic Array V2.
The far field capture is very limited (maybe I need to improve the input gain or something using Sox… I’ll explore that tomorrow). It works pretty well if you speak no more than 3 meters away and directly to it. Whereas the Respeaker Mic Array capture from more than 5 meters even if you look in the opposite direction.
But it’s 7-8x times the cost so for a small room (i’d say like 12 squared meters) the 10€ hat might just be enough… dépends also of the enclosure of course (I did not use one for the tests).
The driver installs pretty easily now that the kernel downgrade is not required anymore and I did not have any issue with it until now…
One issue is that to control the leds you need to run the program as root in order to access the SPI interface…
I’ll try with Speex and SpeexDSP via ALSA soon to see if this improves performance over the EC software since they use the same libs.
I am still trying to work out why the alsa-plugin Speex-echo produces the bad results it does.
The default gain of the driver isn’t good it has output at 90% or something and capture gain very low.
alsamixer F5 to view all controls so capture is included and eventually you will find the capture input.
I actually set mine at about 80% as felt much higher induced to much noise, but remember the default playback and capture values of the card are pretty whack and you need to set them.
Then aslactl store
The speex plugins are a faff on raspbian as they are a version lower than alsa-plugins requires so on the official compile of alsa-plugins it skips the speex-dsp plugins.
Compile speexdsp first as speex looks for speexdsp and not the other way round.
wget http://downloads.us.xiph.org/releases/speex/speexdsp-1.2.0.tar.gz
tar -xzvf speexdsp-1.2.0.tar.gz
cd speexdsp-1.2.0
./configure --enable-neon --libdir=/usr/lib/arm-linux-gnueabihf
make
sudo make install
Before you make you might want to set the compile flags for SoC optimisation but you can just hit return as the default is good.
The above if you want to try tuning.
cd ..
wget http://downloads.us.xiph.org/releases/speex/speex-1.2.0.tar.gz
tar -xzvf speex-1.2.0.tar.gz
cd tar -xzvf speex-1.2.0
./configure --libdir=/usr/lib/arm-linux-gnueabihf
make
sudo make install
Current alsa is 1.1.8 but aplay --version will say.
cd ..
wget ftp://ftp.alsa-project.org/pub/plugins/alsa-plugins-1.1.8.tar.bz2
tar -xjvf alsa-plugins-1.1.8.tar.bz2
cd alsa-plugins-1.1.8
./configure --libdir=/usr/lib/arm-linux-gnueabihf
make
sudo make install
The you can make the expletives of holy hell what have alsa-project.org done to the echo plugin.
There is one speex-dsp plugin that makes a world of difference as the hardware ALC doesn’t work or didn’t seem to.
Respeaker usb has hardware ALC and much isn’t semsitivity but just automatic gain.
Its actually really hard to get any info on alsa-plugin settings but the file 60-speex.conf and the manuals for speex can help
pcm.speex {
@args [ SLAVE AGC AGC_LEVEL DENOISE ECHO
DEREVERB DEREVERB_DECAY DEREVERB_LEVEL
FRAMES FILTER_LENGTH ]
@args.SLAVE {
type string
default "plug:hw"
}
@args.AGC {
type string
default off
}
@args.AGC_LEVEL {
type integer
default 8000
}
@args.DENOISE {
type string
default on
}
@args.ECHO {
type string
default off
}
@args.DEREVERB {
type string
default off
}
@args.DEREVERB_DECAY {
type real
default 0
}
@args.DEREVERB_LEVEL {
type real
default 0
}
@args.FRAMES {
type integer
default 64
}
@args.FILTER_LENGTH {
type integer
default 256
}
type speex
agc $AGC
agc_level $AGC_LEVEL
denoise $DENOISE
echo $ECHO
dereverb $DEREVERB
dereverb_decay $DEREVERB_DECAY
dereverb_level $DEREVERB_LEVEL
frames $FRAMES
filter_length $FILTER_LENGTH
slave.pcm $SLAVE
hint {
show {
@func refer
name defaults.namehint.basic
}
description "Plugin using Speex DSP (resample, agc, denoise, echo, dereverb)"
}
}
The defaults you seem to have to find from the code
struct SpeexPreprocessState_ {
/* Basic info */
int frame_size; /**< Number of samples processed each time */
int ps_size; /**< Number of points in the power spectrum */
int sampling_rate; /**< Sampling rate of the input/output */
int nbands;
FilterBank *bank;
/* Parameters */
int denoise_enabled;
int vad_enabled;
int dereverb_enabled;
spx_word16_t reverb_decay;
spx_word16_t reverb_level;
spx_word16_t speech_prob_start;
spx_word16_t speech_prob_continue;
int noise_suppress;
int echo_suppress;
int echo_suppress_active;
SpeexEchoState *echo_state;
Needs someone with more C experience than me but actually there is some pretty cool stuff not exposed through the plugin.
Also if someone does maybe have a look at compiling with an alternative FFT lib such as fft3w.
So I will leave you to play with AGC and see the worl of difference that makes to sensitivity but the default value seems ok.
The denoise and reverb I always meant to return to and see if the values can be tweaked.
The VAD of speex is strangely only in the codec?!
Agc should be as easy as, but will let you give it a try.
pcm.agc {
type speex
slave.pcm "capture"
agc 1
agc_level 8000
denoise no
dereverb no
}
