Streaming for MOC to a shoutcast server

Submitted by vr_driver on Tue, 2018-04-10 08:02

Forums:

Hi all,
I'm just scoping out a project right now to see if it's viable or even possible, but I'm looking for a low-powered solution to be able to stream from a basic Pi (ARM) system to a web interface, and have a small amount of people stream data.

What I'd like to do (Big picture):

Play M3U playlists
Stream the files to a shoutcast (or similar) server locally run on the device
Have people connect to the server via a web interface.

Wish list:
Be able to load audio playlist on the hour (or even replace those files that are playing, and thus move on to the next playlist after the current element finishes)

The big question is, does MOC support (via some audio driver, or directly) this kind of thing?
I read that MOC is a very lite player, so I'm just looking at all options available.

Thanks in advance.
-Steve

jcf

Tue, 2018-04-10 08:33

I seem to remember reading that PulseAudio can stream to other applications (or maybe just another PulseAudio server). If you can configure shoutcast to take that feed then that might be the first requirement solved.

While MOC does not yet have a native PulseAudio sound driver (it's on the way, I promise), it can use PulseAudio via its ALSA emulation. Also, you may be able to configure ALSA to output audio to a network connection. Check what ALSA plugins are available.

(Longer term, it sounds like a network sound driver might be useful.)

As for the second requirement; you can use MOC's command line options (via cron, in your case) to clear, load or populate, and start playing a playlist. But I'm not sure if it would transition smoothly at the end of the currently playing audio file. Try it and see.

tomaszg

Tue, 2018-04-10 08:43

My suggestion to satisfying the second requirement would be rathere to use OnSongChange config option to run a script that would check if the playlist needs to be updated (i.e. the hour has changed). That would make transition smoother. However that's not very elegant solution.

I think it is another case where something like "play after the song finishes" discussed in https://moc.daper.net/node/1827 would be useful.

jcf

Tue, 2018-04-10 09:29

A script which is started by cron just before the hour which toggles AutoNext off then checks the status every second or so until playing stops and then clears and loads the new playlist before starting playing again with AutoNext toggled back on.

tomaszg

Tue, 2018-04-10 09:32

I don't see why it would be better, but there are probably as many solutions as people trying to solve it :)

jcf

Tue, 2018-04-10 10:03

There are things we don't know about the requirements.

Is there any particular reason why a playlist is required? If not, then maybe just start MOC with a large directory tree and Shuffle turned on. Alternately, just keep adding files to the queue periodicly via a script.

How long is each audio? If they are long (or if you wish minimise CPU cycles), then you may want to determine a more accurate duration to wait between status checks by subtracting current seconds from total seconds.

How are we doing, "vr_driver"? Is any of this sounding applicable to your particular scenario?

vr_driver

Tue, 2018-04-10 13:13

Gosh, this place is much more active than I imagined!
Thanks for the suggestions everyone!

Yes, the application, is to see if I can get a radio station sound, with many m3u playlist files that hour-long and pre-compiled. These files have songs and station IDs pre-programmed in them, as well as long form talking programs scheduled for various times of the day. Therefore, given these requirements, a shuffle feature wouldn't really be an option in this case.

So, the idea would be, is to have the files already scheduled, and then get the new hour to start playing, close to the top of the hour, and forfeit any extra songs that may exist in the hour.

Long term, I'm considering writing my own scheduler, so the station can just continue "forever"...

I had played with some pi stuff in the past and had it playing out of the PI radio broadcast program (and transmitting on pin 4). Probably pushing it a little too hard at times, but I think the device I have this time has much smaller resources available to it, so I can't run X, emulate MSWindows, or do anything super fancy, hence why I started looking around for a bit of a native solution. This looks rather good on the surface, and to be able to control it as a daemon, I'm a little stoked. :D

vr_driver

Tue, 2018-04-10 13:51

Just on all this, I've found the command list (it would be helpful if that was in the wiki on the site)...
Does clearing a playlist stop play, or does it do a Winamp, and keep playing the current file, and then follow on to the rest of the playlist?

jcf

Tue, 2018-04-10 21:31

Okay, I tried loading playlist and starting it playing then cleared the playlist and loaded another:

mocp -a p1.m3u -p
mocp -c -a p2.m3u

The audio playing at the time the playlist was cleared continued playing until the end and the first audio of the new playlist then started playing. I hadn't tried that before, but the result is a seemless transition from one playlist to the next.

Then I tried clearing the playlist and reloading the first one again:

mocp -c -a p1.m3u

This time the result was that the currently playing audio continued to play to the end and then playing stopped. That was unexpected and will need to be investigated further as both cases should behave the same way.

A further test which reloaded the same playlist:

bin/mocp -c -a p3.m3u -p
bin/mocp -c -a p3.m3u

also stopped at the end of the current audio but did not transition to the newly reloaded playlist (which would have replayed the first audio in the playlist).

So, if we can sort out that problem then the solution becomes quite straight forward; just clear the current playlist and load a new one every hour.

vr_driver

Wed, 2018-04-11 07:38

Yes, that may be the solution... I'll take a better look. Thanks. :)