On 28/05/17 21:30, Georg Chini wrote: > On 23.05.2017 03:44, Steven Wawryk wrote: >> Sorry about reposting. I botched up the subject line, messing up the >> threading. >> >>>>>> I've been reading up and experimenting on both the simple and async >>>>>> APIs. In one experiment, I used a CLI file that sets up a set of >>>>>> module-sine modules with output remapped by module-remap-sink modules >>>>>> to a stream fed to a module-null-sink module. >>> Could you please include the command sequence you are using? Maybe I can >>> reproduce the problem here. >> I've attached the CLI file and the shell script I use to run it. The >> sequence is: >> >> ./restart-pulse.sh dist/data/sine-2x6.pa >> parec --device="test_sink0.monitor" --format=ulaw --rate=8000 >> --channels=6 --channel-map="aux0,aux1,aux2,aux3,aux4,aux5" parec0.raw >> >> Wait 10 seconds, then in another terminal: >> >> pactl unload-module module-remap-sink # or pactl unload-module >> module-sine >> >> Wait another 10 seconds, then kill parec with ctrl-c. I then look at >> parec0.raw by importing it in audacity (u-law, 6channels, 8000 smp/sec). > I tested it here. To me it looks like a bug that occurs because of > re-winding and using > a monitor source, but I can't put my finger on it yet. > With your setup, you are running with 2 seconds latency, which is > probably not what > you intend. Add --latency-msec=10 or similar to your parec command. This > should > mostly hide the bug. Thanks, Georg. I set the latency to 10msec as you said and the length of the transitional signal flipping has dropped to less than 200msec.
