New: Audio Service through 3.5mm Jack/Speaker Output


I’ve recently drilled a hole through my girlfriend’s wall for the RG-6 coax. This allows me to put my DreamCatcher inside the house (at one end). My audio reception is pretty choppy although my SNR is -12 to -14 or so. I get a lot of audio segments that repeat themselves.

Second, I find the audio jack on the DreamCatcher to be very restrictive. I would love to listen to the broadcasts through streamed audio over WiFi. There’s an Android App called WiFi speaker that might be something to look at. They have a Windows-based server program. Of course an open-source streaming server could use the WiFi port on the DreamCatcher to cast the audio.



RPi Streaming Audio Server



I like this idea of streaming the audio. I wonder if the DC can really handle it. I look at my running processes and the tuner/demod typically runs at 25 to 40% cpu utilization.
A cheap RPI zero could probably accept the audio from the DC and operate as a second wifi device to do the audio streaming.
I just need to figure out what is needed at the receiving end of the signal.


We are running the Wi-Fi stack already to talk to a router or access point already. The devices on the other end for our applications are PCs, laptops, cellphones or tablets over WiFi or Ethernet.

Does the DC have enough horsepower to add the needed code? That can be determined later. In the meanwhile a slave RPi can be used as a streaming server.

So why not receive the audio stream on a PC, laptop, tablet or smart phone? Check out the Android app called “WiFi speaker” for smart phones and tablets. We should also try “Tune-In”, etc. the only real variables are the data rate, the number of channels, and the sound encoding.

Let’s get an RPi streaming server up and running and find an app or program that will work to receive the stream.



Here is my first investigation for using an RPI to get and send the audio from the DC.

How about this concept.

Capture the audio on a raspberry pi, convert and save them as one or multiple mp3’s

The above link seems to get the audio then I need to use something like
arecord -f cd -t raw | oggenc - -r | ssh ‘user’@‘remotehost’ mplayer -

to send out the file on the wifi.


Sure if you want to take audio programs and put them into files. But the idea is to be able to listen to an audio stream.

Read up about ALSA and streaming and then tell me if that changes your design a bit.



i have asked about this once aready @Konrad_Roeder because of mine lives in a spot where im usally accessing it from another location

and @Abhishek never responded with if it would be possible and how long it would take to implement


OK … let’s try this one:

There’s a server for windows, linux64, linux32 and raspberry pi

The Android app is called Soundwire.



The reason I was pursuing storing the audio into files was to hopefully eliminate the stuttering and looping of the “live” stream. Maybe this not really possible.

Maybe just post-buffering is possible?


The stuttering and looping is a problem that Othernet will need to solve. Sending liable sounding voice over an unreliable link is a real trick onto itself.

@Abhishek I have some questions regarding the stuttering and looping problem:
Is this a problem you are trying to resolve?

Are you seeing packet errors with audio that you don’t get with files? I have a dish on one of my DreamCatchers. It has literally no packet errors, yet the audio stutters and loops.

When you miss a packet, do you replay a previous one? (if so, this is where the looping comes from)
Does the software see packet errors?

How long are the audio packets?
How long is your buffer? On an audio broadcast, it’s OK to have latency.
Do you do interleaving? Since latency is not an issue…

I have more questions. I will wait.



One more idea / question I thought of… What about multiple languages on left / right. Similar to SAP on television audio channel. Or is it only mono ?


Right now, I would rather have a mono program with forward error correction rather than two audio channels that both repeat and stutter.



The audio stuttering is a priority to resolve, we just have a few other things to take care of first.


May I ask what are the “other things”? If no answer, I can understand and hang in there.


We have quite a few things in queue, most of which is behind-the-scenes work.

  • Hardware iterations
  • Antenna
  • LNB circuit
  • Enclosure
  • Private network management
  • Custom product development
  • Link testing
  • Playout server modifications


How did the Beam Type experiment work out. Are we at the optimum of 228? And what does the number mean technically?