ScreamRouter, any experience?

Did anyone try out ScreamRouter for OpenWRT?

It might be a lightweight alternative to Owntone, forked-daapd and shairport-sync.

There are even senders and receivers for Windows, ESP32-S3 with USB-DAC support etc. So, all in all an interesting project IMHO

Are there Openwrt binaries available?

Not that i am aware of, hence i am asking if just no one stumbled across it or if the project is bad in some regard. To me it looks impressive, but just from reading things about it so far

But when asked about available binaries:

So, are you asking for it to be available?

Or are you saying it already exists?

1 Like

It is a python module, good point to start would be to make manylinux-musl wheel on alpine linux aarch64 or x86-64 and try to get that running on OpenWrt.

No, musl package is not “available” https://pypi.org/project/screamrouter/#description without reasonable effort on your side.

1 Like

it should be possible

root@OpenWrt:~# scream -h
Usage: scream [-u] [-p <port>] [-i <iface>] [-g <group>]
         All command line options are optional. Default is to use
         multicast with group address 239.255.77.77, port 4010.
         -u                        : Use unicast instead of multicast.
         -p <port>                 : Use <port> instead of default port 4010.
                                     Applies to both multicast
and unicast.
         -i <iface>                : Use local interface <iface>. Either the IP
                                     or the interface name can
be specified. In
                                     multicast mode, uses this
interface for IGMP.
                                     In unicast, binds to this
interface only.
         -g <group>                : Multicast group address. Multicast mode only.
         -m <ivshmem device path>  : Use shared memory device.
         -P                        : Use libpcap to sniff the packets.
         -o pulse|alsa|jack|raw    : Send audio to PulseAudio,
ALSA, Jack or stdout.
         -d <device>               : ALSA device name. 'default' if not specified.
         -s <sink name>            : Pulseaudio sink name.
         -n <stream name>          : Pulseaudio stream name/description.
         -n <client name>          : JACK client name.
         -t <latency>              : Target latency in milliseconds. Defaults to 50ms.
                                     Only relevant for PulseAudio and ALSA output.
         -l <latency>              : Max latency in milliseconds. Defaults to 200ms.
                                     Only relevant for PulseAudio output.
         -v                        : Be verbose.
root@OpenWrt:~# ldd /usr/bin/scream
        /lib/ld-musl-aarch64.so.1 (0x7f860f0000)
        libpulse-simple.so.0 => /usr/lib/libpulse-simple.so.0 (0x7f860cf000)
        libpulse.so.0 => /usr/lib/libpulse.so.0 (0x7f8606e000)
        libasound.so.2 => /usr/lib/libasound.so.2 (0x7f85f6d000)
        libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x7f85f3c000)
        libc.so => /lib/ld-musl-aarch64.so.1 (0x7f860f0000)
        libpulsecommon-17.0.so => /usr/lib/pulseaudio/libpulsecommon-17.0.so (0x7f85eab000)
        libdbus-1.so.3 => /usr/lib/libdbus-1.so.3 (0x7f85e4a000)
        libsndfile.so.1 => /usr/lib/libsndfile.so.1 (0x7f85dc7000)
        libmpg123.so.0 => /usr/lib/libmpg123.so.0 (0x7f85d76000)
        libmp3lame.so.0 => /usr/lib/libmp3lame.so.0 (0x7f85cf9000)
root@OpenWrt:~#
2 Likes

Was it involving alpine or you got a package makefile?

I made it myself. Alpine and OpenWrt are different, so they shouldn't be compared. Alpine doesn't have a Makefile, but it does have an APK.

Alpine has musl, thats the most importent, you can unpack their apk or install whl and get eg java on raspberry.

That's a dirty and disgusting method. Have the OpenWRT developers given up on cross-compilation in OpenWRT? They should think about or create a way to make cross-compilation in OpenWRT easier. If there's no other way, perhaps the one you mentioned is a temporary option for now.

GL cross comping a package on a 128 MB flash device.

The "they" here is the person staring back at you from the mirror..

2 Likes

Just a suggestion to OP how to get POC testing package in 10 minutes…

include $(TOPDIR)/rules.mk

PKG_NAME:=scream
PKG_VERSION:=4.0
PKG_RELEASE:=1

PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.gz
PKG_SOURCE_URL:=https://github.com/duncanthrax/scream/archive/$(PKG_VERSION)
PKG_HASH:=skip

PKG_MAINTAINER:=
PKG_LICENSE:=MS-PL
PKG_LICENSE_FILES:=LICENSE

CMAKE_BINARY_SUBDIR := build
CMAKE_SOURCE_SUBDIR:= Receivers/unix

include $(INCLUDE_DIR)/package.mk
include $(INCLUDE_DIR)/cmake.mk

define Package/scream
	SECTION:=libs
	CATEGORY:=Libraries
	TITLE:=Virtual network sound card for Microsoft Windows
	DEPENDS:=+alsa-lib +pulseaudio-daemon-avahi
	URL:=https://github.com/duncanthrax/scream
endef

define Package/scream/description
	Scream is a virtual device driver for Windows that provides a discrete sound device. Audio played through this device is published on your local network as a PCM multicast stream.
endef

TARGET_LDFLAGS += -Wl,-rpath-link=$(STAGING_DIR)/usr/lib/pulseaudio

define Package/scream/install
	$(INSTALL_DIR) \
	  $(1)/usr/bin

	$(CP) \
	  $(PKG_INSTALL_DIR)/usr/bin/scream \
	  $(1)/usr/bin/
endef

$(eval $(call BuildPackage,scream))
1 Like

Hey, thanks for all the feedback. I was at the stage of just being curious if this a known software and perhaps not useful as it does not seem to be popular. So my question was basically just before investing more time into it. You already advanced the topic, so thanks for that!! There is now a lot to try out.

@predators_46 knows it…. i’d vote for flavoured package without alsa/pulse for those real routers without any chance for sound card….

Just some thoughts:

I see at least these typical use-cases:

Would make sense to support those use cases then. What is the usecase of a receiver without audio-output?

The transfer is PCM, that will be quite some bandwidth. That needs to be tested if the realtime bandwidth requirement is causing glitches when using the Wifi with other users as well.

Question was about stream server called scream router…. Little to do with either end of stream

Sure, that one is mainly a python package and does not need the output/input to real DACs. It is basically a nice mixer/selection of what streams to where. I think you refer to the title which is misleading indeed, but just using the name “scream” would be too misleading as well - so please be not to irritated by that detail - I meant the whole project/protocol and the several sub-projects.

For DAC-output I want to try @predators_46 Makefile, that should permit finding out if it works on a WiFi router with all the contraints (RAM, CPU, Bandwidth, Flashsize, …). So far my two shairplay-sync outputs are tplink_tl-wr810n-v1 and aerohive_hiveap-121. Especially the wr810n is now at its limit due to the full ffmpeg in 24.0.x eating too much flashspace. That’s the motivation from my side to look around for alternatives, plus the ESP32-S3 options they offer make me curious.

python has a lot of dependencies

1 Like

It takes some time to compile…

https://downloads.openwrt.org/releases/24.10.3/targets/x86/generic/openwrt-sdk-24.10.3-x86-generic_gcc-13.3.0_musl.Linux-x86_64.tar.zst
tar xvf openwrt-sdk-24.10.3-x86-generic_gcc-13.3.0_musl.Linux-x86_64.tar.zst
cd openwrt-sdk-24.10.3-x86-generic_gcc-13.3.0_musl.Linux-x86_64/
./scripts/feeds update -a
./scripts/feeds install -a
#./scripts/feeds install ScreamReceiver
make menuconfig # --> disable global building settings --> Cryptographically sign package lists
make V=s