Issues modifying the sliceKIT Long Delay demo

Technical questions regarding the XTC tools and programming with XMOS.
User avatar
millenliam
Member++
Posts: 23
Joined: Fri Feb 14, 2014 2:51 pm

Issues modifying the sliceKIT Long Delay demo

Post by millenliam »

Hey

I'm relatively new to XMOS and I have spent the last couple of weeks trying to get my head around the Long-Delay sliceKIT Audio Demo and Long-Delay Function Library. I'm trying to modify this app and module to create a basic recirculating stereo delay instead of a multi-tap delay.

I've changed the number of taps to 2 and I'm using the first tap to get the left channel delay signal and the second tap to get the right channel delay. Rather than dealing in micro-seconds I want to use samples directly, so I'm completely ignoring the us_delays array found in the DELAY_PARAM_S struct and for now just hardcoding two delay sample values to the req_delay variable in update_common_delays() within the sdram_delay.c file:

Code: Select all

// Calculate delays in samples ...

	// Loop through all delay taps.
	for (tap_cnt = 0; tap_cnt < num_taps; tap_cnt++)
	{
		// Calculate current requested delay in samples
		//req_delay = ((S64_T)cur_param_ps->freq * (S64_T)cur_param_ps->us_delays[tap_cnt] + (S64_T)500000) / (S64_T)1000000;

		if (tap_cnt == 0)
			req_delay = 5000;
		else if (tap_cnt == 1)
			req_delay = 10000;

		// Do checks
		assert(DELAY_SAMPS > req_delay); // Check buffer is large enough
		assert(LOCAL_SAMPS <= req_delay); // Check delay is larger than multi-buffer (theoretical minimum delay)

		delay_off = req_delay - LOCAL_SAMPS; // compute delay offset to guarantee requested delay

		// Update output offset. NB Add in extra DELAY_SAMPS to prevent negative offsets.
		delay_ps->out_bufs[tap_cnt].off = (delay_ps->inp_bufs.off + (DELAY_SAMPS - delay_off)) % DELAY_SAMPS;

	} // for tap_cnt
However I when attempt to run the above code. most of the time (but strangely not always) after 1 or 2 instances of the delay I just hear a single generated tone and then all audio I/O seems to be disabled from there on. I haven't changed the DELAY_SAMPS value from the default - it should still allow for a delay buffer of around 100,000 samples, so I don't see it being a buffer size issue.

Any idea what this tone is and why it's preventing any audio I/O?

Thanks.


User avatar
millenliam
Member++
Posts: 23
Joined: Fri Feb 14, 2014 2:51 pm

Post by millenliam »

I've just discovered when I'm getting this tone and audio cut-out - when:

Code: Select all

delay_ps->out_bufs[tap_cnt].off
is being given the same value for both delay taps, most obvious when both the left and right delay samples to be the same or of a certain fraction of each other (e.g. 64000 and 48000).

Why would this be an issue though?