It is a reasonable thing to ask. Both jobs are "audio on a schedule", both want a music library, both want a jingle every so often, and nobody wants to buy and maintain two machines to do what sounds like one thing.
The answer is half yes, and the half that is no is worth understanding before you buy anything.
More than you would think. A scheduled music rotation with separation rules, a jingle or ident that fires every so many tracks, dayparting so the afternoon sounds different from the morning, a now-playing display, and a log of what went out - a radio station needs all of that, and so does a shop, a school or a leisure centre that plays music all day. Multilarm does all of it on one small machine, offline, with no subscription.
A radio station's whole point is that people who are not in the building can listen. That means encoding the output to a lossy codec - Opus, Vorbis, AAC, MP3 - and pushing it to a streaming server that fans it out to the public internet.
Multilarm does not do that, and does not pretend to. Its audio engine encodes WAV and FLAC only. There is no Icecast source client, no HLS, and no relay to a remote server. What it has instead is a listen endpoint on your own network: uncompressed audio, roughly 1.5 Mbit/s per listener, up to thirty-two of them, which is fine across a building's own switch and wholly unsuitable across the internet.
So: one box for the building, comfortably. One box for the building and public internet listeners, no.
Quite a lot, and all of it at once:
That is a genuinely capable building station. It is just a building station.
Use a product built for it. LibreTime and AzuraCast are both mature, both free, and both do the thing Multilarm deliberately does not. Neither of them, though, will ring a bell through a relay, watch a GPIO emergency button, or duck the music for an announcement in one zone of a site - so the common arrangement is not "one box instead of the other", it is one box for the building and a separate one for the stream, fed from the same music folder.
Because it is not a small change and the reasons against it are not going away. A lossy encoder has to be vendored into the audio engine and cross-built for five platforms, including a 32-bit ARM one that is hand-compiled. The obvious MP3 encoders are LGPL, which is against how this software is licensed, and the AAC ones carry patent terms. And a streaming path that fails badly is a very different risk on a machine whose actual job is to make the fire announcement work.
It may be built one day. It is not built now, and you should not buy anything on the basis that it might be.
Can Multilarm push audio to Icecast or SHOUTcast?
No. The audio engine encodes WAV and FLAC only, so there is no lossy encoder to feed a streaming server with. There is no Icecast source client and no HLS output.
Can people outside the building listen at all?
Not to a live stream. What you can share is listen-again: scheduled recordings are playable in a browser and can be published as an ordinary podcast feed, which covers the common case of somebody who missed an assembly or a talk.
How many people can listen on the local network?
Up to thirty-two, on three bandwidth tiers - the full mix, a mono stream at half the bandwidth, and a low-bandwidth one at a quarter. It refuses to open itself to the network without a listen key.
Can one machine do the bells and the music without them fighting?
Yes. That is the ordinary arrangement. Music runs underneath, a bell or an announcement takes priority, and an emergency takes priority over everything - the rotation only decides what plays when nothing more important is happening.
Would running both on one Raspberry Pi be too much?
For the building side, no - a Pi 400 handles a music rotation, bells, announcements and LAN listeners comfortably. The question does not arise for streaming, because that half is not supported.