FAQ & Terms of UseFAQ & Terms Of Use   Wiggler RadioMW Radio   Muff Wiggler TwitterTwitter   Support the site @ PatreonPatreon 
 SearchSearch   RegisterSign up   Log inLog in 

Disting bug: I-5 audio playback glitches at zero speed
MUFF WIGGLER Forum Index -> Expert Sleepers  
Author Disting bug: I-5 audio playback glitches at zero speed
Firmware version: v4.10 (and all previous ones I've tried)
Algorithm: I-5 Audio Playback with Reverse

I find that if the Z speed value is at zero (or crosses zero, hard to say since it's an analog input), there is a glitch in the output: instead of continuing to follow (or rather, freezing) the audio sample, the A and B outputs rapidly jump between zero and the sample's value.

I've tested this with a 1-cycle 500 Hz sine/cosine sample at 44.1k sample rate, and the same but with 500 cycles (1 second) length; the length doesn't seem to matter.

Also, while this is happening, the brightness of the Disting's display flickers. Perhaps there's a CPU overload problem when switching between forward and reverse playback? Maybe this could be fixed by ensuring the DAC retains the previous output is while the CPU is busy (so the speed would not be strictly accurate but there would be no glitch)?

Or if, whatever the problem, it turns out to be hard to just fix, maybe there could be a new "wavetable" mode that works only with samples short enough to permanently load into RAM?

Either way, then Disting could be used as a through-zero wavetable quadrature VCO/LFO that's well-behaved around the zero (something that from what I've read is hard to find anywhere).
I'll look into it.
Could you try this version?
os wrote:
Could you try this version?

That changed the artifacts; they used to be triangle-wave-shaped and now they're square-wave-shaped at the same rate but smaller. Like this (new on top, standard 4.10 on bottom):

The ramps are about 4 ms long. This is an AC-coupled recording; by comparing to what my DC-coupled in-rack scope shows, on the bottom the flat spots are zero and the triangle peaks follow the sample data, and on the top the wide side is the sample data and the narrow side is zero. So, the new version seems like it gives longer periods of good output, but not quite long enough to hit 100%. And of course the square shape makes the artifacts much more audible.

Let me know if any other data would be useful. I do have a "real" oscilloscope I can pull out if needed. And I'd be happy to use a different sample format or length if it can make this low-frequency quadrature use case work. Thanks!
Hmm - that worked for me. Do you have any options set in a playlist file that might be conflicting?
I don't have any playlist files. I've attached the WAV file in case it is of interest (I generated it with Audacity).

I tried deleting the generated reversed copies: no effect. I tried using a 10-cycle wav file instead of 1 cycle: the period of the glitches seems to scale with the length of the file a little bit.

Could the performance of the SD card matter? This is a Kingston microSDHC 16 GB class C4. I don't have any ones of a different type/brand handy to test with; I'll put that on my shopping list.

I also noticed a completely unrelated glitch: playing my 500-cycle (1 second) file in reverse glitches when it loops, but plays fine forward. Since that doesn't seem to affect shorter files, I don't immediately care. I think both the standard 4.10 and this variant do that.
I picked up a new microSD card: SanDisk Extreme PLUS (SDXC, U3, A2) 64 GB. The glitches to zero are still present under some speed inputs and sample lengths (can't quite nail down what), but are overally nearly gone. I'd guess that the "worked for me" is due to a difference in the card speed or similar.

However, I notice low amplitude square-wave-shaped glitches in the output. I don't know if this is actually what is going on but a theory that would be consistent with what I'm seeing is that as it is busy reversing, the clock is still advancing so that when it gets back to outputting samples it starts there rather than resuming from where it paused, producing a jump in the output.

So, seems like this could be fixed by ensuring that it's fully "paused" while it's busy accessing the card (as I mentioned for a different reason before, this would conceptually mess with the speed, but in practice doesn't matter because the Z input has noise anyway), or by avoiding the hiccups entirely somehow (as I mentioned before, clever buffering or maybe an entirely-in-memory implementation for short samples). But of course you know the code and I don't, so this is random speculation.

Thanks for the improvement!
Here's a new one which (for me) addresses both of those issues (glitches to zero and low-amplitude square artefacts).
Updated to that firmware and I don't see the forward-back jitter, but the jump to zero artifacts are still present intermittently if I get the frequency close to zero. They seem to come and go for some reason.

Also, I'm noticing another oddity: if the speed is set very low but not zero, then the speed varies with position in the file (the slowly moving dot on my XY scope gets visibly faster and slower). If I speed it up and slow it down again, then which part is slowed down changes. Also, the jump-to-zero glitches happen here some of the time (and the display flickers) even though it should be consistently playing in one direction.

Here's a quick recording of the glitch when it's near zero. Unfortunately the AC coupling still makes it hard to see what's going on; I'll see if I have anything I can use to do better later. Maybe take a video of the Disting and scope.
MUFF WIGGLER Forum Index -> Expert Sleepers  
Page 1 of 1
Powered by phpBB © phpBB Group