Image for post
Image for post

Low Budget, Open Source, Wireless DJ / Dance Instructor Live-stream Video Broadcasting System.

End to end wireless dancing DJ internet broadcast solution including physical and software components.


Recently, I had cause to set up a simple live-stream video broadcast system to share some love of Salsa music and Dance. This was to enable broadcasting my own daily dance exercise activities at home with live commentary, in such a way that others might join in.

That is to compensate a little for the absence of physical Salsa dance classes during the current Pandemic, not only for myself, but also for others missing Salsa Dance classes and socials.

It involves some demonstration and lighthearted discussion of relevant Cuban and Afro-Caribbean Dance Music, Culture, and Associated Dance Styling and techniques per my recent experiences in Cuba.

It requires me to have complete mobility with some form of hands-free headset, to be able to commentate and instruct verbally on good quality musical audio, perceived by an audience or other participants.

Music picked up by a cheap microphone in an average room just doesn’t cut it, compared with authentic studio mastered original artist music, as is achieved using a DJ broadcasting application.

I believe this is necessary to capture and express some of the emotion and feelings of the music, in the dance, for it have any chance of being somehow “Infectious” to others.

Time will tell!

The task of achieving an acceptable technical broadcast solution, on a shoe-string, turned out to be far more challenging than expected, even to me as an accomplished systems Engineer. My hat is off to broadcast Engineers.

So I believe the information detailing the solution I arrived at could also be of value to others; professional dance teachers or otherwise, wishing to do something similar.

I can see this rig being popular in places where fancy hardware such as wireless gaming headsets might be hard to obtain, like Cuba.

As said, the problem could possibly have been solved by use of a wireless gaming headset. But I don’t have one of those, and don’t want to have to buy one in addition to the expensive Bose “Hands-free” bluetooth headset which I already found does not work in this role, no matter how hard I tried to make it do.


This documentation has dual purpose.

As well as providing the information needed by anyone to reconstruct the system, the document also stands as a simple illustration of some of the basic techniques of Formal Systems Design, which I might refer to in other documents later, as an example.

The header diagram is the System Formal Use Case.


Latency (Or lag), simplified, is a time measurement of how long it takes for data to be received, after it is sent.

The latency of capturing and playing audio is different from the latency of capturing and playing video.

For livestreaming, some care has to be taken to ensure audio is correctly synchronised in the video streaming output.

In the case of someone just speaking, such as a broadcaster or commentator, or an actor in a performance, we are usually focused on the lip movements of the speaker, compared with what we hear. In that case we are quite tolerant to fairly large differences, up to large fractions of a second.

In the case of dancing, we are not focused on the commentators lips at all, but more on the timing of the dancer’s body movements relative to the music. In this case, even an error of 100ms (A tenth of a second), can be noticeable. Footfalls which happen consistently on the wrong percussion beats in a musical track, for example, can convince experienced dancers that the instructor is incorrect, or worse; can teach newcomers incorrect movements.

By incorrect movements, I mean movements which would prevent two dancers, perhaps taught by different instructors, engaging with one another in synchronised partnered or group movements.

I believe confusing instruction can scare newcomers away from attempting to learn new dance completely, especially when it leads to embarrassment.

I remember this from being a confused newcomer myself, so it is something I really try to avoid.

Further, the dancer must be connected wirelessly, with no wires to trip over, wrap around body in turns, or pull out of connections.

System Requirements

Image for post
Image for post

The main system requirements are shown in the diagram above.

These could have been further elaborated to give a comprehensive system specification. But in this case, the relatively small system under design did not merit that level of work, and was most pragmatically designed in my head.

The Systems Engineering techniques and artefacts seen here were used only as an aid to create this documentation after the system was implemented.

However, those artefacts now stand as the formal system UML design.

Image for post
Image for post
Main System Diagram

System Description

The above diagram shows all of the system components and how they are integrated, meeting the system requirements.

The headset is attached to the Raspberry Pi via USB connection.

The raspberry Pi connects to my home Wifi network via its built-in Wifi connection. It has installed on it, Mixxx, an open source DJ application.

Mixxx is configured to connect the headset mic with the Mixxx mic input, and the Mixxx main output to the headset speakers.

Mixxx is further configured to output a Icecast ingress broadcast music stream, mixed with voice from headset mic, to the WiFi network.

Also installed on the Pi is a VNC server, enabling remote desktop access via the WiFi network.

This enables me to control Mixxx, so as to schedule tracks and control volume levels etc from my PC, which has the VNC client installed.

The PC further has installed an Icecast server, which decodes the music stream received via Wifi from the Pi, and sends an internet radio type stream on to the PC “localhost” loopback network address. This in a form which can be readily opened by a browser (Firefox), which plays the music on the PC sound system.

A VLC client on the PC is opened when Firefox is used to access the server address (localhost). This is what actually does the conversion of the stream into analog sound on the PC soundcard.

Further installed on the PC is a scrcpy client, which mirrors the screen of my android telephone via USB connection to the PC desktop. The phone is physically fixed in position to act as my main camera, pointed at me during the broadcasting session. I use a car windscreen phone grip, stuck to the glass of a window to mount the phone physically in place.

The mobile phone camera produces far better, higher quality, faster footage, in varying light conditions, than is possible from the camera on my laptop.

The final application installed on the PC which is used is OBS (Open Broadcasting System). This is an open source desktop internet broadcasting application. I use it to broadcast the PC desktop, with the sound from the PC soundcard to the Dlive ingress servers, authenticated by my Dlive account streaming key.

A significant delay (Around 4300 ms in my case) needs to be added to the OBS visual processing, in order to delay it as needed to synchronise the desktop video footage with the sound received from the Pi, via the PC sound system. This is added by a series of render delay filters in OBS, eight of 500ms, and one of 300ms (Each delay filter has a max setting of 500ms).

I chose Dlive rather than Youtube, as from experience, Youtube automatically deletes the soundtrack of streams detected to contain known DMCA copyrighted music tracks (Virtually all!), whereas Dlive does not, enabling us to broadcast copyrighted music within the terms of DMCA fair use clauses.

The specific fair use clauses I mean are the ones allowing live reviews of musical tracks, and live dance instruction using those tracks.

System Physical Components

USB Gaming Headset

The headset I’ve used is an old Corsair H1500, bought around 5 years ago for around $50 from the now defunct and sadly missed (In UK) Maplin. It has a boom microphone which swivels down on the left-hand ear-cup.

Image for post
Image for post

I believe these are out of production and stock now, but any basic USB headset should work just the same.

Raspberry Pi

The Raspberry Pi that I’ve used is a Pi 3 B model, like that shown below.

Image for post
Image for post

This runs at less than 50% of max power, whilst supplying reliable performance for the duration of my online dance sessions (1 to 2 hours).

The Pi has to be used with a case, so as to be easily attached to the body of the live-streaming dancer.

My Pi Case has to be ventilated, and mounted vertically on legs extending about 3cm from the body, to ensure adequate airflow to keep the Pi running at reasonable operating temperature during a constant processing load of around 50%.

I created the legs / belt receptacle from two a pieces of wire coat-hanger, fixed together as cross, bent into a convenient criss-cross shape, with the ends fixed in mount-holes on the case.

I printed my own case using a 3D printing facility which I am lucky enough to have, based on an open source case mechanical design, downloaded from Thingiverse.

My encased Pi fitted with mounting legs, as used is shown in the picture below.

Image for post
Image for post

Most folk might not have 3D capability. So a suitable case might need to be purchased from a supplier.

A reasonable low cost example of one I guess would do fine, is in the picture below. Typical price of this case is around $10.

Image for post
Image for post

Care should be taken to ensure the case is appropriate for the model of Pi used. There are some small differences in PCB layout between models, which sometimes makes a difference to the fit of the case. I would also advise against a metal case, or cases with internal fans, as these will be much heavier than a simple ventilated plastic case (And more expensive), so would be more prone to wobbling with body movements.

As said, the pi runs at around 50% load, which I’ve found is manageable by a plastic case with reasonable ventilation. My case has no heatsinks.

USB Stick

Image for post
Image for post

The USB stick I’ve used is a 16G Toshiba item like that in the image above.

I did at first try a much larger, heavier, USB3 metal-bodied Corsair 64G stick before that, but found that its high mass caused it to wobble a little, with clothing and cables etc catching its high profile in the USB receptacle it occupied in The raspberry Pi, when the Pi was strapped to my waist, and I was dancing with connected headphones on. Now and then, pops and cracks would be heard when data was lost. I believe this was due to the high mass stick rattling in the USB connection, and becoming intermittent.

Also, the USB3 Corsair stick had higher than needed power consumption, unnecessarily reducing the runtime of the Pi and battery combination.

The lower specification USB2 protocol of the Toshiba stick I found to be more than adequate for this application, extending the battery life of the Pi a little, and its low mass induces no rattle, even in vigorous routines.

The stick is only accessed very occasionally by the Pi.

I have around 850 tracks, occupying around 50% of the available 16GB capacity of the Toshiba stick, so there is still plenty capacity left to add more as I come across them.


The battery used is an SKROSS Reload 3. This is small enough to sit comfortably in a pocket, whilst still having enough power to keep the Pi running for a few hours, adequate for my broadcasting sessions.

The standard lead for the battery did not provide enough voltage to the Pi. I was getting low voltage warnings on the Pi with that, and had to change the lead for a much thicker, shorter blackberry phone charger USB lead, which presumably has much less electrical resistance, thus less voltage drop. This seems to work fine.

Image for post
Image for post


The PC used is a Windows 10 laptop. Any standard Windows 10 laptop should be easily capable of doing the same tasks, so I won’t go into too much details about the hardware of that.

…And that is about it.

I might come back to this story at a later date to add more details, to describe the configurations of all components in detail, but it is a lot of work, and right now, I have today’s broadcast to prepare for. With some research, there should already be enough here for anyone wishing to replicate the rig.

Let me know anyone, if you would like more details, or assistance, and I will endeavour to help.

Meantime, if you are curious to see the system in operation, you can see me live-streaming with it every day at 8pm GMT, until further notice at:

Update 17/05/2020:

I gave up broadcasting every day, it was taking too much time away from other things I’ve been working on, and to be honest, it has not generated any apparent interest.

It seems I am alone in my appreciation of salsa, or maybe it is because I seem to be pretty much shadow-banned, on several fronts. Hey-ho.

I still broadcast occasionally, as detailed now at the link.

Addendum: A word of caution in using this system

It occurs to me that use of a personal mobile phone for this application could present a security vulnerability. Specifically, in the case of an active phone used as the second factor in a two-factor (“2FA”) security scheme, there is a possibility that if the phone number is known by a potential attacker watching a broadcaster using their personal mobile phone as above, the phone could receive an authentication code, sent to the phone in response to a request from the attacker, requesting access to some known protected facility of the broadcaster, then seeing the authentication code sent in near real time appearing in a momentary message alert which could appear on the screen of the phone used in the broadcast, and then used by the attacker to fraudulently gain access to an account of the broadcaster.

To avoid this, it is advised to ensure that the phone used in a broadcast is completely removed from any possibility of itself communicating with either the internet, or telephone network.

Thus it is recommended to ensure that any active phone used, is used only in flight mode, which switches off all network access, during the broadcast. The phone will still operate then as needed via the USB connection to the computer, but will prevent the possibility of other parties communicating with the phone during the broadcast.

One of these days, I will do a story on the folly of 2FA, how it is actually a false instrument, not intended to improve our security at all, what it actually does is provide attackers with a second attack face, whilst giving our phone number to the organisations insisting on it, so that they can sell this on to others, who pay for lists of active phone numbers for direct marketing.


Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store