Hacker News new | past | comments | ask | show | jobs | submit login
Make an internet radio station with one line of bash (schollz.com)
153 points by qrv3w 4 days ago | hide | past | favorite | 46 comments

This is really cool. I have a little node.js script I wrote that generates a funky little beat I call "egypt.js"[0] and outputs the PCM data to stdout, just for weird things like this.

My local WSL1 install of ffmpeg has an issue with the LAME encoder so using a few extra pipes I was able to get this working! Confirmed with a friend they were able to listen across the planet.

    node /tmp/egypt.js | ffmpeg -f f64le -ar 176400 -i pipe: -f wav - | lame - - | curl -s -k -H "Transfer-Encoding: chunked" -X POST -T - "https://broadcast.schollz.com/egypt.mp3?stream=true&advertise=true"

Neat stuff! I love things like this.

[0] https://gist.github.com/Qix-/7c131c6eb83bef7c44ef6faaf1eab10...

Coincidentally today is the anniversary of the first public radio broadcast in 1910.


Fascinating. I recall two other interesting uses of ffmpeg: to stream to twitch[1], and to record video[2].

[1] https://stackoverflow.com/questions/54273291/streaming-a-str...

[2] https://www.youtube.com/watch?v=HO6oU5oT6uU

There's a lot of FFmpeg streaming info here:


I think the dissenting / mocking comments here are missing the spirit of the post.

Since bash can evoke any Turing complete program, feasibly anything could be done with one line of bash.

The authors intent as I saw was to show what that line was. Would you have known without this article?

Whether or not people are just being sarcastic, I feel we should definitely not mock but rather encourage any open and free attempts at teaching us cool things that are more novel than the “how to get started on Linux” type bs the market is inundated with.

Bravo to author.

"To solve this problem I wrote a simple server that runs in the cloud which can handle any number of realtime broadcasts uploaded using a simple curl command. This allows you to essentially broadcast radio feeds with a single line. My solution to the problem of broadcasting audio without port-forwarding was to create a free and public “dummy” server that handles any incoming traffic and forwards to any number of connected clients. This server keeps track of connected clients and routes incoming packets to them, otherwise discarding the packets."

If the author had perhaps titled their post "I wrote a multiplexing server for audio streams" it might go over better, although that doesn't have the proper click-bait appeal.

I think the spirit of the post got overrun by (likely accidentally) making the title so clickbaity.

Bash can run any program, that's why you don't advertise running a program with it in your title unless the program is (at least mostly) in bash which is an interesting constraint to go check out. There are some really whacky crazy interesting things done in actual bash scripting including internet applications like this via bash's builtin /dev/tcp functionality... come to think of it this might actually be one of those crazy "I did it in pure bash"able things.

I'm sure most on HN knew you could pipe the output of a media application like ffmpeg into something like curl instead of locally. All of the exact options and methodology used here off the top of their head? Very unlikely but is that really what this title sets the expectation of?

I don't think mocking is the best recourse but I'm not sure it's much more useful to argue the author should only be receiving blind encouragement in cases like this either. Like I said I highly doubt the author had any malice when changing the title for HN but I also understand why many don't want to blindly encourage posts where the title can be so misleading/confusing.

Ironically "Creating my own free and easy to use internet radio station host" would probably have gotten even more attention with almost never of the pushback and the project work on norns is probably worth its own post.

The one line didn't even "Make an internet radio statio" it just uploaded streaming audio to a web site.

If the network is down...Carry on. The music can't stop.

"System Bus Radio" https://github.com/fulldecent/system-bus-radio

I mean, you could probably launch nuclear missiles with a line of bash

  sudo ./launch-missiles.sh --target=[REDACTED] --missile-count=4 --username=jbiden --password=1111

I like how you redacted the target but not the password – though I’m pretty sure the real password is alphanumeric and based on a family member: http://www.bash.org/?quote=244321

One of the actual big-P Passwords decades ago was actually


> during the height of the Cold War, the US military put such an emphasis on a rapid response to an attack on American soil, that to minimize any foreseeable delay in launching a nuclear missile, for nearly two decades they intentionally set the launch codes at every silo in the US to 8 zeroes


...so, a quasi-implicit-and-optional parameter.

Wow! From an InfoSec perspective, that’s hard to believe but when you understand that every large group of humans has competing interests and large bureaucracies don’t have perfect chains of command, it’s totally believable. I guess it’s a high-stakes example of the difficulty in getting the right balance between security and convenience.

Edit: on a related note, a few years ago I was shocked to hear the story of how a simple accident while carrying out routine maintenance of liquid-fuelled nuclear missiles almost resulted in a devastating nuclear explosion in the American heartland: https://www.thisamericanlife.org/634/human-error-in-volatile...

That was what I was paying homage to.

   -j 4

Pretty sure that would be a Perl script.

I love that Biden's putting his password into ~/.bash_history

It's also visible in the process table (ps auxww). It can be erased by rewriting the arguments from inside the process (I think this is OS-specific, not the same as changing argv in-place), but that is a race condition.

The safe way is to either read it from stdin/fd (maybe call isatty(3) to check if someone doesn't echo password | ./foo), or open a file (check if permissions are 600). You could also have a named socket (check permissions!) talking to an authn agent, which could be doing some other fancy stuff like pinging your smartwatch to confirm, etc.

another option is in an env variable (from an encrypted file).

    gpg -d ~/secrets/nuclear_launch_codes.gpg
    source ~/secrets/nuclear_launch_codes
where the gpg key has a password and is stored on a hardware dongle that doesn't allow copying the private key off. If you really want to be fancy, there are some hardware security keys that also require a biometric to confirm.

The other option is something like Hasicorp Vault, but we're way out of "one line bash" territory :p

can't you do `cat /proc/$PID/environ`?

It's chmod 400'd and owned by process owner.

> It can be erased by rewriting the arguments from inside the process

Please nobody rely on this behavior. :O

Spacex launches rockets with one line of bash

Next post of this type is "execute any arbitrary binary with one line of bash"

This article isn't very useful for a "one liner radio", but I use icecast2 in a couple of ways

1. I host a VGM radio [1] 2. I use a combination of icecast2 and darkice to have a full home audio networking.

With the home audio network, there's a lot to optimize, but I haven't implemented it much more to experiment with it further.

Basically I have a Ubuntu Desktop VM on my home server. A long range bluetooth receiver [2] is feed from Proxmox host into the VM. The audio from the Bluetooth source (say your phone or your computer) is pulled from Darkice and renders an MP3 file/stream into Icecast2, which then broadcasts it on I can use devices like Raspberry Pis to continuously listen on that URL for playback and play if it's available. There's CLI audio players like mpg123.

This could be used for whole home audio playback, but there's weird quirks to deal with like the delay between the audio in and when you hear it, as well as it becoming desynced over time.

It can also be setup in reverse where a RPi ingests audio from it's audio jack and sends it to the audio hub VM and the audio hub sends it out to the network.

[1] https://vidya.fm [2] https://www.amazon.com/gp/product/B07KTK8YP3/

> weird quirks to deal with like the delay between the audio in and when you hear it, as well as it becoming desynced over time.

You may want to check out Snapcast. I use it to distribute audio to 6 clients on diverse hardware (several Raspberry Pis, a Windows PC, a Linux PC) and it handles synchronized playback very well, after tweaking the latency offsets for each device (once).


(Edit: Ok, Snapcast doesn't get rid of the delay. But it does keep the players in sync, if you can tolerate some delay between source and speakers.)

Title is misleading at best.

Does anyone have experience with https://www.liquidsoap.info/ for simple radio stations? Is it any good?

Yes, I highly recommend it. You can express your broadcast in a nice functional DSL. We are running a community radio and use it there in production for couple of years now.[0] (Ours linked is a very suboptimal solution but performs w/o any hiccup even though we got some pretty specific constraints.) We could've gotten many more mileage out of it, if we really would have had the time to focus on creating libs and functions for our specific needs as the API is really powerful, the docs are a good read. Also, on a more subjective note: It's developed by nice guys and even if some built-ins fail from time-to-time since there's no real rush to update we can help test w/ them & give some input on features.

[0] https://github.com/mmmnmnm/lahmacun/blob/master/azuracast/li...

I did something similar so I could listen to my vinyl records over an in home ip radio station on my Sonos without buying their $500 box that lets you add arbitrary audio input.

Nobody has problems with dropped TCP connections when streaming?

Tried icecast2 on several servers at distinct hosters and audio tag on various browsers and platforms, in maybe tens of minutes it always seized up. I had to add script to client page had to detect it and reconnect, the pauses were annoying, gave up.

Did not dig deeper seems as if routers drop the connection when there are no data transmitted in one direction.

Record the mic to a remote server:

    ffmpeg -nostdin -f alsa -i pulse -c:a libmp3lame -ar 44100 -b:a 128k -ac 1 -f mp3 - | ssh -C vps "cat - > /var/www/output-$(date '+%s').mp3"

For osx:

  ffmpeg -f avfoundation -i ":1"

Doesn't an icecast server already do what broadcast-server does? You post an audio stream to it and it relays that to clients. What am I missing?

That using TCP for streaming is insane. UDP only, in this context called RTP.

I don't see why latency matters here.

The examples use "broadcast.schollz.com" as a service. How do I do it on a local network?

Do whatever in one line: 1) Open a source code with Sublime 2) Ctrl+J to join the lines 3) Enjoy

That's 3 lines of "bash." Not one.

Browse the Internet with one line of Bash:

  firefox https://news.ycombinator.com
But seriously, the commands in the article are not Bash commands (they don't even use Bashisms) and are valid in any POSIX-compliant shell.

The original title of the article is:

> Your own internet radio station in one line

OP here.

The original title did include the word "bash" (it was the one and only instance of the word "bash"). I removed this word from the main article because including the word "bash" superseded a conversation that was nominally about internet broadcasting. Maybe the title of this HN submission can be changed too.

I appreciate the commenters that picked up on the main theme of article and shared some interesting links! But I did enjoy the humorous comments too (who doesn't enjoy some good-natured bashing (pun-intended)).

If I write a complex piece of software that does something even marginally interesting, I'm going to post it to HN with a similar title. After all, I'm sure I can execute it with one line of bash, so the title is appropriate, right?

Did you read the article? It's probably the most honest version of "one line of bash" given how prolific ffmpeg is, and the fact that, beyond one line of shell commands, I was able to listen to the streamed audio in my browser.

What more do you want? It works, quite literally, as advertised.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact