Budget Standalone "Toslink > DSP > Toslink" with Camilladsp. Set up instructions for newbies.

[melomane13]

Just recieved the U24 XL. Got it running on a windows laptop for now.

However the only way I can see to loopback the input signal to the output is to check the setting "listen to this device" in the windows recording audio device settings, which adds noticeable latency.

Do I need additional software like something from VB-Audio to route the signal via ASIO for the lowest latency? If so, is this also a problem I will run into on linux when eventually migrating to a Pi?

i not see particulary latency with RPI4 .

 

[mattzildjian]

Rather frustrating that the U24 XL offers direct monitoring of the analog inputs but not the digital inputs, so to monitor the digital inputs you have to go through the windows "listen to this device" setting which always adds latency. Maybe linux just has a better way of looping back audio?

 

[melomane13]

@mattzildjian , linux is free. so you can install on double boot on pc , when install camilladsp and try with alsa.

 

[mattzildjian]

@mattzildjian , linux is free. so you can install on double boot on pc , when install camilladsp and try with alsa.

Yeah I could do this, maybe make a live boot usb.

There has to be a way in windows though.
I am finding all sorts of applications / drivers that may work.
SAR / SynchronousAudioRouter
ASIO Link Pro
Voicemeeter
R3LAY VPB Virtual Patch Bay

Anyone familiar with these? I just want the digital input to route back to the speaker output with as little latency as possible.
Thanks.

EDIT: Could this function within EqualiserAPO work?

Equalizer APO / Documentation Wiki / Configuration reference

sourceforge.net

EDIT2: Solved it using Voicemeeter, it allows low latency monitoring of input devices via ASIO which the U24 XL officially supports.

EDIT3: Another issue, getting audio dropouts every 20 minutes or so. It's a similar sounding drop out that the CM6206 card was doing, though that was doing it constantly. The problem might be with my laptop and not the card perhaps. Not sure how to troubleshoot this.

EDIT4: Switched the input type from WASAPI to MME on voicemeeter and not had a dropout for 30mins, so hoping that solved it though I'm not holding my breath. I am able to set the asio buffer size as low as 32 samples and not have any glitching, which is quite remarkable. There is zero perceivable latency. Can linux do that? Tested for a further 30 mins or so without drop outs so seems good right now. I can turn the TV speakers on in combination with the DSP'd optical signal and they are practically bang on top of each other, the latency is so minimal all I hear is a little bit of phasing between them. Wondering now if windows is actually a best solution because of asio support.

 

[mdsimon2]

It is unclear to me if the U24 XL has independent analog and TOSLINK outputs, it looks to me like they might be mirrored. I just purchased a used U24 XL on e-bay so can report back when I receive it.

I received the U24XL and unfortunately it has seems to have some buffer management issues with CamillaDSP when used as a TOSLINK I/O device.

If you use the silence_threshold / silence_timeout functionality to pause CamillaDSP when there is no input, the buffer level drops significantly and for the first few seconds after a restart there will be drop outs. You can avoid this by deleting the silence_threshold / silence_timout entries in your configuration so that CamillaDSP never pauses.

Next issue I observed is that while playing the buffer level just keeps increasing. This is odd because as far as I can tell the input and output are clocked sync'd, so not sure what is going on here. I tried to solve this by using async resampling and rate adjust but the behavior seems a bit erratic and at 1024 chunk size / target level I still ran in to some issues. Probably need to use a pretty big chunk size / target level and a lower adjust period.

It seems to retain clock settings / volume levels in alsamixer after a restart which is nice.

Overall given the buffer management issues I don't think the U24XL is a good option.

Michael

 

[mattzildjian]

I received the U24XL and unfortunately it has seems to have some buffer management issues with CamillaDSP when used as a TOSLINK I/O device.

If you use the silence_threshold / silence_timeout functionality to pause CamillaDSP when there is no input, the buffer level drops significantly and for the first few seconds after a restart there will be drop outs. You can avoid this by deleting the silence_threshold / silence_timout entries in your configuration so that CamillaDSP never pauses.

Next issue I observed is that while playing the buffer level just keeps increasing. This is odd because as far as I can tell the input and output are clocked sync'd, so not sure what is going on here. I tried to solve this by using async resampling and rate adjust but the behavior seems a bit erratic and at 1024 chunk size / target level I still ran in to some issues. Probably need to use a pretty big chunk size / target level and a lower adjust period.

It seems to retain clock settings / volume levels in alsamixer after a restart which is nice.

Overall given the buffer management issues I don't think the U24XL is a good option.

Michael

well, this doesnt bode well for me.. I was planning to switch to RPi + CamillaDSP setup with the U24XL soon. Dang.

 

[mdsimon2]

Next issue I observed is that while playing the buffer level just keeps increasing. This is odd because as far as I can tell the input and output are clocked sync'd, so not sure what is going on here. I tried to solve this by using async resampling and rate adjust but the behavior seems a bit erratic and at 1024 chunk size / target level I still ran in to some issues. Probably need to use a pretty big chunk size / target level and a lower adjust period.

Slight follow up to this.

I learned today that CamillaDSP V2 uses a buffer equal to 4 x chunk size, previously it was 2 x chunk size. This means target level should be double of what you used in V1. I haven't tried the U24XL again, but I bet if I use a lower chunk size (say 512) with a higher target level (like 1023) the buffer will be much more stable. CamillaDSP still limits the target level to less than 2 x chunk size (which is why I said target level of 1023 not 1024), but future updates will remove this limit.

More discussion can be found here -> https://www.diyaudio.com/community/...overs-room-correction-etc.349818/post-7673239.

Michael

 

[MCH]

Chunksize... so useful to adjust latency or reduce drop outs. If I only knew what on earth it means

 

[mdsimon2]

Chunksize... so useful to adjust latency or reduce drop outs. If I only knew what on earth it means

Every time I think I understand it I get more confused.

My latest learning is that target level seems to impact buffer level even when rate adjust is not enabled!

Definitely something I need to play around with to understand more. I think I now get that it seems more important that target level is larger than chunk size (ideally 3 x chunk size, but currently can only do 2 x chunk size - 1) than it is to have an absolutely large chunk size.

Michael

 

[HenrikEnquist]

Chunksize... so useful to adjust latency or reduce drop outs. If I only knew what on earth it means

Chunksize is the number of frames that camilladsp processes at a time. The capture thread reads this number of frames of audio data from the capture device, and then sends this chunk of data to the processing pipeline as a packet. Then it starts reading again to make the next chunk.
This way the pipeline gets to process a fixed size chunk of audio at a time. This makes things much more efficient than processing single frames (and is required to do fast convolution via FFT).

My latest learning is that target level seems to impact buffer level even when rate adjust is not enabled!

Yes there is an initial delay when processing starts that tries to time the starts of the capture and playback devices to get close to the target level. Unfortunately every device behaves a bit differently on startup so this sometimes ends up quite far off.

 

[mdsimon2]

Chunksize is the number of frames that camilladsp processes at a time. The capture thread reads this number of frames of audio data from the capture device, and then sends this chunk of data to the processing pipeline as a packet. Then it starts reading again to make the next chunk.
This way the pipeline gets to process a fixed size chunk of audio at a time. This makes things much more efficient than processing single frames (and is required to do fast convolution via FFT).



Yes there is an initial delay when processing starts that tries to time the starts of the capture and playback devices to get close to the target level. Unfortunately every device behaves a bit differently on startup so this sometimes ends up quite far off.

Thanks for the info. I've been running at pretty low chunk size (128 at 48 kHz, 128 target) and I haven't noticed any issues. I don't usually use long FIR filters but I've tried some 64K tap filters and those seem to also work fine.

Other than increased CPU load, is there any disadvantage to using smaller chunks?

Michael