Bug#1035387: csound: Regression from Bullseye: K opcodes not initialized at init time
Package: csound Version: 1:6.18.1+dfsg-1 Tags: fixed-upstream, upstream See https://github.com/csound/csound/issues/1707 I'd like to NMU a fix once things settle down on the upstream side and I'd like to file an unblock request (or a stable update request if this misses the bookworm release). I'm not a member of the multimedia team, but I am familiar with the csound packaging. Are you okay with me doing an NMU and submitting a merge request on salsa once we settle on a fix on the upstream github issue? You can declare an opcode something like opcode inittest,K,0 According o the docs, the output parameter is copied both at k-time and at i-time. It turns out in csound 6.14 (bullseye) it's always copied at i-time even if declared as 'k' not 'K'. But that in 6.18 it's only copied as k-time. If you are using the opcode as a state machine, triggering reinits, etc, that can totally break your orchestra.
Bug#924260: NMUDIFF for csound 1:6.12.2~dfsg-3.1
Dear maintainer, I've uploaded the following patch to csound to
delayed/2. Rationale for the short delay: we've already discussed the
change and you've reviewed my merge request, and the release team
requested that I upload in a timely manner.
diff --git a/debian/changelog b/debian/changelog
index 84a4831..72a6859 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+csound (1:6.12.2~dfsg-3.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Fix diskgrain, syncgrain and syncloop when sample rate of sample
+differs from orchestra, Closes: #924260
+
+ -- Sam Hartman Thu, 21 Mar 2019 10:31:29 -0400
+
csound (1:6.12.2~dfsg-3) unstable; urgency=medium
* Fix FTBFS on mips by avoiding a deadlock
diff --git
a/debian/patches/applied-diskgrain-fix-to-syncgrain-andsyncloop.patch
b/debian/patches/applied-diskgrain-fix-to-syncgrain-andsyncloop.patch
new file mode 100644
index 000..d5f3033
--- /dev/null
+++ b/debian/patches/applied-diskgrain-fix-to-syncgrain-andsyncloop.patch
@@ -0,0 +1,58 @@
+From: veplaini
+Date: Mon, 11 Mar 2019 09:11:40 +
+Subject: applied diskgrain fix to syncgrain andsyncloop
+
+---
+ Opcodes/syncgrain.c | 11 ++-
+ 1 file changed, 6 insertions(+), 5 deletions(-)
+
+diff --git a/Opcodes/syncgrain.c b/Opcodes/syncgrain.c
+index cb0b2bd..1dc1973 100644
+--- a/Opcodes/syncgrain.c
b/Opcodes/syncgrain.c
+@@ -96,15 +96,16 @@ static int32_t syncgrain_process(CSOUND *csound, syncgrain
*p)
+ int32_t numstreams = p->numstreams, olaps = p->olaps;
+ int32_t count = p->count, j, newstream;
+ int32_t datasize = p->datasize, envtablesize = p->envtablesize;
++MYFLT pscale = p->sfunc->gen01args.sample_rate/CS_ESR;
+
+-pitch = *p->pitch * p->sfunc->gen01args.sample_rate/CS_ESR;
++pitch = *p->pitch * pscale;
+ fperiod = FABS(p->sfunc->gen01args.sample_rate/(*p->fr));
+ //if (UNLIKELY(fperiod < 0)) fperiod = -fperiod;
+ amp =*p->amp;
+ grsize = p->sfunc->gen01args.sample_rate * *p->grsize;
+ if (UNLIKELY(grsize<1)) goto err1;
+ envincr = envtablesize/grsize;
+-prate = *p->prate;
++prate = *p->prate * pscale;
+
+ if (UNLIKELY(offset)) memset(output, '\0', offset*sizeof(MYFLT));
+ if (UNLIKELY(early)) {
+@@ -249,7 +250,7 @@ static int32_t syncgrainloop_process(CSOUND *csound,
syncgrainloop *p)
+ int32_t loopsize;
+ int32_t firsttime = p->firsttime;
+ MYFLT sr = p->sfunc->gen01args.sample_rate;
+-
++MYFLT pscale = sr/CS_ESR;
+ /* loop points & checks */
+ loop_start = (int32_t) (*p->loop_start*sr);
+ loop_end = (int32_t) (*p->loop_end*sr);
+@@ -260,7 +261,7 @@ static int32_t syncgrainloop_process(CSOUND *csound,
syncgrainloop *p)
+ /*csound->Message(csound, "st:%d, end:%d, loopsize=%d\n",
+ loop_start, loop_end, loopsize); */
+
+-pitch = *p->pitch * sr/CS_ESR;;
++pitch = *p->pitch * pscale;
+ fperiod = FABS(sr/(*p->fr));
+ //if (UNLIKELY(fperiod < 0)) fperiod = -fperiod;
+ amp =*p->amp;
+@@ -268,7 +269,7 @@ static int32_t syncgrainloop_process(CSOUND *csound,
syncgrainloop *p)
+ if (UNLIKELY(grsize<1)) goto err1;
+ if (loopsize <= 0) loopsize = grsize;
+ envincr = envtablesize/grsize;
+-prate = *p->prate;
++prate = *p->prate * pscale;
+
+ if (UNLIKELY(offset)) memset(output, '\0', offset*sizeof(MYFLT));
+ if (UNLIKELY(early)) {
diff --git a/debian/patches/diskgrain-prate-scaling.patch
b/debian/patches/diskgrain-prate-scaling.patch
new file mode 100644
index 000..9f21a6e
--- /dev/null
+++ b/debian/patches/diskgrain-prate-scaling.patch
@@ -0,0 +1,30 @@
+From: veplaini
+Date: Sat, 9 Mar 2019 14:03:22 +
+Subject: diskgrain prate scaling
+
+---
+ Opcodes/syncgrain.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/Opcodes/syncgrain.c b/Opcodes/syncgrain.c
+index d7c461e..cb0b2bd 100644
+--- a/Opcodes/syncgrain.c
b/Opcodes/syncgrain.c
+@@ -455,7 +455,7 @@ static int32_t filegrain_init(CSOUND *csound, filegrain *p)
+ p->pscale = p->sr/CS_ESR;
+
+ if (*p->ioff >= 0)
+- sf_seek(p->sf,*p->ioff * CS_ESR, SEEK_SET);
++ sf_seek(p->sf,*p->ioff * p->sr, SEEK_SET);
+
+ if (LIKELY(sf_read_MYFLT(p->sf,buffer,p->dataframes*p->nChannels/2) !=
0)) {
+ p->read1 = 1;
+@@ -518,7 +518,7 @@ static int32_t filegrain_process(CSOUND *csound, filegrain
*p)
+ if (UNLIKELY(grsize<1)) goto err1;
+ if (grsize > hdataframes) grsize = hdataframes;
+ envincr = envtablesize/grsize;
+-prate = *p->prate;
++prate = *p->prate * p->pscale;
+
+ if (UNLIKELY(offset)) memset(output, '\0', offset*sizeof(MYFLT));
+ if (UNLIKELY(early)) {
diff --git a/debian/patches/series b/debian/patches/series
index
Bug#924260: Csound: regression in diskgrain stretch->buster when file sr != orchestra sr
package: csound severity: important justification: Stretch regression with no work around without code changes version: 1:6.12.2~dfsg-3 tags: patch, fixed-upstream, upstream Hi. In https://github.com/csound/csound/issues/1119 I reported an issue. In stretch, if you want to deal with a file that doesn't match the orchestra sample rate in diskgrain, you have to do all the work in your orchestra. Between stretch and buster upstream tried to improve it but got a couple of things wrong: * Most seriously, they handle the initial file seek according to the orchestra sr not the file sr. So there will be a jump of uncontrollable length when the first file buffer is exausted. * They scale the pitch but not the pointer read rate, so the orchestra still has to know about the gap. This is fixed in f23c45efcef upstream. I confirmed that code change works against the upstream code base and the Debian code base. I'd like to try and get an unblock to get this into buster. I want your support obviously before trying to do that. I'm happy to do everything (prepare a package; upload; file an unblock), simply write the unblock justification, sit back and let you deal, or accept that you don't think this is worth trying to get an unblock for. My justification for the unblock is that it's a well-constrained change, something that is possible in stretch is entirely impossible in the current buster code, and there is an easy fix. --Sam signature.asc Description: PGP signature
Bug#916066: csound regression: zir opcode appears entirely broken; hangs instrument
package: csound version: 1:6.12.2~dfsg-1 I was experiencing strange failures with orchestras with csound 6.12 and eventually I've tracked it down to the zir opcode to read a value from zk-space at i-time. It's fairly basic: the zir.csd from the csound examples fails to print out anything in the instrument that runs zir. Based on what I've seen the instrument hangs (or aborts without a note aborted message). This is bad because it doesn't look like there's any way to read a zk-value at I time without that opcode. I guess you could play reinit games, but ugh. Interestingly, Debian doesn't seem to be shipping zir.csd or really most of the examples. We used to, as I got them somewhere, and they're really useful. I'm not seeing any license problems, so it would be cool if we either shipped them or documented why not. Anyway for completeness I'm attaching zir.csd. This works on stretch. ; Select audio/midi flags here according to platform ; Audio out Audio in -odac -iadc;;;RT audio I/O ; For Non-realtime ouput leave only the line below: ; -o zir.wav -W ;;; for file output any platform ; Initialize the global variables. sr = 44100 kr = 4410 ksmps = 10 nchnls = 1 ; Initialize the ZAK space. ; Create 1 a-rate variable and 1 k-rate variable. zakinit 1, 1 ; Instrument #1 -- a simple instrument. instr 1 ; Set the zk variable #1 to 32.594. ziw 32.594, 1 endin ; Instrument #2 -- prints out zk variable #1. instr 2 ; Read the zk variable #1 at i-rate. i1 zir 1 ; Print out the value of zk variable #1. print i1 endin ; Play Instrument #1 for one second. i 1 0 1 ; Play Instrument #2 for one second. i 2 0 1 e
Bug#916047: csound: regression in String handling
package: csound version: 1:6.12.2~dfsg-1 severity: important justification: Regression over stretch with insidious and hard-to-diagnose consequences I noticed that my orchestras were failing on several sound files after upgrading to buster, and tracked it down to some cases of filenames being input in the score file. Consider the following orchestra and score: Orchestra: 0dbfs=1 sr=44100 nchnls=4 instr 1, 10 Sfile strget p4 amic = 0 a1, a2 diskin Sfile, 0.997, -2.3 vincr amic, a1 outq amic, amic, amic, amic endin Score: i 10.000244140625 10.135534524917603 -1 "/home/hartmans/.cache/djcli/Bobina - Music Box (Album Mix).wav" 1 1.0 10.135534524917603 0.0 422.2395255249176 1.0 0 50 1.0 f0 20.0 Stretch Behavior: (csound 6.08) 0dBFS level = 1.0 orch now loaded audio buffered in 256 sample-frame blocks ALSA output: total buffer size: 1024, period size: 256 writing 1024 sample blks of 64-bit floats to dac SECTION 1: B 0.000 .. 10.136 T 10.136 TT 10.136 M: 0.0 0.0 0.0 0.0 new alloc for instr 10: WARNING: instr 10 uses 4 p-fields but is given 13 diskin2: opened '/home/hartmans/.cache/djcli/Bobina - Music Box (Album Mix).wav': 48000 Hz, 2 channel(s), 19778664 sample frames B 10.136 .. 20.000 T 20.000 TT 20.000 M: 0.87332 0.87332 0.87332 0.87332 Score finished in csoundPerform(). inactive allocs returned to freespace end of score. overall amps: 0.87332 0.87332 0.87332 0.87332 overall samples out of range:0000 0 errors in performance Elapsed time at end of performance: real: 19.972s, CPU: 0.963s 3446 1024 sample blks of 64-bit floats written to dac hartmans@mount-peerless:djutils(6)> Buster behavior: 0dBFS level = 1.0 orch now loaded audio buffered in 256 sample-frame blocks ALSA output: total buffer size: 1024, period size: 256 writing 1024 sample blks of 64-bit floats to dac SECTION 1: WARNING: Buffer underrun in real-time audio output B 0.000 .. 10.136 T 10.136 TT 10.136 M: 0.0 0.0 0.0 0.0 new alloc for instr 10: WARNING: instr 10 uses 4 p-fields but is given 13 INIT ERROR in instr 10 line 7: diskin2: /home/hartmans/.cache/djcli/Bobina - Music Box (AlbumMix).wav: failed to open file (No Error.) from file test.orc (1) a1 a2 diskin Sfile 0.997 -2.2998224 0 0 0 0 0 0 B 10.136 - note deleted. i10 had 1 init errors B 10.136 .. 20.000 T 20.000 TT 20.000 M: 0.0 0.0 0.0 0.0 Score finished in csoundPerform(). inactive allocs returned to freespace end of score. overall amps: 0.0 0.0 0.0 0.0 overall samples out of range:0000 1 errors in performance Elapsed time at end of performance: real: 20.006s, CPU: 0.901s 3446 1024 sample blks of 64-bit floats written to dac hartmans@mount-peerless:djutils(7)> Somehow in the buster code path, The space between Album and Mix has been removed and the filename has become corrupted. Note that the buster code path works fine if you hard code the sound file name in the instrument. It's something to do with the score file that is problematic. I apologize that the score is a bit complex; it's obviously extracted From some more complex code. My typical orchestra is quite complex and I wanted to get things down to an debuggable minimal example, but I also wanted to use the production score file. I'm also attaching the score as a mime attachment because it is a rather long line. score Description: Binary data signature.asc Description: PGP signature
