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
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.
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.
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.
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))
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.
The ScreamRouter is optional IMHO and it seems to be a lot of python anyway which is not nice for packaging.
The ESP32-S3 senders/receivers are appealing, but do not impact OpenWRT. For testing I ordered two PCB-As.
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.
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.
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