Network Code

35 views
Skip to first unread message

Paul Dunn

unread,
Jan 15, 2015, 7:53:48 AM1/15/15
to lightsh...@googlegroups.com
As you guys work on the refactoring and cleaning up, I still have networking code to integrate.
If you care to take a look at what I've got so far
https://bitbucket.org/PaulDunn/lightshowpi/branch/dev3

there were a couple issues that Chris pointed out that I have yet to correct. (as Todd said, just a question of finding time to do so)

also would appreciate if others could help me test the code some more

thanks!
Paul

Micah Wedemeyer

unread,
Jan 15, 2015, 12:51:22 PM1/15/15
to lightsh...@googlegroups.com
It would be nice if we could approach this code you're adding from a stream perspective. Like, if we could somehow envision this as a stream of audio and lightshow data, just like the current FFT analysis does. So, using my branch as an example, I have an FftAnalyzer object that takes an audio stream as input and generates a tuple of (audio data, light matrix, mean, std) as output.

Your slave setup here could be refactored to have basically that same output, correct? I guess it would not return the audio data, but it's close. Perhaps we could just use empty strings to indicate null audio data. Something like that.

Anyways, the point is that we could have a very simple play_song() that does something like this:

audioAnalyzer = None
if config.slaveMode():
  audioAnalyzer = NetSlave(options_for_netslave)
else:
  audioAnalyzer = FftAnalyzer(options_for_fft)

while audioAnalyzer.has_more_to_analyze():
  play_lights_and_music(audioAnalyzer.analyze(data))

So, instead of having to hack play_song() to bits for each new way of inputting audio or analyzing it, instead each new piece just has to match the interface of the other pieces and then we can drop it in.

Here's a link to my branch where I've encapsulated the FFT analysis as FftAnalyzer:

Specifically, here's the FftAnalyzer:

And here's where I create a worker that accepts an FftAnalyzer and uses it to analyze the audio stream:

If we could agree on an interface for Analyzers (right now, I'm just assuming it has an analyze(data) function that takes a chunk of audio data) then we could make all of this stuff much more pluggable for new pieces.

Does this make sense?

Micah

Tom Enos

unread,
Jan 17, 2015, 2:42:16 AM1/17/15
to lightsh...@googlegroups.com
I wish I had a second Pi.  Your code has a lot of ideas that look so interesting and make me just thing of what is happening.  Simply, yet does so much.  

Tom Enos

unread,
Jan 18, 2015, 2:27:24 AM1/18/15
to lightsh...@googlegroups.com
After giving the code a good looking at I have a few question. (I wish I had a second pi for testing, I like this)

1. If I am reading this right, the slave is a mirror of the master, correct?     
2. What if any lag time is there to the slave?    
3. Should line 365 "s.bind(('',0))"  have a 0 for the port? I thought you needed to bind it to _PORT, or is that only for listening and not broadcasting?    
4. More a statement then a question, but....., couldn't you move the socket setup statements and the variable streaming from play_song() to just after you set _NETMODE and _PORT, removing the need to use the global statements for s and streaming?
Not an issue just a thought.
5. Strait connection with cat-5 right?  I wonder if we could get it working over wifi?  It's not a whole lot of data we're sending. But there might be a lot of lag over wifi.    

Like I said before this code is simple, but it does so much.  I need another pi.

Wait I'm using linux, I have a few extra cat-5 cables around, and a second nic.  Maybe I can help test this out!!!!

On Thursday, January 15, 2015 at 4:53:48 AM UTC-8, Paul Dunn wrote:

Micah Wedemeyer

unread,
Jan 18, 2015, 9:46:07 AM1/18/15
to lightsh...@googlegroups.com
Very interesting stuff. A few things that I'm unclear on:
  • How many slaves do you expect? Is it 1 master, 1 slave? The broadcast option seems to support any number of slaves, which is really interesting.
  • This is a raw mirroring setup, right? Every slave mirrors the same show, as opposed to using slaves to handle different pieces of the show (ie. Slave 1 gets lights 1-10, Slave 2 gets 11-20, etc.)
  • Is someone else playing the audio? Is that the master?
  • Are you concerned at all about timing drift? Like, if a slave stutters or has an issue, is it behind forever at that point?
Overall, it looks very cool.

Micah

On Thursday, 15 January 2015 07:53:48 UTC-5, Paul Dunn wrote:

Micah Wedemeyer

unread,
Jan 18, 2015, 9:47:36 AM1/18/15
to lightsh...@googlegroups.com
Sorry, I didn't read Tom's questions closely enough. Several of mine are copies of his (mirroring and lag/drift).

I'll be interested to see the answers.
Micah

Paul Dunn

unread,
Jan 18, 2015, 9:53:42 AM1/18/15
to lightsh...@googlegroups.com
Tom:

yes, the slave is going to mirror the master as far as just straight channels, you can still change things around, mirror 8 channels into 4 etc.
lag is going to just depend on your network, when I would first ping one of the PI, the first ping would be 100ms but then each subsequent was only something like 2-5ms. but this would depend on each individual network.
for that bind, uhhhh.. it works as-is, so you might be right, I just slapped it together to get it working based on online docs for python broadcast.

I could probably move those statements around, but was trying to avoid creating those objects if they weren't needed. There were also a couple errors about
those globals that Chris pointed out that I just haven't fixed yet.
wireshark analysis showed me about 1kbps so, no, it's not much data at all.

To test streaming, you can write a python prog to just read the channel data off the network and then print it out. I have one for the slave pi that I originally wrote as play.py, really cut-down and simple, you could take that and then just remove the hardwarecontroller portion

I also have a C# "spectrum display" that uses colored bar-graphs to display what gets streamed, but.. GASP! it's for MS Winders ;-)

cheers!

Tom Enos

unread,
Jan 18, 2015, 5:07:51 PM1/18/15
to lightsh...@googlegroups.com
Thanks that clears things up some.  I'm going to play with it from my desktop and see what happens. 

C# is Mono, Mono is C#, (for the most part) so it's not windows only :), plus there is wine.

Todd Giles

unread,
Jan 23, 2015, 4:54:01 PM1/23/15
to lightsh...@googlegroups.com
Paul - finally got around to looking at this, great stuff!  Loving all the ideas out there ... just need to find time to play with them all ;)

Tom Enos

unread,
Jan 29, 2015, 12:56:52 AM1/29/15
to lightsh...@googlegroups.com
I was able to do some playing with this.  I expanded the virtual mode into a gui for desktop use, then added in your code.  Set my desktop as the server and the pi as the client and it worked great, and it works over wifi too (no mods).  The only things i did was to to fix the error with the globals and added a little bit to turn off all the lights if the show is interrupted (stopped early on the server).
Running multiple copies on my desktop it's a perfect mirror of the server, over wifi there is little lag on occasion, but that looks like it is do to network load.  And it resyncs as soon as the network catches up.

  


On Thursday, January 15, 2015 at 4:53:48 AM UTC-8, Paul Dunn wrote:
Reply all
Reply to author
Forward
0 new messages