Synology DSM Login and Connection Issue

TL;DR: if you cannot access DSM via the web or the apps, the date on your Synology might be wrong causing the services to either not start or not respond correctly.

 I had a strange error with my Synology DS416play the other day.  I had to power the system down to connect it to a new UPS.  Upon powering it back up, I could not access the DSM console via the web, nor would any of the Synology / DS apps connect.  No amount of restarts or kicking the box would fix the issue.

What was strange is SMB and SSH were working fine, meaning that the underlying OS and system were working fine.  I could copy files to and from using SMB/CIFS and I could ssh into the box itself.

I opened a support case with Synology and we started collecting logs and other information.  One of the things they asked for was to confirm that the drives in the system were on the compatibility list.  To do that, I had to shut the system down.  When I powered it back up, I noticed that the drive lights had shut off.  I confirmed that the system was running and that made me realize that the date could be wrong.  I have the lights set to go dark at night.

I logged into the server and checked the date and sure enough, it had reset to Jan 1, 2015 00:00:00.  I sudo'd to root and reset the date using the date command and suddenly DSM access was restored.  I assume that means the CMOS battery needs to be replaced, but that's something for tomorrow ...

First Publication

Wanted to let everyone know that I'm now a published academic author.  Last year, I presented a paper at the IEEE EDOC conference, or more specifically the VOTRE workshop.  Later last year, the paper was officially published and is now available through the IEEE.

The information in the paper will be the basis of my PhD thesis.  I'm now working on follow up papers that will attempt to add to and answer the questions from this paper.

Allen & Heath SQ vs Behringer Wing

For those of you who know me, you know that in addition to being a propeller head of the highest order, I am also a professional audio engineer.  It's not my day job, but something I tend to do on the side.  Given that, I've started haunting the r/livesound subreddit.  A few months ago, someone asked about the Wing vs other options.  I've been thinking about it for a while and decided that was a good time to put my thoughts on "paper".  As people found the answer useful, I thought I'd publish it here lightly edited.

 

Here's my take: those who love the Wing, really love it. I know some local engineers who have it and sing its praises. But I know others who don't. The split tends to be along the lines of X/M32 users love it and those who have used higher end consoles (DiGiCO, Yamaha, Studer, etc) don't like it as much.  Given that, as you're looking at a low/mid-level console, you need to ask the questions below.  And do note, this comparison focuses on the Allen & Heath SQ vs the Behringer Wing.

 

Like any question of this type: it depends on factors such as your budget, needs, and your choice of alternative.

 

Here's what I've started saying / recommending:

 

Are you an existing Behringer/Midas user (specifically into AES50)?

If so, then the Wing will likely be an upgrade, especially if you're hitting the top end of I/O in the X/M32 range. Below is my take on the pros/cons. Someone with more Wing experience might be able to add to the list.

• Pros
  • More channels that can all be stereo (aside: is this a major upgrade as most vocal mics, instruments and other inputs are likely mono and won't benefit)
  • More effects (autotune clone anyone?)
  • Big touchscreen
  • It is newer so should be supported longer than a new X/M32 today
  • Fully remappable surface (you can make any fader on any layer be what you want it to be like the A&H SQ line and GLD before it as well as higher end consoles)
  • Generally more of everything
  • More flexible input/output mapping vs the X/M32 (yes firmware 4.x makes 1:1 patching possible but it's still more complicated than is necessary)
• Cons
  • Bigger than a M32 Live / X32 Compact / X32 Producer (that might matter if you're having to move it constantly like a touring band where a smaller/rack mountable console might be better)
  • New patching system that is still different than the industry standard grid patching layout used by A&H, Yamaha, DiGiCo, etc.
  • (personal opinion here) Potentially a more cramped layout as they added DAW controls that are not necessary for live sound and (potentially) unnecessarily split the fade banks. The X/M32 (full) has 16 mix faders and 8 DCA/bus faders plus the mains fader. The Wing is 20 mix/DCA faders and 4 mains(ish faders). Yes, then can be remapped, but in my usage I found it to feel a bit cramped. Probably with time it might become more comfortable.
  • No real path upwards (Next step up is Midas Pro or Heritage series that may need new stage boxes to support 96kHz vs 48kHz for the Wing/X32 and the price difference is immense vs the path up in the A&H line)
  • You MUST have a stage rack as the Wing only has 8 inputs on the surface vs 16-32 on the X32/M32 mixers (the SQ series is similar)
  • No offline editor (as of Jan 2022) and iOS/Android apps still developing to meet feature parity.

Are you looking to start new with a Wing-level budget?

• Consider the Wing of course as it's a fine console and will be broadly supported and see above for pros/cons vs X32/M32.
• Consider the Allen & Heath SQ line as it has similar feature set:
  • Pros
    • 96kHz (there is discussion as to which is better, but it is a thing)
    • More options to upgrade (same stage racks work with the Avantis @ $10K and the dLive C/S-series $18k+)
    • Uses industry standard patching options (grid-based UI, same as DiGiCo, Yamaha, Avid, and A&H)
    • Three surface options giving same processing but flexibility for selecting the form factor / fader count needed (SQ5 16+Main, SQ6 24+Main, SQ7 32+Main)
    • Generally considered better sounding than the Behringer / Midas consoles, though of course opinions vary
    • True offline editor and feature complete iOS/Android apps
  • Cons
    • Stereo inputs consume multiple channels vs the Wing
    • Fewer FX and what they have are descendants of the 2004 iLive FX which are not always the best
    • Proprietary Slink port for audio connections vs AES50 which is a standards, though it has limited adoption outside the Behringer/Midas world.
    • More expensive components (surface, stage rack, add-in cards) than the Behringer side

For myself, I ended up skipping the Wing and SQ altogether and bought a Allen & Heath Avantis and love it. It has almost everything I could have wanted (short of a dLive, DiGiCo SD or Yamaha CL/QL) at a price that is probably better than anything else on the market at that range.

First Conference Session

Just a quick update, but I've had a conference presentation accepted for early March.  I submitted a proposal to the Workflow Workshop and Hackathon (WoWoHa) 2020 in Livermore, California and was accepted.

The conference looks to be great with a number of interesting presentations.  Maybe I'll see some of you there. 

PhD v2.0

It was about two and a half years ago that I started publishing information about my presumed pending doctoral program.  Well, that ended up being sidelined because of the Romanian Ministry of Education.  In reviewing my application, they determined I was not eligible because I had not attended or completed a master's degree.

Whoops!

Nothing like selling everything you have and preparing to move to a new country only to discover that the primary reason (or excuse) you planned the move was not going to happen.  At least the educational system in Romania tends towards a "things get done at the last minute" method, so I was able to apply for a Master's Program at UBB instead.  And, while the process was annoying, it did end up with me having a better understanding of the process and a stronger line on what I will be attempting to research.

My original plan was to continue my loose work around text analytics, but the more time I spent learning the math involved, the more I started to understand that my passions lie elsewhere.  Now, that's not to say I won't end up picking this back up, but for now I plan on working towards a different topic.

Which brings us to the main thrust of this post: I have now been accepted into the PhD program at Universitatea Babes-Bolyai.  This time, I'm going to start looking into the intersection of workflow management and parallel programming.  Associate Professor Virginia Niculescu posed the following question during my last semester: what overlap is there between the workflow patterns (as documented by van der Aalst and Russell) and the defined parallel programming patterns.

With that thought in my head, I started my Master's thesis based on that, with a healthy dose of advanced case management thrown in.  Apparently, it was enough to complete my degree.  Now, I plan on working to complete the thought, as I believe there is plenty of room left to research the topic.  In fact, my thesis was about 80 pages (including project documentation) and I firmly believe that I could have easily added another 20-40 pages.

Follow this space (and my ResearchGate profile) as I move forward.  I'm already starting to write what I hope to be my first academic article and as it progresses I will try and update here.

Masters is (Basically) Complete

This may be slightly premature as I'm still waiting on the final grades from the University, but Wednesday 3 July, I delivered my thesis/dissertation defense and final presentation.  I believe it went well and hope to publish my final paper on ResearchGate as soon as the final grades are out.  In the meantime, here's the abstract:

Computers and information technology are commonly used to perform complex tasks more efficiently. Within information technology, two disciplines that are often used to assist businesses and other domains complete processes in a more efficient manner are workflow management and advanced case management. Workflow management is a discipline that is used to document, enforce, and streamline repetitive processes. Advanced Case Management is an emerging field that is an alternative to traditional workflow management and that offers more flexibility in completing processes. Both disciplines can provide additional efficiency gains through enabling business to distribute tasks to multiple users simultaneously.

Another discipline in computer science is parallel and high-performance computing. It offers users a similar ability to increase performance and throughput of complex processes through parallel task execution and work distribution across multiple systems. 

To explore the commonality between the three disciplines, this paper will review both the disciplines of workflow management and advanced case management from a parallel programming perspective. In addition, this paper will present a prototype of a new framework based on the guard-stage- milestone methodology of advanced case management, that has been built on the Akka actor model framework, uses a common big data NoSQL database for data storage, and can be used to demonstrate how an advanced case management system can be used to as a parallel task execution environment.

URL Shorteners + Icecast/VLC

One additional thing I've been trying that seems to work well is using something like bit.ly.  We've been using it for linking to our online instructions, but last weekend I started using it as the URL for listening to the stream.  Now, instead of having to type in http://192.168.0.4:8000/live.mp3, the listeners can simply use bit.ly/CTEnglish.

So far, it seems to be working, though I haven't tried it on both iOS and Android.

Thoughts on Interpretation

I have a friend, Scott Garber, in the US who has been an interpreter for his church for a number of years.  When we started planning the new ministry, I reached out to him for some pointers.  With his permission, below are his thoughts:

1. It’s difficult to do the translation in the same space (or even off in a corner) as the main service. It just creates too much distracting noise. So, you have to figure out how the hearers are going to get the sound. At our church we give the listeners earpieces that fit over one ear and receive a radio signal (I suppose, as i don’t deal with the transmission of the sound). That allows them to follow the original audio as well. If you’re not going to translate everything (for instance, if you translate only the sermon) or if the listeners are also trying to learn Romanian, the live audio comes in handy. Plus, a full headset would make it hard to follow the live music.
2. The translator needs to be in a space where he or she can concentrate without distractions. I’m in a studio, where I have a monitor and a headset with a mic. It doesn’t have to be such a dedicated space, but stuff is going on around you that diverts your attention you’ll get behind and then have to start summarizing and paraphrasing to catch up. Or just lose track of what’s being said while you’re talking. You could do it without video, I suppose, but the video makes it a lot easier to follow. If the speaker writes anything or uses graphics, you’d get kind of lost without video. It also allows you to see the song lyrics if they are projected.
3. Translation works better if you have multiple services, even if you’re translating only one. That way the translator can attend a service before translating and think through/look up any tricky bits rather than being caught flat-footed. Plus, it allows the translator to have a worship experience, as translating is work. And to have any Scripture passages bookmarked before translating, so that those can just be read rather than having to translate them. If you have just one service there are things you can do to help the translator. All of these will also enhance the translation, even if the translator has a chance to experience the service beforehand. Having sermon notes ahead will allow them to make sure they have the best possible terminology for key words and main points. Plus, it will give them the Scripture passage ahead of time. If you want to translate the music, having the lyrics ahead of time is very helpful. If you’re translating into English, in many cases the translator could find the English lyrics. If not, it’s still helpful to see the Romanian lyrics, as poetic language can be trickier than normal speech, and it can throw translators for a loop. If you do dramas, it’s also really helpful to have that script ahead of time.
4. You have to determine which portions of the service you will translate. At the U.N. they switch out translators every 20 min. or so (I’ve been told). I do an hour and a half (minus some announcements and instrumental music), and it’s a lot. We don’t get the lyrics ahead of time, so not all of our translators even attempt to do music. Even though it would be handy to be able to switch out translators and keep them fresh, if you’re working with volunteers on a rotational basis it can get logistically hairy to find enough people if you have to use more than one per week, especially if that requires them to attend two services. 
5. I would suggest that you have at least a couple or three people that you can count on. One person might start with great enthusiasm but could easily get burnt out. Plus, if that person is away or ill, the people who have come to depend on translation are left high and dry.
6. If you are streaming the services you’ll have to decide whether or not translation will be part of that package and how to pull it off technically. You might want to work out the kinks and make sure that you’re really going to continue with translation long-term before you cross this bridge..
7. I think it’s important to have somebody who understands both languages monitor the translation, at least initially and from time to time, to make sure that you don’t have wildly divergent quality levels and that it’s actually working. Not everybody who is an expert in both languages can do simultaneous translation, so having some quality control can help determine if the translator(s) is capable. Feedback can also help improve performance over time. We don’t do this at our church, but I think we should. I know that some people, like me, are really translating, whereas I have the sense that some are just giving periodic summaries or very loose paraphrases. Your pastor(s) might not be happy to have people “flavoring” their messages too much.

Configuring Icecast and BUTT

In my last post, I described some of the recent changes we've made to our live interpretation tech and described some lessons learned.  Now I want to try and walk someone through the process of setting up a similar system to ours.  I'm going to focus on Windows, Icecast and Broadcast Using This Tool (BUTT).  I may add a second post to show how this can be configured using Linux as well, but for now Windows will do.

For starters, you'll need a Windows machine (probably Windows 7 based on my recent experience, though YMMV).  After that you will:

• Configure your Windows machine with either a static IP address or a DHCP reservation with your firewall.  (I'm a big fan of the DHCP reservation so you can take your machine elsewhere and it'll still work fine).
• Download the two packages mentioned above: Icecast and BUTT.

Install the Tools

• Install Icecast using the downloaded installer.  You can accept the defaults, but you might want to install it somewhere other than Program Files as you'll need to edit the configuration file and, given that it's a server, you might want to run as a non-system/non-privileged user.
• Install BUTT using the downloaded installer.

Configure Icecast

Icecast uses an XML configuration file.  Edit that file in your favorite text editor.  You will need to make the following changes (at minimum ... there may be more things you can do to harden the server).

1. Change the value of the <location>Earth</location> tag.  The value doesn't matter much, but Icecast will gripe at you if you don't.
2. Change the <admin>icemaster@localhost</admin> tag to your contact address
3. Change the <hostname>localhost</hostname> tag to your system's hostname
4. In the <limits> section:
1. set <queue-size>16384</queue-size>
2. set <burst-size>16384</burst-size>
5. In <authentication>, set the source, relay and admin passwords. 

Save the configuration and start the server with the icecast.bat file.  If you've done everything right, you should see a console window like this:

Configure BUTT

BUTT offers a nice UI for configuring the tool.  So, once you've started it, you can configure it using the UI.

Configure the server

1. Click the settings button to the right of the VU meter
2. Click the ADD button under the server drop down to configure your server.  Enter the following:
1. Name: I used localhost just because, but you can call it what you want
2. Type: Icecast
3. Address: localhost
4. Port: 8000
5. Password: <source password from icecast config file>
6. IceCast mountpoint: live.mp3 (or whatever you want it to be.  This is will be part of the URL for the Icecast server)

Configure Audio Settings

On the Audio tab you will configure the audio encoding settings.  The default assumes full CD quality 44100/stereo.  As this is voice only, you can greatly reduce your overhead and network usage by reducing this.  To do this, you will: 

1. Select your audio input device
2. Set channel to Mono
3. Set Samplerate to 22050Hz
4. Set the streaming bitrate to 64k

Save the settings and start streaming.

After you start, you might want to update the title of the stream using the Stream tab and update song name manually option.

Note: there is also an option on this tab to start streaming automatically.  Once you know you have the settings correct, enabling this option might be a good idea.  It simplifies the process.

Test

Now that you have your system up and running, you can test the sound by starting VLC (or any streaming client) and opening the stream.  You should adjust your audio to suit.

Documentation

I'm a big fan of creating documentation for volunteers to use.  As such, I created a HOWTO document for our team.  I've uploaded a sanitized version of this document here for you to use as a starting point.

Live Interpretation (Updated)

I had someone come to me today asking about the solution we are using for live interpretation.  Apparently news of this is starting to get around and this made me realize it's time to update the technical details and start posting some of my lessons learned.

Let's start with our current technology stack.  It's fairly similar to what we were using before, but we have managed to simplify it a bit.  Here's a list of tech:

• Hardware
• HP laptop (I don't have the specs currently)
• TP-Link TL-WDR4300
• Gatt MX-6 mixer
• Behringer UFO202 USB audio interface
• Sennheiser EM100 wireless microphone
• Software
• Windows 7
• Icecast
• Broadcast Using This Tool
• VLC for iOS and Android

The configuration is fairly straightforward:

• Connect mic to mixer
• Connect mixer to interface
• Connect the interface to the laptop
• Connect the laptop to router
• Connect router to internet
• Power everything on
• Start Icecast
• Start BUTT
• Start streaming

I will create blog posts to describe how to configure the software and a description of Windows vs Linux as a server OS for this purpose.  However, this is meant to be an overview of what we're using and how.

I also wanted to provide a list of issues we've run into so far and things to keep in mind:

• Internet connectivity is very important.  Our initial tests were on a local network with no internet connectivity and, while it worked, it did cause some issues.  Specifically, we started using TuneIn the streaming radio player and its initial setup required internet connectivity to move forward.  VLC doesn't, but you cannot assume the users will have enough data on their plan to download the software.  We now have a dedicated wireless network that does have internet connectivity
• Wireless channel selection.  Right now we are having some issues with cross-talk between the various routers in the house.  (sound tech, ours and others).  I'm hoping we can get around to assigning dedicated channels for these, but we're not there yet
• User friendliness: VLC, while a great app, isn't always the friendliest.  The iOS app will keep track of URLs you've listened to and that helps, but Android does not.  I'm hoping to eventually replace this with a dedicate app for CT, but that's a future enhancement.
• Audio Processing: Our current mixer has limited audio processing, specifically no compression.  BUTT doesn't offer any dynamics either, so we are looking at other options to allow us to compress and boost the audio a bit.  Also, don't skimp on the choice of microphone.  You could use an inexpensive computer mic, but I would think it would result in poor sounding audio and not be pleasant to the listener.  We're using a Sennheiser mic (which is probably overkill), but at least a Shure SM58.  Ideally you'd have a good plosive filter too.
• Dedicated space: one of the issues we have now is our interpreters are set up in the back of the theater.  This is for expediency sake at this point as they can see what's going on and hear the message.  There are two key downsides to this:
• The interpreters can occasionally be heard by the congregation.  To avoid this, they often have to speak more quietly than they would and that causes the volume to fluctuate for the listener.
• The listeners tend to hear the sound from the service flow into the feed we are sending.  This can be a bit distracting, especially given the lag.
• Latency: while the technology appears to work well, it does suffer from a bit of latency.  Each step of the chain adds a small time buffer to smooth out any network loss.  The configurations I use tend to reduce this, but it still adds up.  At best, we tend to see 3 second latency between when words are spoken to when they are delivered.  At worst, I've seen 10 seconds or more.  With VLC, you can simply stop and restart the stream to reduce that back down, but it's still something to keep in mind.
• Avoid Windows 10 (for now): I personally use Windows 10 and have since about the time it came out. (In fact, I'm writing this post on a Windows 10 Pro machine).  However, when I tried to use Icecast on Windows 10, something went wrong.  It worked in testing, but in production use, somehow the networking stack in Windows (be it the firewall or something) ended up killing all active connections.  It was so bad that I had to quickly restart into Linux just to continue the service.  We're currently using Windows 7 and it works just fine, so until I can figure out what happened, I'd avoid 10.
• GDPR: One thing Icecast will do is create log files.  Under GDPR you will need to make sure you handle those with care and follow your organization's privacy guidelines.  And if you don't have guidelines for compliance ... bring it up as it does matter.

At the end of the day, it's not the most perfect setup, but the price of starting up is fairly inexpensive.  Assuming you have a PC or laptop available, simply add the dedicated wireless router, mixer and microphone and you're up and running.

As we continue on, I will publish more thoughts and details.

CT Interpretation Live Links

This post provides links to the live stream only.  For more details on the whole process, see the previous post.

To listen to the live stream, tap on one of the following links:

Apple iOS or Android Link

Live Interpretation 2.1

Welcome to the Casa Taplarului live service interpretation service.  Getting connected and listening is fairly straightforward, though it does include a few steps.  This guide will try and cover both Android and iOS.  For those technically inclined, here's the brief overview:

1. Connect to the CT-Live24 or CT-Live50 access point (password: CTInterpretation)
2. Connect to the following streaming URL using a media player (like VLC or TuneIn): http://bit.ly/CTEnglish (or if that fails, you can try http://192.168.0.4:8000/live.mp3)

For those who need more step-by-step instructions, here are the steps for Android and iOS:

1. Connect to the CT-Live24 or CT-Live50 WiFi access point.  The password is CTInterpretation.  Note: you will need to do this in the cinema itself as the WiFi does not extend out into the lobby. 
2. Download VLC (or any audio streaming application you want to use).  We're recommending VLC as it is free and has proven to work well.
   
   ,
   
   
     
3. Start VLC.  On first run, there will be some introductory steps you will need to skip through.
   
   
   For iOS, you can take the tour or just tap on "Done"
   
     
   For Android, note that on the second step you can disable the "Let VLC scan my device for media content" option.
4. Open the live stream for the first time:
   
    
   For iOS, tap on the traffic cone / VLC icon in the top left and then select "Network Stream".  In the URL box at the top, enter: http://bit.ly/CTEnglish  (or if that fails, you can try http://192.168.0.4:8000/live.mp3)
   
     
   For Android, tap on the hamburger menu (three lines) in the upper left, tap on "Stream" and enter http://bit.ly/CTEnglish and tap on the arrow to the right.   (If that fails, you can try http://192.168.0.4:8000/live.mp3)
   
   Note: if the stream ends up lagging behind the service by more than about 5 seconds, you can stop and restart the stream.
5. For subsequent, future visits, you may be able to select the stream from a list of recent streams:
   
   
   For iOS, on the Network Stream page, you can simply select the CTEnglish stream from the list.
   
   For Android, you may be able to select it from the History page.

If you have any issues, you can reach out to one of the volunteers and they can direct you to someone who can help.

Google Play and the Google Play logo are trademarks of Google LLC.

Smooth Move of the Week

On Wednesday, I pulled a good one.  Alex and I were biking across town for his guitar lesson when I managed to crash my bike.  I'm sure you've heard other people's stories where they hit a car, crashed into a curb or got their tire stuck in a streetcar track.  My story's even better.  I managed to crash over the air.  I literally hit nothing.

A bit more details are in order, for sure.  While I can't be 100% certain, I think what happened was this:  while riding, I saw my neighbor's kid and wanted to say hi.  That meant I slammed on my brakes to slow down and I think I just shifted my weight forward causing the bike to stop and me to keep going.

Next thing I know I'm heading over the handlebars and thinking "this is going to be painful".  I then crashed into the ground (shoulder first), hit my head (in my helmet) on the ground and then crashed into my side.  The result was bruised ribs, road rash on my shoulder/arms/knee/foot and a serious bruise to my ego.

Fortunately I was wearing a helmet so I'm only living with painful ribs and not a concussion.  I will heal and live to bike again.  The bike also survived the encounter more or less unscathed.  The handlebars do have a bit of road rash too and I need to adjust a few things.

My only real hope now is that I heal sooner than later .. and that someone happened to get that on video.  I'd love to watch me bounce off the air like a moron.  Bonus points if they have it in slow motion.

Listening to the Live Stream

In my last post, I described how I’m trying to use streaming audio to deliver simultaneous translation of the messages at my church.  This post is meant to be a HOWTO for anyone attending and tho want to listen to the stream.

Note for this to work, you will need to be connected to the appropriate wireless network. This will be given out on Sunday morning

Android	iOS
Download TuneIn
Copy URL (or use QR code)
http://192.168.86.230:8000/live.mp3.m3u
Create Custom URL in TuneIn
Step 1: Select favorites from the hamburger menu (Android) or from the bottom set of links (iOS)
Step 2: Click "Add Custom URL"
Step 3: Enter the Custom URL into the box and touch Save on Android or touch the URL below the search box on iOS

Once you have created and saved the custom URL, each time you want to listen you can just select that Custom URL from the favorites list and it will begin streaming the audio.

Simultaneous Translation Tech Pilot

When we moved to Cluj, we started attending a local church, Casa Tamplarului.  As a church, it reminds us a lot of National Community Church in DC, which we attended before we moved here.  Of course, being the audio nerd that I am, I’ve joined the production team and now run front of house regularly.

As much as I like the church and the people there, I have one issue: the message is delivered in Romanian.  Actually, it’s not a problem with the church, but it’s really my problem as my Romanian isn’t quite as far along as I would like.  I’m learning, but I’m not there yet.

In talking with some of our friends there, the team has wanted to offer simultaneous translation of the service into English for a while.  They even started collecting some consumer-grade wireless headphones to try and use.  While we were able to make them function, they offer some limitations, so we started looking at alternatives.

What we’ve settled on as an initial trial is to use mobile phones and streaming audio as a delivery platform.  It offers a few key advantages:

• Everyone has a mobile phone, so we are not limited to hardware that the church has to provide.
• Phones are already set up to receive streaming audio, the listener just needs to download an application.
• As we move forward, it offers the option of broadcasting the audio not only locally but to the Internet at large as well.
• If we decide to add more languages, it should be just a matter of adding additional streaming endpoints to the existing tech.

For the initial pilot, we started with a completely local setup with the following components:

• One Windows laptop
• One Mac
• Google WiFi access point(s)
• An Icecast server on the Windows laptop that would offer up audio streams to as many endpoints as possible.
• Ladiocast on the Mac which would forward the audio to the Icecast server.
• TuneIn (Android, iOS) as the streaming client on each of the mobile devices.

One key thing I did was to wire up everything that was static.  Both laptops were wired into a gigabit desktop switch in order to limit the amount of traffic on the wireless network.  We also did not connect the access point to the Internet, mostly because it was an initial test, however, as I’m thinking about it now, we may not want to connect it to the internet at all, again in order to limit saturating the wireless network.

In the end, with just me connecting, the technology did work.  There is a fairly long delay of about 10-15 seconds in the audio stream.  I think this is due to the client buffering the audio.  I will continue to look into how to reduce that latency, but for now it’s workable.

We plan on trying it again this weekend with a larger audience of clients and see how it goes.  We also need to gather together some additional upstream tech (microphones, mixers, etc) in order to complete the rig.

I also plan on updating things here as we get closer to a finished solution and start learning lessons of what to do and what not to do.

Groovy: Related Languages

The Groovy language is most directly related to Java. One key design consideration for Groovy was building it to integrate directly with the Java Runtime. In fact, any valid Java code is valid Groovy code. A Groovy application can also access the Java class library and third-party libraries. Even where the languages differ, the language implements these differences in a compatible way. An example is the cross compiling of a Groovy script into a Java class.
Groovy as a language does pull from other languages, however. These language elements include:

• Ruby
• Meta programming construct where a meta object is created for key objects providing runtime extension and introspection capabilities beyond what Java offers natively
• Range type as demonstrated in the select/case statement
• Python
• list/map literal notation
• syntax for default parameters
• Smalltalk
• collection processing methods
• collect and inject naming scheme
• Functional programming
• Closures came from the world of functional programming (function pointers)

Groovy: Conclusions

Groovy is an interesting hybrid language that bridges the words of strictly-typed, object-oriented languages and dynamically-typed scripting languages.  Because it is built directly onto the JVM, it must adhere to the constructs of an object-oriented language.  However, despite this requirement, the language itself has built into it a number of abstractions that allow for the developer to utilize it as if it were a dynamically typed language.
These abstractions offer a level of power to the language that may not exist in Java itself.  These abstractions and extension include the ability to create domain specific languages and writing more compact and concise code.  It also makes learning the language easier for native Java developers than moving to Ruby or Python.
However, since these elements are grafted onto an underlying language, that can cause problems.   Following the Law of Leaky Abstractions, as coined by Joel Spolsky, there are places where a Groovy developer can encounter errors that may not make sense as they are covered by these abstractions.

class LeakyAbstraction

{

    int makeMeFail()

    {

         Random r = new Random()

         if(r.nextBoolean())

              return -1

         // Here’s a “hidden” type conversion error

    }

}

In the above example, the method makeMeFail is typed to return a primitive int.  In the case where nextBoolean returns true, this function will complete successfully as the return is a primitive integer.  However, if nextBoolean returns false, the return attempted is a NULL as Groovy will attempt to return the value of the last executed operation.  Because NULL cannot be converted to a primitive this causes a conversion exception.  This error may not make immediate sense to the developer as other scripting languages handle this more gracefully.
With that exception, the Groovy language does provide a welcome addition to the Java eco-system by providing an alternative to the strict, structured world of Java but still offering access to the full breadth of the Java ecosystem.

Groovy: Comparison to Programming Paradigms

Groovy is derived from Java and as such follows many of the object-oriented design paradigms, however its scripting nature and other elements allows it to implement elements of other programming paradigms.  This section compares Groovy to each of the key paradigms.

Imperative Programming

Unlike Java where everything is an object (with the exception of primitives), Groovy offers a scripting framework that allows for a more imperative method of programming.  A Groovy script operates as a set of variables containing data that can be acted upon via functions.  These functions perform operations and can return a result.  This result is stored can be stored in a variable in the code.
Unlike a true imperative language, like C, Groovy still maintains two key elements of object-oriented programming:

• Unlike C, a variable in Groovy can store not only a value but also a reference to an object.
• Under the covers, Groovy converts all scripts to a Java object in order to be executed by the JVM.  This conversion is transparent to the developer, but it is an abstraction that is described in greater detail in the next section.

Object-Oriented Paradigm

Groovy is an object-oriented language and follows all key OO paradigms including:

• Everything is an object
• Classes and subclasses for polymorphism
• Inheritance
• Inclusion polymorphism

As noted in the imperative paradigm section, Groovy does offer a scripting semantic that appears to implement the imperative paradigm.  However, at compilation time, the script itself is converted into a proper Java object with the globals, functions and other elements handled within the class.  Below is a sample Groovy script:

// A sample Groovy script

a = 1

def b = 2

def doSomething()

{

    def c = "Foo"

    def d = a

}

The following code example is the same script cross-compiled into Java by the Intelli-J integrated development environment.

// A cross compiled Groovy script

public class Sample extends Script {

    // Groovy-specific constructors omitted

    public static void main(String[] args) {

        new Sample(new Binding(args)).run();

    }

    public Object run() {

        setProperty("a", 1);

        Integer b = 1;

        return null;

    }

    public void doSomething() {

        String c = "Foo";

        Object d = this.getBinding().getProperty("a");

    }

}

Global variables are managed through a Bindings object which manages the scope and access within created methods.  Any functions created in the script are promoted to class-level methods.  All other elements are managed using normal object-oriented paradigms.

Concurrent Paradigm

Groovy implements elements of current programming.  The underlying processing model allows for:

• Creating and managing multiple threads to process in a parallel or interleaved fashion
• Event management
• Mutual exclusion via synchronization and atomic object classes
• Admission control via Semaphore

Functional Programming

Groovy implements elements of the functional programming paradigm through the implementation of closures.  Closures allow for defining a function as a variable and then using that function in various ways, including list processing.

Scripting

Groovy implements key elements of the scripting paradigm.  In fact, one of the primary goals when Groovy was created was to offer a scripting language like Python that targeted the Java Virtual Machine.  A developer can create a compact script of commands and variables that can be executed in an interactive fashion either via the groovy command line tool or in the Groovy shell.
It implements script-like variable binding and scope by offering script-level globals and variable definition within the script itself.  Variables are optionally typed, adding a def keyword that defines a variable as untyped.  Groovy offers the ability to scope variables and functions within packages and offers access to the underlying Java packaging system.
Data abstraction is accomplished using packages as well as through Java classes and objects.

Groovy: Language Evolution and Usage

After the initial release, the Groovy language continued to evolve and progress. Below are key features with each major release, not including pending releases.

Groovy 1.5

• Added support for key conventions added in Java 1.5, including
• Annotations - syntactic metadata added to classes and methods for use by the compiler and at runtime.
• Enumerations (enum) - named lists of pre-defined constants
• Static Imports - importing static methods from other classes into a class o Generics
• Classical for loop
• Domain Specific Language - the ability to extend the language with domain specific naming, allowing programmers to work with language and structures that are specific to their domain and have them mapped to the appropriate Groovy code
• Elvis Operator - a simple conditional of <test> ? <ifTrue> : <ifFalse>

Groovy 2.0

• Static type checking - while Groovy is an optionally typed language, version 2.0 added the ability to indicate that static type checking is required for a class
• Static compilation - added the ability to compile objects as native Java classes rather than using the meta object protocol
• Implemented additional Java 1.7 features
• Binary literals
• Underscore literals
• Multi-catch blocks
• Extension Modules
• Contributing instance and static methods (similar to adding to a JS prototype) 

Groovy 2.1

• Compile time meta-annotations
• The GPars 1.0 concurrency and threading library was included
• Definable custom base classes, allowing a programmer to select which base class to extend for a Groovy object rather than the language defined one

Groovy 2.2

• Better interaction with Java 8 lambdas

Groovy 2.3

• Official JDK 8 support
• Traits
• Template markup engine - a mechanism for formatting text output

Groovy 2.4 (current)

• Support for writing Android apps in Groovy
• Other enhancements

Usage

While the Groovy language was not targeted at a specific industry or vertical sector of the programming language market, like ADA for example, it has been embraced in web development circles, including the Grails web application development framework.  It also provides the core language for Samsung’s SmartThings home automation platform.

Groovy: Advanced Concepts: Concurrency

Groovy supports multithreaded operation, deriving its capabilities from the Java language itself.  This includes thread-based processing and concurrent processing capabilities.
In order to implement concurrency, Groovy operates on a single-process, multi-threading model.  Each process contains at least one thread and it has the ability to create multiple additional threads, each capable of performing separate work.  These threads share access to the same data, so the language implements a set of critical region and semaphore capabilities to allow for protecting access and updates to shared memory.

Control and Creation

The core language object in Java, and by extension Groovy, for managing multi-threading are java.lang.Thread and java.lang.Runnable.  The Thread object represents a single thread of execution within a Java process.  The language allows a developer to create, monitor and affect the processing of a given thread.
In order to create a thread, a class must be created that implements the Runnable interface.  This interface offers a single run method that is the developer will implement and provide the main entry point for the thread to start execution.  The developer will first create an instance of the class, then create the Thread object using the new class and finally calling the Thread.start() method to being processing.
Threads in Groovy are interruptible and include a set of exceptions that can be thrown if a sleeping or blocked thread is interrupted.  They also offer a wait for operation called join that allows a parent thread to wait for the completion of the thread processing before continuing.

class Worker implements Runnable

{

    public void run()

    {

         // Work goes here

    }

}

class Parent

{

    static void main(String[] args)

    {

         // Create the worker object

         Worker w = new Worker();

         // Create the new thread

         Thread t = new Thread(w);

         // Start the thread

         t.start();

         // Wait for the thread to complete processing

         t.join();

    }

}

Critical Regions and Semaphores

When it is necessary to make execution a section of code mutually exclusive, Groovy offers the ability to surround that code in a lock block.  Locks apply to a specific object and when a second thread attempts to access the same block as another thread, it will wait until the lock has been released.
One of the simplest methods for managing access is by marking a method as synchronized or by the synchronized(this) {} semantic.  This locks access to the entire object, giving mutually exclusive access to the object and its memory structures to the requesting thread.  All other threads are placed in wait until that section has completed processing.

public class Example

{

    synchronized void mutexMethod()

    {

         // Only one thread can execute this code

         // at a time

    }

    void method()

    {

         synchronized(this)

         {

              // This code block is mutex

         }

    }

}

The synchronized block semantic described above does not apply only to the object it is defined in, it can also apply to any other objects available within the execution scope.
In addition to the synchronized mutex described above, Groovy also offers a Semaphore class which allows for limiting access to a set of code and resources not to a single thread alone, but to a pre-defined number of threads.  It follows the baseline pattern of initialize/wait/signal.  Creating a Semaphore object defines the number of permits, the acquire methods implements wait and signal and the release methods implement the relinquish.
Groovy also implements a number of atomic objects that manage mutex access to primitive values, such as integer or floating point, and offer synchronized methods to get and increment the value of that object.

Events

Groovy implements events via the base Object’s wait and notify methods.  A given thread can call the wait method which will place that thread in a wait state until the corresponding signal is received.  This signal is set by the Object’s notify method.

// Wait code in one thread

synchronized(obj)

{

    obj.wait()

}

// Send signal code in separate object

synchronized(obj)

{
     obj.notify()

}