Mix 96K ADC and 192K DAC

Baloran

Active member
Hello ;)
For my project, which you may already know about:
https://baloran.com/store/blog/project-pool

As part of a possible upgrade, I'm coming up against a small problem. I've tested audio streams at 192K (on PCM5122). I seem to be seeing a gain in quality in certain contexts and the Teensy 4.1 supports this very well in terms of CPU.

I also use a CS5343 (works fine with AudioInputI2S2) as a slave for the ADC . It's not a fundamental function, but it's nice all the same: it converts the output of the hardwares VCOs to provide a digital copy of the signal that can be used for RING MODULATOR, PHASE and FREQUENCY MODULATION. Do you think it's possible to run the CS5343 at 96K, even if it means filling the acquisition buffer with two identical samples, while the rest of the chain is at 192K (AUDIO_SAMPLE_RATE_EXACT 192000.0f)?
I've looked at the audio lib sources in detail, I don't feel competent enough to do that ;)

I should point out that at 96000.0f the sound is excellent but at 192000.0f , I'm pushing back aliasing, for example on a WAVEFORM_PULSE oscillator, if I modulate the signal's duty cycle. Using WAVEFORM_BANDLIMIT_PULSE would be an ideal solution but modulating the duty cycle generates crackling, and I haven't managed to "correct" this.

Congratulations again to Paul and the team for the incredible tools that are now available to us.
 
About the pulse duty cycle,

as far as i see the code, the duty cycle is updated at block rate.

Maybe if the blocks are big and the duty cycle changes too fast it may cause these glitches.
 
as far as i see the code, the duty cycle is updated at block rate.
Maybe if the blocks are big and the duty cycle changes too fast it may cause these glitches.

Thanks, I imagined the same source of problems and so I modified the loop

Code:
	case WAVEFORM_BANDLIMIT_PULSE:
	
		for (i=0; i < AUDIO_BLOCK_SAMPLES; i++)
		{
		    if ( target_width != pulse_width )
                    {
                        .....
                    }	
                    .... 
		    ph = new_ph ;
		}
so that the pulse_width increment here is very smooth. Nothing to do, still the same problem, cracking that seems random. I can imagine the problem in generate_pulse + new_step_check_pulse, inserting the steps for the bandlimit doesn't like the modulation.
 
Problem solved for pulse_width after updating the BandLimitedWaveform class with the Gitub version of the audio library....
process_active_steps_pulse did not exist in the version I was using.

The moral is that it would be wise for me to do a complete update of the audio library and re-import my modifications.
 
Back
Top