Archives July 2022

Maybe a bit off topic…but maybe some interest anyway. A client have a outdoor gig and without any supply of external power…and asked if I was able to fulfill such request. And with a Behringer Flow 8, a power bank of 40000mA, 2x Mackie Freeplay 150W speakers…I think I can say yes! 🙂

Of course, I also had to test if I was able to record 8 channels from the Flow 8 using my Raspberry PI multitrack recorder – www.z-liverec.com using the same power bank…and the answer was yes even here – but the solution consumes power. The battery will probably last for 1-1.5 hours) 🙂

But Z-LiveRec recorded 8 channels without any problems – you are even able to record the bluetooth stream (channel 9-10) at the same time. Note that the Flow 8 only have 4 USB return channels – so it is not possible to playback channels to make a virtual soundcheck etc.

But a pretty neat small environment!

The background for this post was that some Z-LiveRec users experienced problems with USB Sticks formatted in exFAT format and using the resources demanding W64 file format. The idea with using exFAT is the ability to utilize larger storage medias without any limits in file size – compared FAT32 which limit single files to 4GB. W64 is a wav format which is using 64 bits file structure…and supports unlimited file sizes – compared to wav which has a limit on 2GB.

By using W64 on exFAT…Z-LiveRec is able to store multitrack files which easily can be like 22GB for a 1.5h recordings with 48 channels. But it is here some users have started to see problems – a lot of buffer overruns was reported in Z-LiveRec. If selecting less channels – the problem disappears. Note: there is also another unlimited format available in Z-LiveRec called “CAF” (Apples multitrack format) which have the same characteristics as W64 – which seems to run more smooth and is nicer in performance for a Raspberry PI – so one solution is to use this format instead.

But why do W64 report a lot of buffer overruns in exfat? I had to investigate this more in detail – especially if using FAT32 instead – no problem was reported. 🙂

Equipment used:

• Raspberry PI 4B with 2GB RAM.
• Sandisk Ultrafit 64GB, USB 3.1 Stick. (130MB/s for reading and 55 MB/s writing)
• Sandisk Extreme Go 64GB USB 3.2 stick (395 MB read/s and a write speed of 100 MB/s)
• Samsung TEAM SX2 – 120GB SSD drive.
• Behringer XR18
• Raspberry PI OS “10” BUSTER 32 Bit.
• Raspberry PI OS ”11” BULLSEYE 32 bit

First check the version of the Raspberry PI OS used:

cat /etc/os-versions

Ok – in theory – can a storage device be measured by Raspberry PI? Yes by moving to the drive you want to measure:

cd /media/pi/$HARD_DRIVE_LABEL

and then execute the following code:

dd if=/dev/zero of=test.bin bs=10M count=100

and the system will show: (Takes a little while)

100+0 records in
100+0 records out
1048576000 bytes (1.0 GB, 1000 MiB) copied, 755.422 s, 1.4 MB/s

The system will show the write speed – e.g. 1.4MB in this case! (Too Slow!)

Ok, using this info and apply it to our storage devices used will give us the following data:

Ok, when used these storage types in Z-LiveRec with w64 format!

Conclusion

ExFAT seems to have performance problems in Buster…but works great in Bullseye! It seems like a faster USB stick makes great improvements to the write speed. Another recommendation is to use Sandisk Extreme Go USB 3.2 Flash drives with 64GB – which has a read speed of 395 MB read/s and a write speed of 100 MB/s. Compared to the Sandisk Ultra Slim Fit – which has a read speed on 150MB/S and a write speed on 55MB/S – the Extreme GO USB stick can improve the situation with experienced buffer overruns a lot! (e.g Zero overruns!)