What makes it worth it for me, is that I would probably want something that's on the edge of easily feasible with a full PC anyway, and a Pi is cheap and easily put in a drawer for six months if now is not the time. There are always alternative suggestions, board X is much better, or board Y, but when you look into it there are always other drawbacks. My factory stock AVreceiver and factory stock integrated amplifier with CD player and turntable are my reliable music machines, so the Pi allows me to try stuff out without major concern to reliability, ultra-perfection etc. The fact that I have had configurations that were as good or better as the major brand products for a specific goal was a lot of fun.
Hi there.
Tz been a while.
The PI foundation folks are still making great progress on the PI4.
BTW. I meanwhile installed a Raspbian.
Arch Linux Arm currently is simply not able to follow all the RPi foundation PI4 related developments.
Let's see what I consider worthwhile developments
* The eeprom update process is now a part of Raspbian environment
* They fixed a reboot issue which impacted the 3.3V line and therefore certain HAT DACs
* They now renamed a bunch of overlays it's now e.g. "disable_bt".
Unfortunately the documentation around that is quite sparse. Best is to read the
/boot/overlays/README
* LEDs on motherboard AND ethernet-jack can now be turned off
* Raspbian now supplies a 64bit foundation kernel. Just run "rpi-update" to install bleeding edge kernels and then you add "arm_64bit=1" to your /boot/config.txt
They also work hard on real-USB-boot. From what I see it seems they come up with something in December.
I did encounter one to me very annoying PI4 related issue.
My Audiohonics iSabre 9038Q2M HAT simply doesn't work on the PI4. To be exact I2C controls fail. No SW volume control, no filters can be changed.
I've been told that newer models (production >mid of 2019) are supposed to work. Great.
Katana, Boss etc. work fine.
I also opened a RPi4 PowerSavings thread over at Raspi forums. Some of you might be interested. I outline some of the changed parameters in that thread.
Looking at the developments. I think the dust is going to reasonably settle by the end of this year.
What's IMO still missing is a Raspbian 64bit userspace. I'd love to see that one popping up sooner or later.
I'll keep you posted.
Enjoy.
Tz been a while.
The PI foundation folks are still making great progress on the PI4.
BTW. I meanwhile installed a Raspbian.
Arch Linux Arm currently is simply not able to follow all the RPi foundation PI4 related developments.
Let's see what I consider worthwhile developments
* The eeprom update process is now a part of Raspbian environment
* They fixed a reboot issue which impacted the 3.3V line and therefore certain HAT DACs
* They now renamed a bunch of overlays it's now e.g. "disable_bt".
Unfortunately the documentation around that is quite sparse. Best is to read the
/boot/overlays/README
* LEDs on motherboard AND ethernet-jack can now be turned off
* Raspbian now supplies a 64bit foundation kernel. Just run "rpi-update" to install bleeding edge kernels and then you add "arm_64bit=1" to your /boot/config.txt
They also work hard on real-USB-boot. From what I see it seems they come up with something in December.
I did encounter one to me very annoying PI4 related issue.
My Audiohonics iSabre 9038Q2M HAT simply doesn't work on the PI4. To be exact I2C controls fail. No SW volume control, no filters can be changed.
I've been told that newer models (production >mid of 2019) are supposed to work. Great.
Katana, Boss etc. work fine.
I also opened a RPi4 PowerSavings thread over at Raspi forums. Some of you might be interested. I outline some of the changed parameters in that thread.
Looking at the developments. I think the dust is going to reasonably settle by the end of this year.
What's IMO still missing is a Raspbian 64bit userspace. I'd love to see that one popping up sooner or later.
I'll keep you posted.
Enjoy.
Hi.
Tz been a while.
Updates on the RPi4 are still popping in. Just recently a new USB firmware was launched.
So. Make sure you keep updating your eeprom firmware!
I meanwhile bought a passive cooling case for my PI4. That stabilized the temperature situation. You really need to keep an eye on that.
If you e.g. run HATs and have low ventilation in the area or your room temperature rises
it might make things tricky.
Now, with my USB DAC attached, it's of course a little easier to get the cooling accomplished.
A new project from my side:
I am now in the process to setup a RPi4 as server. I'll give it a try. Let's see how it performs.
I'll hook up a SSD and use my 64-bit Arch Linux (64-bit foundation kernel and userland!) as base.
It won't beat a NUC, but perhaps it's sufficient to have it running as a basic server without running challenging DSP task.
For this I planned to use ethernet @Gbit speed.
Guess what? I immediately ran into an issue on that. Just figured it out.
There can be serious packet loss on eth0 if u run GBit on a RPi4.
It's been discussed and recognized all over the place. Some people nailed it to a specific router.
The RPI development team (on github) simply ignored the fact that the issue only happens with the RPi4 AND that router.
Most other clients and PCs (Intel) did not show this packet loss behavior on that router. The issue got closed anyhow.
That's not cool. Ignorance seems to creep in into the foundation. That's usually not a good sign.
I once more strongly recommend, since you run all your RPis as network clients,
do yourself a favor and check your network performance - Wifi and ethernet - once in a while.
You can simply run iperf3 and see if there's packet loss. If you'd run UDP tests with iperf3 it'd show even more clearly what you're up to.
You should do it e.g. after relocation, SW/firmware updates, cable swap/disconnect or introducing (different) cases.
Enjoy.
Tz been a while.
Updates on the RPi4 are still popping in. Just recently a new USB firmware was launched.
So. Make sure you keep updating your eeprom firmware!
I meanwhile bought a passive cooling case for my PI4. That stabilized the temperature situation. You really need to keep an eye on that.
If you e.g. run HATs and have low ventilation in the area or your room temperature rises
it might make things tricky.
Now, with my USB DAC attached, it's of course a little easier to get the cooling accomplished.
A new project from my side:
I am now in the process to setup a RPi4 as server. I'll give it a try. Let's see how it performs.
I'll hook up a SSD and use my 64-bit Arch Linux (64-bit foundation kernel and userland!) as base.
It won't beat a NUC, but perhaps it's sufficient to have it running as a basic server without running challenging DSP task.
For this I planned to use ethernet @Gbit speed.
Guess what? I immediately ran into an issue on that. Just figured it out.
There can be serious packet loss on eth0 if u run GBit on a RPi4.
It's been discussed and recognized all over the place. Some people nailed it to a specific router.
The RPI development team (on github) simply ignored the fact that the issue only happens with the RPi4 AND that router.
Most other clients and PCs (Intel) did not show this packet loss behavior on that router. The issue got closed anyhow.
That's not cool. Ignorance seems to creep in into the foundation. That's usually not a good sign.
I once more strongly recommend, since you run all your RPis as network clients,
do yourself a favor and check your network performance - Wifi and ethernet - once in a while.
You can simply run iperf3 and see if there's packet loss. If you'd run UDP tests with iperf3 it'd show even more clearly what you're up to.
You should do it e.g. after relocation, SW/firmware updates, cable swap/disconnect or introducing (different) cases.
Enjoy.
Last edited:
Advise:
For those who run a RPi4 on a wired network and on a problematic router,
below will be your ticket - for the time being - to avoid any loss of data,
especially if UDP is involved (e.g. LMS/squeezelite):
We simply limit the interface to 100MBit/s.
If I find a better solution I'll let u know. If anybody else sees a better one let me know.
Enjoy.
For those who run a RPi4 on a wired network and on a problematic router,
below will be your ticket - for the time being - to avoid any loss of data,
especially if UDP is involved (e.g. LMS/squeezelite):
Code:
ethtool -s eth0 speed 100 duplex fullWe simply limit the interface to 100MBit/s.
If I find a better solution I'll let u know. If anybody else sees a better one let me know.
Enjoy.
Hi.
Still working on the ethernet GBIT issue.
I yesterday figured when throttling eth0 to 100MBit, every couple of seconds the IF - according to dmesg - restarts. That's not good.
I now tried an external USB3-GBIT adapter which comes with a Realtek chip inside.
The errorfree (no lost datagrams) UDP bandwidth doubled form 200Mbit to 400Mbit.
That's interesting, still not OK - IMO. However. While being logged in via ssh and the
external network adapter at least these annoying micro-stalls while entering data vanished.
I also swapped ports on the router and swapped cables. No change.
One last thing would be to swap the router. Or the PI?
But again. My NUC works fine. It's got to be a problem with the RPi.
Any RPi4 owner reading this and feeling motivated, could do me a favor.
Could you run iperf3 on a wired RPi4 with latest Rasbian Buster.
Just to see if anybody out there faces a similar issue.
I'm running the latest 64-bit kernel 4.19.97-v8+ (the 32-bit kernel makes no difference)
Do the following, after ssh login:
#install iperf3
#on the RPi4 run
#on a linux server run
You need to insert your RPi4 IP address in above command.
To give you a benchmark, below my result:
If any of you have any other ideas - let me know.
Still working on the ethernet GBIT issue.
I yesterday figured when throttling eth0 to 100MBit, every couple of seconds the IF - according to dmesg - restarts. That's not good.
I now tried an external USB3-GBIT adapter which comes with a Realtek chip inside.
The errorfree (no lost datagrams) UDP bandwidth doubled form 200Mbit to 400Mbit.
That's interesting, still not OK - IMO. However. While being logged in via ssh and the
external network adapter at least these annoying micro-stalls while entering data vanished.
I also swapped ports on the router and swapped cables. No change.
One last thing would be to swap the router. Or the PI?
But again. My NUC works fine. It's got to be a problem with the RPi.
Any RPi4 owner reading this and feeling motivated, could do me a favor.
Could you run iperf3 on a wired RPi4 with latest Rasbian Buster.
Just to see if anybody out there faces a similar issue.
I'm running the latest 64-bit kernel 4.19.97-v8+ (the 32-bit kernel makes no difference)
Do the following, after ssh login:
#install iperf3
Code:
sudo su
apt-get install iperf3#on the RPi4 run
Code:
iperf3 -s -V#on a linux server run
Code:
iperf3 -c 192.xxx.x.xx -V -i 1 -A 1 -b 0 -u -t 60You need to insert your RPi4 IP address in above command.
To give you a benchmark, below my result:
Code:
Test Complete. Summary Results:
[ ID] Interval Transfer Bitrate Jitter Lost/Total Datagrams
[ 5] 0.00-60.00 sec 6.62 GBytes 948 Mbits/sec 0.000 ms 0/4908290 (0%) sender
[ 5] 0.00-60.00 sec 3.43 GBytes 491 Mbits/sec 0.012 ms 2362789/4908290 (48%) receiver
CPU Utilization: local/sender 47.2% (8.3%u/38.9%s), remote/receiver 83.0% (7.2%u/75.9%s)If any of you have any other ideas - let me know.
Interesting developments!
Just out of curiosity, I simply set the affinity - assigning a certain CPU - on the RPi4 based iperf3 side:
I then ran earlier UDP test.
Guess what?
Wow. What a change. That looks pretty good.
And above listing shows the internal RPi NIC already! My external USB3-NIC shows the same performance.
I then checked which CPU is causing the jam. It quickly turned out to be CPU0.
Then I added "isolcpus=0" to cmdline.txt, to make the workaround permanent.
And here we go. All working rather well.
That's what I call a nice workaround.
Now the actual Q remains. What's causing the jam??
IRQs?
Just out of curiosity, I simply set the affinity - assigning a certain CPU - on the RPi4 based iperf3 side:
Code:
iperf3 -s -V -A 2I then ran earlier UDP test.
Guess what?
Code:
Test Complete. Summary Results:
[ ID] Interval Transfer Bitrate Jitter Lost/Total Datagrams
[ 5] 0.00-60.00 sec 6.63 GBytes 949 Mbits/sec 0.000 ms 0/4914870 (0%) sender
[ 5] 0.00-60.00 sec 6.62 GBytes 948 Mbits/sec 0.013 ms 2409/4914870 (0.049%) receiver
CPU Utilization: local/sender 50.8% (8.6%u/42.2%s), remote/receiver 80.5% (16.9%u/63.6%s)Wow. What a change. That looks pretty good.
And above listing shows the internal RPi NIC already! My external USB3-NIC shows the same performance.
I then checked which CPU is causing the jam. It quickly turned out to be CPU0.
Then I added "isolcpus=0" to cmdline.txt, to make the workaround permanent.
And here we go. All working rather well.
That's what I call a nice workaround.
Now the actual Q remains. What's causing the jam??
IRQs?
Code:
cat /proc/interrupts
CPU0 CPU1 CPU2 CPU3
3: 6451 6610 13246 33767 GICv2 30 Level arch_timer
6: 0 0 0 0 GICv2 112 Level bcm2708_fb DMA
16: 684 0 0 0 GICv2 65 Level fe00b880.mailbox
20: 0 0 0 0 GICv2 169 Level brcmstb_thermal
21: 9800 0 0 0 GICv2 158 Level mmc0
22: 0 0 0 0 GICv2 48 Level arm-pmu
23: 0 0 0 0 GICv2 49 Level arm-pmu
24: 0 0 0 0 GICv2 50 Level arm-pmu
25: 0 0 0 0 GICv2 51 Level arm-pmu
[B] 27: 10235986 0 0 0 GICv2 189 Level eth0
[/B] 28: 322 0 0 0 GICv2 190 Level eth0
34: 12 0 0 0 GICv2 66 Level VCHIQ doorbell
36: 100918 0 0 0 Brcm_MSI 524288 Edge xhci_hcd
IPI0: 1041 181193 715141 1253161 Rescheduling interrupts
IPI1: 44 712 1449 51198 Function call interrupts
IPI2: 0 0 0 0 CPU stop interrupts
IPI3: 0 0 0 0 CPU stop (for crash dump) interrupts
IPI4: 0 0 0 0 Timer broadcast interrupts
IPI5: 17 883 367 1653 IRQ work interrupts
IPI6: 0 0 0 0 CPU wake-up interrupts
Err: 0
Last edited:
Sorry folks.
One more.
As you can see in earlier performance report there are still some lost datagrams.
These occur at the very beginning of the measurement!
I now figured these are related to the CPU governor.
I have "ondemand" running as default governor.
That one drags the CPU frequency down to 600MHz during idle operation. And speeds up to 1500MHz if needed.
That acceleration process takes a while! And the switching also causes some extra load.
Now comes the solution to that one:
Changing to the "performance" governor, which runs continuously at 1500MHz did the trick.
No more lost datagrams.
One more.
As you can see in earlier performance report there are still some lost datagrams.
These occur at the very beginning of the measurement!
I now figured these are related to the CPU governor.
I have "ondemand" running as default governor.
That one drags the CPU frequency down to 600MHz during idle operation. And speeds up to 1500MHz if needed.
That acceleration process takes a while! And the switching also causes some extra load.
Now comes the solution to that one:
Changing to the "performance" governor, which runs continuously at 1500MHz did the trick.
No more lost datagrams.
Simply the single core is not up to handling all the flood of interrupts generated by the ethernet card - skips - xruns happen just like they would in audio.
Is there any way to increase the "period" of the ethernet device, to lower the IRQ rate? I guess looking at the driver source code would tell what configs (if any) are available.
Is there any way to increase the "period" of the ethernet device, to lower the IRQ rate? I guess looking at the driver source code would tell what configs (if any) are available.
Yes. You're right. It's about inefficiency.
You can play around with the receive and other buffers.
And yes, there are ways to play around with Interrupt coalescing.
However. I do think e.g. the new way of handling interrupts (hard and soft) on the RPi4 is not mature yet. They changed a lot in that area on the PI4.
Before starting the fine-tuning I'd like to get the big blocks out of the way.
I btw also opened a thread over at RPI forums now.
If that won't get me any further I'll open a github TT.
Maybe i get a answer here about RPi and bit/sample rate.
If i google around it seems like the RPi's can only do 24-bit/192kHz.
So i did ask here about the Pi4:
Which SBCs support which bitrate/samplerate? : DACs - Volumio
RPi 4 audio bit rate and sample rate - Raspberry Pi Forums
Now at raspberrypi.org somebody says:
All RPis support up to 384kHz stereo at 32bits resolution via I2S
I'm confused.
If i google around it seems like the RPi's can only do 24-bit/192kHz.
So i did ask here about the Pi4:
Which SBCs support which bitrate/samplerate? : DACs - Volumio
RPi 4 audio bit rate and sample rate - Raspberry Pi Forums
Now at raspberrypi.org somebody says:
All RPis support up to 384kHz stereo at 32bits resolution via I2S
I'm confused.
I think from PI 2 onwards 384k was possible from a HW perspective.
But. To make absolute sure that everything worked fine
the drivers were limited to 192k by the manufacturers
in the early days.
I think Hifiberry came up with the first driver.
And that had the 192k limit. Some drivers still have it.
And that's the confusing part here.
You basically need to analyze the situation for every single DAC.
But. To make absolute sure that everything worked fine
the drivers were limited to 192k by the manufacturers
in the early days.
I think Hifiberry came up with the first driver.
And that had the 192k limit. Some drivers still have it.
And that's the confusing part here.
You basically need to analyze the situation for every single DAC.
I bought a Odroid C1+ just to find out there is only old stuff (kernel, releases, software).
Now somebody shows at raspberrypi.org that the JustBoom DAC does 32/384
All I'm looking for is a I2S DAC (Stereo Cinch) that does
44.1k/48k/88.2k/96k/176.4k/192k/352.8k/384k @ 16/24/32bit
DSD64/DSD128/DSD256
without up/down sampling.
Now somebody shows at raspberrypi.org that the JustBoom DAC does 32/384
All I'm looking for is a I2S DAC (Stereo Cinch) that does
44.1k/48k/88.2k/96k/176.4k/192k/352.8k/384k @ 16/24/32bit
DSD64/DSD128/DSD256
without up/down sampling.
Absolutely. There's nothing to be sorry about.
However. After explaining to you the RPi4 I2S capabilities,
you switched topics and asked for a DAC:
Simply make use of "search", because numerous (HAT-) DACs with all their features have been discussed over the years.
Or if you prefer the lazy-mans approach, simply open a new thread in the "digital-line-level" section and ask your question over there.
Today I did a quick benchmark.
@1500MHz I redid my sox resampling benchmarking exercise on the RPi4.
a flac 44.1 >> 352k8
In comparison the same task on my Broadwell NUC
"real" is the elapsed time.
It's still half the size on the NUC. And the performance from 3B to 4B has
not changed much. Around 10%.
DSP is still the achilles heel in the RPi universe.
Running an RPi4 as a media server has still its limitations.
Enjoy.
@1500MHz I redid my sox resampling benchmarking exercise on the RPi4.
a flac 44.1 >> 352k8
Code:
**************************************************************
*** audio file length >> 00:06:28.93
*** binary >> /tmp/sox
*** SRC options >> rate -v -b 95.0 -p 50 -a 352800
*** dither options >> dither -S
real 0m28.171s
user 0m39.928s
sys 0m0.992s
**************************************************************In comparison the same task on my Broadwell NUC
Code:
**************************************************************
*** audio file length >> 00:06:28.93
*** binary >> /tmp/sox
*** SRC options >> rate -v -b 95.0 -p 50 -a 352800
*** dither options >> dither -S
real 0m14,815s
user 0m41,807s
sys 0m0,387s
**************************************************************"real" is the elapsed time.
It's still half the size on the NUC. And the performance from 3B to 4B has
not changed much. Around 10%.
DSP is still the achilles heel in the RPi universe.
Running an RPi4 as a media server has still its limitations.
Enjoy.
Last edited:
Yep. A reasonable value for a RPi. There were times when such a HQ upsampling
wasn't possible at all in realtime.
And, yep , it would probably look even better if the ARM specific optimizations would be used.
Perhaps using ffmpeg (with libsoxr enabled) does a better job. Usually they use the GPU
for processing and on top ffmpeg also comes with a much better multi-threading engine.
Ah. I forgot: the sox binary was compiled with "-mcpu=native", whereas I was using the
standard binary on the NUC.
wasn't possible at all in realtime.
And, yep , it would probably look even better if the ARM specific optimizations would be used.
Perhaps using ffmpeg (with libsoxr enabled) does a better job. Usually they use the GPU
for processing and on top ffmpeg also comes with a much better multi-threading engine.
Ah. I forgot: the sox binary was compiled with "-mcpu=native", whereas I was using the
standard binary on the NUC.
Last edited:
The Raspberry PI 4 Version 1.2 is ""on its way"".
* the USB-C Power layout issue has been resolved
* they relocated a SD power-switch
* and then they did some silk screen adjustments due do problems in the production.
One the first glance, I'd say, no major changes or enhancements.
To clearly identify the new board via SW, you can run below command:
You should get this:
The initial version is c03111.
As usual official RPi Foundation issued information is scarse. You hardly see any official announcements, roadmaps or release plans.
You never really know if old stuff still gets sold to you. That's a bit annoying.
Enjoy.
* the USB-C Power layout issue has been resolved
* they relocated a SD power-switch
* and then they did some silk screen adjustments due do problems in the production.
One the first glance, I'd say, no major changes or enhancements.
To clearly identify the new board via SW, you can run below command:
Code:
# cat /proc/cpuinfo | grep RevisionYou should get this:
Code:
Revision : c03112The initial version is c03111.
As usual official RPi Foundation issued information is scarse. You hardly see any official announcements, roadmaps or release plans.
You never really know if old stuff still gets sold to you. That's a bit annoying.
Enjoy.
- Status
- This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.