Closed umlaeute closed 1 year ago
For now, I'm using this in the Debian packages:
From 4004503b7ce45da4ce1ff689d464075a7f017f45 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?IOhannes=20m=20zm=C3=B6lnig?= <zmoelnig@iem.at>
Date: Wed, 18 Jan 2023 09:19:14 +0100
Subject: [PATCH] Print renderer when invoking SSR via the generic wrapper
---
data/ssr | 3 +++
1 file changed, 3 insertions(+)
diff --git a/data/ssr b/data/ssr
index 4b8c494..fbcc9ff 100755
--- a/data/ssr
+++ b/data/ssr
@@ -37,6 +37,9 @@ while [[ $1 ]]; do
shift
done
+echo "Using '${SSR_EXECUTABLE#ssr-}' SoundScape Renderer"
+echo ""
+
SSR_EXECUTABLE=$(dirname $0)/$SSR_EXECUTABLE
if [ ! -x $SSR_EXECUTABLE ]
--
2.39.0
But I think it would be nicer to add this information directly to the boilerplate.
Thanks for the report!
I have created #324, what do you think about that?
The ssr
script was only meant for backwards compatibility, I wanted to remove it at some point: #325.
This was solved by #324 and #325.
as a very casual user of
ssr
, i find it a bit confusing that it aborts on my pipewire-enabled system, butssr-vbap
does not.the underlying reason is of course that
ssr
by callsssr-binaural
by defaultssr-binaural
requires HRIR files in the correct sampleratessr
are 44.1kHzin any case, what is confusing me is that there's no information about the actual renderer when
ssr
starts up. instead i'm only greeted by big (and nice but generic) boilerplate:no mention of anything VBAP (or whatever renderer is chosen).
this is probably less a problem when i explicitly select the renderer (either with
ssr-binaural
orssr --binaural
), but with the default renderer it creates extra cognitive load.