Highlighted
Contributor - Level 2

18-track Recorder + Remote Jukebox + Solo/Talkback Streaming

It all works, and I'm pretty sure the documentation is right, so I guess it's time to post it.

This system consists of:
o 3-outlet power strip (minimum)
o XR18 (the one with 18-track USB instead of a built-in player/recorder)
o Banana Pi Pro
o SATA SSD for recording
o UCA202 USB<->analog line-level for streaming
o Custom Battery Backup for Banana Pi
o External router for a real network
o Touchscreen laptop for Front-of-House, running Lubuntu Linux

Initial setup:
o Mount the power strip, router, Pi, UCA202, battery backup components, and XR18 together, preferably in a mobile rack box.[INDENT]o All of these parts can be somewhat small, so depending on the exact arrangement, it might actually end up requiring no extra real estate on the face of the rack.[/INDENT]
o Run two short Cat5 cables from the router to the XR18 and to the Pi.
o Run a USB cord from the Pi to the XR18.
o Run two RCA<->1/4" adapter cables from the UCA202 to the XR18:[INDENT]o UCA202 Line-out to XR18 channel in
o XR18 Headphone out to UCA202 Line-in[/INDENT]
o Configure the router as desired for this dedicated network, preferably with a viable internet connection.
o Follow the Commands.txt files (linked at the bottom of this post) to set up the software. (these need internet access)

To use, simply give it power.
The Pi and the router will start up and provide their functions automatically.

To stop using, just unplug the power strip and pack it up.
The router will turn off immediately (no more network). The Pi will see that, wait for the router to reboot, and shutdown automatically if it doesn't. Once the Pi is finished shutting down, the battery backup disconnects itself to avoid further discharge.

Basic Maintenance:
o Keep the recording drive relatively clean. You don't have to be obsessive about it, but just keep an eye on how much space is left compared to the ~1GiB every 5 minutes that the recorder requires while it's running, plus the rate that you can transfer them off so as to free that space.[INDENT]o Note: Transferring a recording (the safe way, at least) makes a copy. You still have to delete it from the Pi explicitly.[/INDENT]
o You might want to delete the recording logfile every so often, just to keep it from becoming too large and nearly impossible to navigate. If you need an old log, you can transfer it along with the recording(s) that it goes to, and then delete it from the Pi.[INDENT]o Note: There are actually two possible logfiles in the same place. Which one you have access to depends on whether the drive is present or not. If it is, then you get the one on the drive; if not, then you get the one on the Pi itself.[/INDENT]

Automatic mode switches:
o If the USB plug from the Pi to the XR18 is out, it will wait until it's in before it tries to record, play, or stream anything. This is meant to transfer recordings without needlessly eating up CPU time.
o If there's no UCA202 to stream with, it simply won't try. If it's plugged in later, it will start then, again with no need to reboot.

Automatic "hiccup recovery":
o If the USB plug comes out, it will cleanly stop recording (with a note to that effect in the recording logfile), wait for the USB plug to go back in, and then start another recording. This way, you only lose the time that it was out, and not the time to reboot as well.[INDENT]o Note: the streaming continues to run in this case, and the jukebox remains active but cannot play.[/INDENT]
o If the recorder itself hiccups, it will put a note to that effect in the recording logfile, along with a timestamp of where to look in the recording to see if it needs some extra cleanup work.
o If the Pi somehow ends up off while the external power is on, the battery backup will automatically reset the Pi so that it turns back on and starts up again.[INDENT]o Note: a jumper between the center two pins of the battery backup's 6-pin programming header will make it ignore the Pi and not try to reset it. This allows the Pi to stay off or to not be present while charging the battery. This forced-on state also means that the battery will discharge when the external power goes away, so it's not recommended to set-and-forget it this way.[/INDENT]

Possibly odd quirk to some people, that I didn't change:
o The recording drive is only detected on startup, fairly late in the process.[INDENT]o This is to keep the logfiles somewhat sensible, and isn't really considered a problem because you're supposed to power down to change drives anyway.[/INDENT]

To build the entire system from scratch, including the Pi, FOH laptop, battery backup, and XR18 network settings, see here:
https://drive.google.com/open?id=0B088FYjTvcxHeDZ6ajVJWVBWYk0

For a Pre-built Banana Pi image, licensed under GPLv2, see here:
https://drive.google.com/open?id=0B088FYjTvcxHLU0wSHItNlZnajA
This saves some lengthy downloads and source-code compilations that otherwise must be done on the Pi.

---

Updated Version 0.2:

AudioHub:

Default static address
- Actually uses DHCP to start - static IP must be set manually - but changed the example to the intended address as noted in Network-Topology.txt

Startup-Main.sh
- Changed REC_DRIVE from /dev/sda to /dev/sda1, to be more compatible with GParted and other disk utilities

RecPlay.sh
- Added a permission file that also specifies a maximum record time
- Manually removing the file stops the recording early
- Negative or unspecified time records indefinitely, until manually stopped or the drive is full

Shutdown.sh
- Changed default time from 5 minutes to 15 seconds
- Also requires XR18 to go down, not just the router (this lets it survive a router reboot)

Playback.sh
- Added new
- Provides a basic virtual soundcheck, remixed reprise, etc.
- Must be run from SSH, no file-triggered function (yet?)

Commands.txt
- Updated to match the above

FOH:

Recordings
- Moved the Conversion scripts to the Scripts folder with the rest of them
- Added timestamps in the terminal while converting, for a rough estimate of time remaining

Commands.txt
- Updated for Behringer's official 64-bit app (no more need to install the 32-bit libraries)
- Added NumLock so that the number pad works on startup for laptops that have them
- Updated to match the Conversion scripts' new location

To Build From Scratch:
https://drive.google.com/open?id=1KwExqlWBgDqbuAdNo-olWPIWGn3OcrIh

Pre-built Banana Pi image, licensed under GPLv2:
https://drive.google.com/open?id=1FbhwYUlSLf6mmkf4xk6OnVzlL57rN4Oy
AaronDuerksen Contributor - Level 2 2017-01-31

2017-01-31

18-track Recorder + Remote Jukebox + Solo/Talkback Streaming

It all works, and I'm pretty sure the documentation is right, so I guess it's time to post it.

This system consists of:
o 3-outlet power strip (minimum)
o XR18 (the one with 18-track USB instead of a built-in player/recorder)
o Banana Pi Pro
o SATA SSD for recording
o UCA202 USB<->analog line-level for streaming
o Custom Battery Backup for Banana Pi
o External router for a real network
o Touchscreen laptop for Front-of-House, running Lubuntu Linux

Initial setup:
o Mount the power strip, router, Pi, UCA202, battery backup components, and XR18 together, preferably in a mobile rack box.[INDENT]o All of these parts can be somewhat small, so depending on the exact arrangement, it might actually end up requiring no extra real estate on the face of the rack.[/INDENT]
o Run two short Cat5 cables from the router to the XR18 and to the Pi.
o Run a USB cord from the Pi to the XR18.
o Run two RCA<->1/4" adapter cables from the UCA202 to the XR18:[INDENT]o UCA202 Line-out to XR18 channel in
o XR18 Headphone out to UCA202 Line-in[/INDENT]
o Configure the router as desired for this dedicated network, preferably with a viable internet connection.
o Follow the Commands.txt files (linked at the bottom of this post) to set up the software. (these need internet access)

To use, simply give it power.
The Pi and the router will start up and provide their functions automatically.

To stop using, just unplug the power strip and pack it up.
The router will turn off immediately (no more network). The Pi will see that, wait for the router to reboot, and shutdown automatically if it doesn't. Once the Pi is finished shutting down, the battery backup disconnects itself to avoid further discharge.

Basic Maintenance:
o Keep the recording drive relatively clean. You don't have to be obsessive about it, but just keep an eye on how much space is left compared to the ~1GiB every 5 minutes that the recorder requires while it's running, plus the rate that you can transfer them off so as to free that space.[INDENT]o Note: Transferring a recording (the safe way, at least) makes a copy. You still have to delete it from the Pi explicitly.[/INDENT]
o You might want to delete the recording logfile every so often, just to keep it from becoming too large and nearly impossible to navigate. If you need an old log, you can transfer it along with the recording(s) that it goes to, and then delete it from the Pi.[INDENT]o Note: There are actually two possible logfiles in the same place. Which one you have access to depends on whether the drive is present or not. If it is, then you get the one on the drive; if not, then you get the one on the Pi itself.[/INDENT]

Automatic mode switches:
o If the USB plug from the Pi to the XR18 is out, it will wait until it's in before it tries to record, play, or stream anything. This is meant to transfer recordings without needlessly eating up CPU time.
o If there's no UCA202 to stream with, it simply won't try. If it's plugged in later, it will start then, again with no need to reboot.

Automatic "hiccup recovery":
o If the USB plug comes out, it will cleanly stop recording (with a note to that effect in the recording logfile), wait for the USB plug to go back in, and then start another recording. This way, you only lose the time that it was out, and not the time to reboot as well.[INDENT]o Note: the streaming continues to run in this case, and the jukebox remains active but cannot play.[/INDENT]
o If the recorder itself hiccups, it will put a note to that effect in the recording logfile, along with a timestamp of where to look in the recording to see if it needs some extra cleanup work.
o If the Pi somehow ends up off while the external power is on, the battery backup will automatically reset the Pi so that it turns back on and starts up again.[INDENT]o Note: a jumper between the center two pins of the battery backup's 6-pin programming header will make it ignore the Pi and not try to reset it. This allows the Pi to stay off or to not be present while charging the battery. This forced-on state also means that the battery will discharge when the external power goes away, so it's not recommended to set-and-forget it this way.[/INDENT]

Possibly odd quirk to some people, that I didn't change:
o The recording drive is only detected on startup, fairly late in the process.[INDENT]o This is to keep the logfiles somewhat sensible, and isn't really considered a problem because you're supposed to power down to change drives anyway.[/INDENT]

To build the entire system from scratch, including the Pi, FOH laptop, battery backup, and XR18 network settings, see here:
https://drive.google.com/open?id=0B088FYjTvcxHeDZ6ajVJWVBWYk0

For a Pre-built Banana Pi image, licensed under GPLv2, see here:
https://drive.google.com/open?id=0B088FYjTvcxHLU0wSHItNlZnajA
This saves some lengthy downloads and source-code compilations that otherwise must be done on the Pi.

---

Updated Version 0.2:

AudioHub:

Default static address
- Actually uses DHCP to start - static IP must be set manually - but changed the example to the intended address as noted in Network-Topology.txt

Startup-Main.sh
- Changed REC_DRIVE from /dev/sda to /dev/sda1, to be more compatible with GParted and other disk utilities

RecPlay.sh
- Added a permission file that also specifies a maximum record time
- Manually removing the file stops the recording early
- Negative or unspecified time records indefinitely, until manually stopped or the drive is full

Shutdown.sh
- Changed default time from 5 minutes to 15 seconds
- Also requires XR18 to go down, not just the router (this lets it survive a router reboot)

Playback.sh
- Added new
- Provides a basic virtual soundcheck, remixed reprise, etc.
- Must be run from SSH, no file-triggered function (yet?)

Commands.txt
- Updated to match the above

FOH:

Recordings
- Moved the Conversion scripts to the Scripts folder with the rest of them
- Added timestamps in the terminal while converting, for a rough estimate of time remaining

Commands.txt
- Updated for Behringer's official 64-bit app (no more need to install the 32-bit libraries)
- Added NumLock so that the number pad works on startup for laptops that have them
- Updated to match the Conversion scripts' new location

To Build From Scratch:
https://drive.google.com/open?id=1KwExqlWBgDqbuAdNo-olWPIWGn3OcrIh

Pre-built Banana Pi image, licensed under GPLv2:
https://drive.google.com/open?id=1FbhwYUlSLf6mmkf4xk6OnVzlL57rN4Oy

  • 0 Kudos
  • 11 Replies
  • Reply
Highlighted
Contributor - Level 2

Re: 18-track Recorder + Remote Jukebox + Solo/Talkback Streaming

Hey Aaron,

awesome setup, very impressive! Do you have any pictures of your setup you'd be willing to share?

I got to say, you beat me to the punch, as I have been building a very similar rack Smiley Very Happy I (have to) use a Raspberry Pi as it also does DMX.

Do you record the full 24bit, 48kHz? And have you witnessed any dropouts or overruns while recording?

As the Raspberry doesn't have SATA I record straight to USB, which gave me major headaches Smiley Sad In the end I managed to record CD quality (16 bit, 44.1 kHz) to a USB thumb drive. Everything else resulted in buffer overruns and therefore aduio dropouts in the recording.

Did you ever try to record to a USB drive on the Banana Pi?

If you're interested, I'll surley do a proper presentation of my rack when I get around to it.

br,
Thomas
Highlighted
Contributor - Level 2

Re: 18-track Recorder + Remote Jukebox + Solo/Talkback Streaming

Thomas Horn;93982 wrote:
awesome setup, very impressive! Do you have any pictures of your setup you'd be willing to share?


Thanks! I still need to figure out how to mount everything, but it does work spread out on top of the gator case / wheeled rack box. Once I get it mounted, I'll post some pictures.

Thomas Horn;93982 wrote:
I got to say, you beat me to the punch, as I have been building a very similar rack Smiley Very Happy I (have to) use a Raspberry Pi as it also does DMX.


Ooo, cool! DMX too! I'm not sure why you *need* a Raspberry for that though. The Banana also has a built-in UART if that's what you're using, and my setup also has one spare USB. I'm using both full-size USB's for sound cards (XR18 + UCA202), but there's also a USB OTG port on the other side that can be adapted to full-size. That was one of my variations that didn't make it, but the OTG port did work as a third independent USB 2.0 host.

In contrast, the Raspberry only has one USB 2.0 host that runs through an onboard hub to the external ports and to the ethernet adapter. So all of that has to fight over 480Mbps total bandwidth. Not so for the Banana; each of its USB ports has its own dedicated host, and the ethernet port also goes directly to the CPU with no USB needed at all for that. (so it can be gigabit too) That was one of the reasons for me to use a Banana instead of a Raspberry.

Thomas Horn;93982 wrote:
Do you record the full 24bit, 48kHz? And have you witnessed any dropouts or overruns while recording?


Actually, it's 32bit, 48kHz. Yes, I know that's overkill, but there are literally no options with the XR18. The USB audio is always 32bit integer and runs at the same rate as the DSP. So you could set it for 44.1kHz or 48kHz, depending on whether you're making a CD or video to avoid resampling, but that's pretty much it. I always have it set to 48kHz to swap a camera's audio in post-production, so I think I hardcoded that into the record command. If I did, you can change it easily. You'll also need to change the conversion scripts that the FOH laptop ends up with because the raw recording doesn't describe itself like a WAV file does.

As for dropouts and overruns, it does need to flush the buffer quite often because it ties up the CPU and can lose samples just because it's busy for that long at one time. So if you look at the RecPlay.sh script, you'll notice towards the bottom that I start the recording (the arecord command) and then drop into a loop that forces that flush (the sync command) every second. That keeps the hard-drive-write buffer small enough that the CPU can finish and come back before the sound-card-read buffer fills up. No problems at all with that, recording to a dedicated SSD using the Banana's native SATA port.

Thomas Horn;93982 wrote:
As the Raspberry doesn't have SATA I record straight to USB, which gave me major headaches Smiley Sad In the end I managed to record CD quality (16 bit, 44.1 kHz) to a USB thumb drive. Everything else resulted in buffer overruns and therefore aduio dropouts in the recording.

Did you ever try to record to a USB drive on the Banana Pi?


Never tried that. USB in general represents a bottleneck to me, so I try to use application-specific protocols when possible.

Thomas Horn;93982 wrote:
If you're interested, I'll surley do a proper presentation of my rack when I get around to it.


I'd like to see that. I tend to think I'm doing a good job...until I see what someone else did and wonder why I didn't think of that.
Highlighted
Contributor - Level 2

Pictures!

Here's the basic idea:

This is all upside-down and out of the rack so I can get to things. The tray is from a 1/4" patchbay that I only used the face of in our permanently-installed analog system, and it just barely fits behind the custom patchbay that we put on the back of the XR18 for outputs. The face of that 1U assembly is a blank cover plate that we put 4 XLR line outputs in. We'll have to trim the angle a little bit to clear the tray's ears, but it'll work. Thus, no extra real-estate required on the face of the rack.

The output patchbay also provides a convenient mounting spot for the UCA202:

Yes, it clears the fan.

Just to show that this does actually fit in one rack unit, here's the power strip on top of it (under it in the final rack - remember this is upside-down), with the router's power brick plugged into it:

I think the biggest problem now is going to be cord management. A couple of these are like 6 feet (2m) long with a special plug on the end. Might need to shorten those.

Details of what's in the tray:

I left out some of the cords that I know are going to work, like USB's and Cat5's, to make it a little bit easier to see what's there.
And the router board actually has the corner notched out where the Pi is. I thought that was nice of Linksys to do that for me. Smiley Happy

And spread out so you can actually see what it is:

The extra pigtail coming off of the Pi is for the internal battery backup. It takes a single-cell Lithium Ion battery, but it doesn't back up the hard drive. My attempts to power the hard drive from the GPIO connector that *is* backed up didn't work so well, hence the completely external backup. I'll probably get out my hot-air rework gun and take the pigtail back off.

Detail of the UPS and Power Management boards:


Bottom of the UPS and Power Management boards, so you can see my ad-hoc soldering:

I can design and order professional PCB's too, but this is much faster than waiting for a fab house to turn around.
And yes, I'm only using two pins out of the 40-pin GPIO header (3.3V and GND), so it could be that much shorter. Oh well.
Highlighted
Contributor - Level 2

Re: 18-track Recorder + Remote Jukebox + Solo/Talkback Streaming

Hi Aaron,

sorry for not getting back to you sooner, I'm extremly busy right now! I'll just go down the line of open topics Smiley Very Happy

So I "had" to use the raspi because of DMX. I indeed am using the UART Interface in conjunction with a board from bitwizard and the QLC+ software. The developer offers a brebuilt image of QLC+ for Raspberrys, that's why I choose to stick to it. You could go ahead and compile the software from source, but I gave it a quick try and decided I don't have the time/nerve to delve deep enough into QLC+ to sort out all issues.

That, of course, means no SATA for me, but i'm quite happy with the way I managed the recording. I use a programm called "sox", which in turn also uses arecord of course. But I found sox is easier to work with, especially concering buffers. The main problem with arecord was, that it ran into overruns, probably due to a combination of small buffer (max. 500ms), slow file-system write on my flash drive (xfs-formating worked best) and bottlenecked USB controller. I also tried the periodic sync command, but that didn't work out for me.
You are right of course, in that the XR18 only offers 32 bit resolution over USB, but afaik the ADCs in the unit are 24 bit, so the rest should be just padding. In the end I opted for 16 bit, as that will record smoothly without interrupts. The conversion from 32 to 16 is done by sox on the fly - pretty neat actually! All in all, my goal was less to build a sturdy, fail-safe and reliable recorder, like you did, but more of a solution for conveniently recording straight to USB flash drive. If I really NEED to get a recording right and in full 24 bit, I'd still use external hardware. Kudos to you for making the recorder professionally usable!

Here are a few pictures of my setup - I'll do a proper rundown, when I come round to it!


So here's the final rack 4 spaces high, with mixer, raspberry, dmx and soundcard in the bottom 3 spaces and router, patchbay and UHF receiver in the top one. Complete with tablet, mic and external cabling Smiley Wink


That's the tray in the top space. Router on the left and receiver on the right. I do a lot of weddings, where I need to have a wireless mic for speeches, so I wanted to integrate it into the rack. Nice idea to ditch the enclosure of the router - saves a little space!

I also struggled with the cabling and ended up soldering custom cables for nearly everything! I even went so far as to remove the shielding for the ethernet pigtails, as they otherwise wouldn't bend enough to fint inside. The Patchbay on the front offers antennas for WiFi and the wireless Mic, two Ethernet-ports, two USB-ports from the raspberry for charging and thumb drives as well as two fans. Still the XR18 gets quite hot - a little worring, but I have yet to see negative effects and others report now problems with their rack-mounted units.


Lastly a pic of my raspberry mount. I made custom rack-ears for the XR18, to which the raspberry just so happens to fit on the bottom. The holes next to it are for 2x DMX with a splitter in the back and cables for jukebox and sound-to-light. I wanted a analog music input from the raspberry to the mixer, for when I have the USB of the XR18 hooked up to a laptop.

Power is distributed over a standard power strip mounted to the bottom of the rack behind the XR18 with an inlet on the side.

Again, kudos to you for all the electronics and soldering work! I just couldn't be bothered to put more effort into the recording part of things It's mainly a rack for convenience at gigs, to reduce setup time and have everything I need in a portable enclosure.

Alright, hope you found it interesting! Smiley Happy

br,
Thomas
Highlighted
Contributor - Level 2

Re: 18-track Recorder + Remote Jukebox + Solo/Talkback Streaming

Thomas Horn;95344 wrote:
You could go ahead and compile the software from source, but I gave it a quick try and decided I don't have the time/nerve to delve deep enough into QLC+ to sort out all issues.


Yeah, it took some work to figure out all the dependencies that need to be installed before the compiler works, which of course are different for each application that you want to build. That being said though, I found some instructions here that seem to include that for QLC+:
https://github.com/mcallegari/qlcplus/wiki/Linux-Build-HOWTO
The Debian version should work for Raspbian, Bananian, *buntu, or anything else that is derived from Debian.

However, the other problem that you might not have noticed is that QLC+ is a graphical application while the Bananian image that I'm using does not have any kind of display manager at all. I started my project with Lubuntu on both the Pi and the laptop, mostly for familiarity when working on the Pi over VNC. But the BPi's official Lubuntu image is horribly outdated and not supported anywhere (even on their own forum) and I found an entire set of software that doesn't need a local GUI. So I went completely headless.

I didn't look closely enough to see if QLC+ is or can be can be split like MPD - user interface on one machine, function on another, across a network - but that would also be a requirement to use it on my system, in addition to compiling from source because it doesn't have a prebuilt Banana image or even a binary package for armhf. (ARM chip with Hardware Floating-point, same as the Raspberry) There are reports of installing a GUI on Bananian, but that's probably not worth it for just the one app.

Thomas Horn;95344 wrote:
I use a programm called "sox", which in turn also uses arecord of course. But I found sox is easier to work with, especially concering buffers. The main problem with arecord was, that it ran into overruns, probably due to a combination of small buffer (max. 500ms), slow file-system write on my flash drive (xfs-formating worked best) and bottlenecked USB controller. I also tried the periodic sync command, but that didn't work out for me.


I've heard of that. My FOH conversion scripts actually use it to get 18 full-length single-track WAV files out of the giant monolithic block of raw data that comes from the Pi. But that's all I use it for because arecord by itself seems to do okay with ext4 on a native SATA drive. I do have to pipe it to the drive, via stdout (command > file), instead of writing directly because arecord itself panics at 2GiB. (~10 minutes at my rate) The pipe moves that problem to the operating system, which is perfectly fine with it.

Thomas Horn;95344 wrote:
You are right of course, in that the XR18 only offers 32 bit resolution over USB, but afaik the ADCs in the unit are 24 bit, so the rest should be just padding.


Yes, the ADC's are 24-bit, but the DSP uses 40-bit floating-point and as soon as you do anything at all to the signal, you start filling those extra bits. Whether they actually mean anything is a different story, but the point is to keep the internal roundoff error low enough that the 24-bit output can't see it.

You can look at the source code of my power management board for one example of how this happens. It makes a 24-bit signal from a 10-bit ADC...and then only uses the top few bits of it. It's probably overkill the way that I did it for this particular application, but it was quick to write (mostly from memory), quick to run, and it works really well.

So the 32-bit USB output technically truncates the internal signal. Again, that hardly matters because even 24-bit audio has enough dynamic range to cover inaudible to immediate deafness with no gain adjustments. (it's actually better than 15-0-15V analog electronics, considering the thermal noise floor and of course clipping)

Thomas Horn;95344 wrote:
I wanted a analog music input from the raspberry to the mixer, for when I have the USB of the XR18 hooked up to a laptop.


I might be wrong on this - haven't actually looked it up - but I believe that the RPi's onboard DAC is only 11-bit. Probably because it's cheap and most people either don't use it at all or don't notice the difference in practice. It's still a dynamic range of 20*log(2^11) = 66dB, which is better than the signal/noise in a lot of venues. Smiley Wink (signal = PA, noise = audience)

Thomas Horn;95344 wrote:
I'll do a proper rundown, when I come round to it!


Great! Looking forward to it! Smiley Very Happy (I still need to finish mounting and post completed pictures.)
I'm especially interested in the DMX part, though I'm not sure that the system I'm building now will have it. Maybe something else will.
Contributor - Level 2

Re: 18-track Recorder + Remote Jukebox + Solo/Talkback Streaming

Aaron Duerksen;95388 wrote:
Yeah, it took some work to figure out all the dependencies that need to be installed before the compiler works, which of course are different for each application that you want to build. That being said though, I found some instructions here that seem to include that for QLC+:
https://github.com/mcallegari/qlcplus/wiki/Linux-Build-HOWTO
The Debian version should work for Raspbian, Bananian, *buntu, or anything else that is derived from Debian.


It wasn't so much a problem of getting the dependencies right, I actually managed to get a self-compiled version of QLC+ running on Raspbian. But it was missing UART-Integration to talk to my daughterboard and the web-interface didn't work. That could surely be fixed with a few settings in the source code, but I couldn't afford the time to look into it.

For the moment I am also running headless. The prebuilt image of OLC+ doesn't use the X11 desktop, but rather runs on OpenGL directly. That means you can only look at the GUI via HDMI monitor, VNC won't work. Presumably Massimo did this to make QLC+ run on a Raspberry Pi 1 - a model 3 like mine would probably be fine with X11 and VNC.

For programming my light shows I use QLC+ on a laptop with the Raspberry working as a passthrough from ArtNet to DMX and then load the scene onto the raspberry. Then I can control everything from the browser interface QLC+ offers. In the long run I plan to replace that solution with an OSC client along the lines of TouchOSC.

Aaron Duerksen;95388 wrote:
I've heard of that. My FOH conversion scripts actually use it to get 18 full-length single-track WAV files out of the giant monolithic block of raw data that comes from the Pi. But that's all I use it for because arecord by itself seems to do okay with ext4 on a native SATA drive. I do have to pipe it to the drive, via stdout (command > file), instead of writing directly because arecord itself panics at 2GiB. (~10 minutes at my rate) The pipe moves that problem to the operating system, which is perfectly fine with it.


Yeah, I also tried quite a few combinations of pipeing the output of arecord to stdout, sox or others, but none seemd to work absolutly realiably. With the right combination I'd get just a few short overruns of a few hundred milliseconds over the course of a multiple hour recording, but never a perfect result. So I opted for lower quality in favor of reliable capturing. I assume you transfer the recordings from the SSD via ethernet?

Aaron Duerksen;95388 wrote:
Yes, the ADC's are 24-bit, but the DSP uses 40-bit floating-point and as soon as you do anything at all to the signal, you start filling those extra bits. Whether they actually mean anything is a different story, but the point is to keep the internal roundoff error low enough that the 24-bit output can't see it.


Oh, I wasn't aware of that, thanks for pointing it out! But either way, I can't write even 24 bit reliably. There still might be some headroom from 16 bit, so maybe the pi could manage 18, even 20 bit. If only there was a Raspberry with USB 3...

Aaron Duerksen;95388 wrote:
I might be wrong on this - haven't actually looked it up - but I believe that the RPi's onboard DAC is only 11-bit. Probably because it's cheap and most people either don't use it at all or don't notice the difference in practice. It's still a dynamic range of 20*log(2^11) = 66dB, which is better than the signal/noise in a lot of venues. Smiley Wink (signal = PA, noise = audience)


You are quite right Smiley Happy I forgot to mention it, but I don't use the built in DAC of the Raspberry, but rather a generic external USB soundcard. Can't recall the exact make and model, nothing fancy, but it does the job. Better than the built in I might add. This soundcard is also what feeds back the Aux 6 from the XR18 to QLC+ for sound to light. This is in early stages, the programming of the lightshow in QLC+ is rather unwieldy and I have not put much effort into StL, but it works in principle.

How do you manage the controls of your headless device? In keeping with my low-profile approach I try to keep all the controls on an android tablet, which works beautifully for XR18 with Mixing Station, MPD with an app called M.A.L.P. and QLC+ with a simple browser interface. For controlling my recording script on the pi I use an app called "Hot Button" which let's you define a SSH connection to a server and fixed bash commands to execute at the press of a button. The choice fell upon Hot Button as it was the only app I could find, that showed responses from the server. Still, it would be nice to have a continuous indication if the recording is running without having to manually press a "polling" button. Do you have a different/better approach to this?
Highlighted
Contributor - Level 2

Re: 18-track Recorder + Remote Jukebox + Solo/Talkback Streaming

Thomas Horn;95391 wrote:
It wasn't so much a problem of getting the dependencies right, I actually managed to get a self-compiled version of QLC+ running on Raspbian. But it was missing UART-Integration to talk to my daughterboard and the web-interface didn't work. That could surely be fixed with a few settings in the source code, but I couldn't afford the time to look into it.


Oh! Yeah, I don't think I can help you there, beyond what you've already done.

Thomas Horn;95391 wrote:
The prebuilt image of OLC+ doesn't use the X11 desktop, but rather runs on OpenGL directly. That means you can only look at the GUI via HDMI monitor, VNC won't work. Presumably Massimo did this to make QLC+ run on a Raspberry Pi 1 - a model 3 like mine would probably be fine with X11 and VNC.


Hmm. That's interesting. I saw that note on his RPi page, but I didn't realize he went that far with it. That sounds like a lot of work on his end.

Thomas Horn;95391 wrote:
For programming my light shows I use QLC+ on a laptop with the Raspberry working as a passthrough from ArtNet to DMX and then load the scene onto the raspberry. Then I can control everything from the browser interface QLC+ offers.


I'm not sure I follow that. So you have one copy of QLC+ on a laptop that actually runs the show, and sends commands to the RPi running another copy of QLC+ as a translator to the real world? Or you have presets in the Pi that are triggered from the laptop? Anyway, this might be better suited for the complete write-up once you get it all done.

Thomas Horn;95391 wrote:
In the long run I plan to replace that solution with an OSC client along the lines of TouchOSC.


The X-Air mixers also use OSC. Maybe light and sound could be combined into one app? Also a lot of work though...

Thomas Horn;95391 wrote:
I assume you transfer the recordings from the SSD via ethernet?


Usually, yes. Since the SSD is formatted to ext4, any Linux machine should be able to read it, but I usually don't have one available that has an accessible SATA port. A USB to SATA adapter would also be faster than the network, but I don't have one of those either. Besides, the drive is pretty well buried once I get it all together. It's velcro'ed in so that I *could* remove it if I really wanted to, but not during a theatrical mission trip that has 2-5 shows a day for a week straight, all in different locations. I tried to size it to handle an entire trip's worth of shows without having to transfer/delete any, but I like to do that overnight anyway just to be sure.

Thomas Horn;95391 wrote:
How do you manage the controls of your headless device? In keeping with my low-profile approach I try to keep all the controls on an android tablet, which works beautifully for XR18 with Mixing Station, MPD with an app called M.A.L.P. and QLC+ with a simple browser interface. For controlling my recording script on the pi I use an app called "Hot Button" which let's you define a SSH connection to a server and fixed bash commands to execute at the press of a button. The choice fell upon Hot Button as it was the only app I could find, that showed responses from the server. Still, it would be nice to have a continuous indication if the recording is running without having to manually press a "polling" button. Do you have a different/better approach to this?


I use Gnome Media Player Client (gmpc) on the FOH laptop to control MPD on the Pi. It has its own heartbeat/polling and user-notification, so I know from there that I'm running and connected. Otherwise, it's all managed by some scripts that are called from /etc/rc.local on startup. Both the Pi and the FOH laptop have their own set of scripts, so things "just work" when you turn them on. FOH requires a manual start, but all the functions of that are scripted. That's because it has no good way of knowing automatically, like the Pi does, whether you're running a show or dumping recordings or something else.

As a backup, I also have X-Air Edit and Droid MPC on my phone, but I haven't used them enough to comment on the details. The only thing that misses is the streaming talkback and solo...oh well.

Hot Button looks interesting. I might not use it for the portable sound system, but I also have an RPi-based fileserver/NAS that might benefit from it...
Highlighted
Contributor - Level 2

Re: 18-track Recorder + Remote Jukebox + Solo/Talkback Streaming

This is amazing work guys.
I'm already using a Linux Laptop to do my recording (been using Tracktion and Ardour) but the setup can be a bit of a chore and have been looking to trying to make it a little bit more one touch.

I was looking at DMX too ... not that I use it right now but it certainly loks like another nice "toy" to play with ... saw an ethernet (sACN) to DMX interface on amazon that looked like it could be useful.
https://www.amazon.co.uk/gp/product/B01827XMUC/ref=ox_sc_sfl_title_3?ie=UTF8&psc=1&smid=AA1X5YMMNBD3...
Highlighted
Contributor - Level 2

Updated Version 0.2

I finally got to test it, so here it is:

---

Changes:

AudioHub:

Default static address
- Actually uses DHCP to start - static IP must be set manually - but changed the example to the intended address as noted in Network-Topology.txt

Startup-Main.sh
- Changed REC_DRIVE from /dev/sda to /dev/sda1, to be more compatible with GParted and other disk utilities

RecPlay.sh
- Added a permission file that also specifies a maximum record time
- Manually removing the file stops the recording early
- Negative or unspecified time records indefinitely, until manually stopped or the drive is full

Shutdown.sh
- Changed default time from 5 minutes to 15 seconds
- Also requires XR18 to go down, not just the router (this lets it survive a router reboot)

Playback.sh
- Added new
- Provides a basic virtual soundcheck, remixed reprise, etc.
- Must be run from SSH, no file-triggered function (yet?)

Commands.txt
- Updated to match the above

FOH:

Recordings
- Moved the Conversion scripts to the Scripts folder with the rest of them
- Added timestamps in the terminal while converting, for a rough estimate of time remaining

Commands.txt
- Updated for Behringer's official 64-bit app (no more need to install the 32-bit libraries)
- Added NumLock so that the number pad works on startup for laptops that have them
- Updated to match the Conversion scripts' new location

To Build From Scratch:
https://drive.google.com/open?id=1KwExqlWBgDqbuAdNo-olWPIWGn3OcrIh

Pre-built Banana Pi image, licensed under GPLv2:
https://drive.google.com/open?id=1FbhwYUlSLf6mmkf4xk6OnVzlL57rN4Oy