New: Audio Service through 3.5mm Jack/Speaker Output

@ac8dg
@Abhishek
The blockage seems to happen at odd intervals. The stop at 4,721,276 frames is the longest the receiver has played audio; when I re-booted that time, it only played 287,101 frames until it locked up. I re-booted again, and early that day it hung up at 46,236. Not consistent as far as what we can see at this end. I am not seeing any other problems with the receiver other than the audio lock-ups.

Do the audio lockups impact any other part of receiver operations?

My lockups where the audio stops doesn’t lock up the rest of the outernet device that I can tell yet.

@Syed
@Abhishek
I am not seeing any other problems that would relate to the audio lock-up. I re-started this morning and am seeing 748,975 frames played so far, and continuing. It has been at unusual/not the same number of frames in each incident. I have noted 4,721,276, then 287,101, then 46,236, then 356,101 at lockup so far, each required a re-start of the receiver to continue to play. It appears that the receiver is still seeing the audio frames coming, but is not counting or playing after this occurs. Relating to @ac8dg Jim’s log above, I did note that in one log file it stated that the receiver is not compatible with f2fs-fs, however, I am not knowledgeable enough of the system to know if that is a concern relating to this situation.

I have two different types of “lock-up”. Yesterday, everything was locked, the led5 (busy) was dim, the led6 (pck1) and led10 (audio) had stopped flashing. The wifi was also not functional.

Today, I had just the audio service stop, but the radio and data was still operating and getting “data”. Just the led10 had stopped flashing. A reboot got things back to normal.

So… maybe they are two things going on causing different results. Bottom line, something happens everyday or so requiring a re-boot. not good.

@ac8dg you can debug this easily using a UPS power bank or of course a classic APC UPS
Dreamcatcher Case for Travel - #6 by kenbarbi?

Another complete lock up today. This one stopped the heatbeat, display, wifi,

It been a daily occurance that the audio stream stops, but today total lockup

Here is the only thing I can find in the system message after a re-boot

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.

–Konrad

RPi Streaming Audio Server

–Konrad

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.

–Konrad

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.

–Konrad

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:

http://georgielabs.net/

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

The Android app is called Soundwire.

–Konrad

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.

–Konrad

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.

–Konrad

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

1 Like