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

 

[m_u]

Has anyone tried MCHStreamer Kit for the toslink input\output, a bit more expensive than X-FI HD but supports various rates and can do master clock

 

[mdsimon2]

Has anyone tried MCHStreamer Kit for the toslink input\output, a bit more expensive than X-FI HD but supports various rates and can do master clock

I've used it with CamillaDSP, unfortunately it has some usability issues. IIRC CamillaDSP needed the MCHStreamer clock to be set to Internal for it start correctly, if this wasn't done it would get stuck in a stalled state.

You could probably set up a python script to switch the clock to Internal if it ever goes into the stalled state, restart CamillaDSP and then switch the clock to TOSLINK. Or if you just leave it running all the time you shouldn't have any issues.

The good news is it does have clocking options and the CamillaDSP buffer levels are rock solid via TOSLINK clocking.

Michael

 

[MCH]

Could it be checked with an oscilloscope? I guess, checking the rises are simultaneous over time? -no idea, just guessing.

Also have no idea of how you would do it by looking at the SPDIF waveform, maybe some smarter folks know.

I have checked synced by looking at DAC outputs on an oscilloscope while playing a 15 kHz tone. For example take the UL Mk5, route the SPDIF output to the CM6206 and the SPDIF output of the CM6206 to a DAC. Then play a 15 kHz to tone to an analog output and the SPDIF output of the UL Mk5. Observe the analog output of the UL Mk5 and the DAC being feed by the CM6206 on the scope, if they are sync'd you won't see any movement between the traces.

Can also run frequency sweeps using a loopback as timing reference and see if the phase response is stable.

Actually makes we want to try it on the S2 digital to see what it looks like.

Michael

I was very curious and went ahead and ordered a new toslink In/out usb card exactly the same as the one on post #1 to try to see if the toslink input and output are synchronized.
I have no idea if this is a valid test, but this is what i did:
Opened the card and put it to work toslink in > camilladsp > toslink out.
tapped the spdif signal right at the toslink receiver and transmitter.
autotrigger in one of the channels.
The idea is: if the second channel shows a static edge, that would confirm synchronization. If it is dancing around, that would be a signal of not synchronization. Again, i don't know if this hypothesis is correct, but i would like to know.
Well, my tests show the second. If i trigger the input, I see the edge stable at 0 but the output channel dancing around, and the same is true the other way around.
Difficult to capture in a picture but so that you get an idea (yellow is the triggered signal in this case)

If someone can suggest a test to do with the digital signal to confirm or not synchronization, i would love to try it.

 

[phofman]

I was very curious and went ahead and ordered a new toslink In/out usb card exactly the same as the one on post #1 to try to see if the toslink input and output are synchronized.

IMO you could tell by checking the USB isochronous mode. Adaptive playback means the playback is clocked by the USB host controller. Then by principle it could not be synchronous to the incoming SPDIF stream.

I have a similar soundcard and it has adaptive playback.

 

[m_u]

I've used it with CamillaDSP, unfortunately it has some usability issues. IIRC CamillaDSP needed the MCHStreamer clock to be set to Internal for it start correctly, if this wasn't done it would get stuck in a stalled state.

Have you tried to use MCHStreamer for input and output?
My signal path will be MCHStreamer->camilladsp->pi2aes (basically hifiberry digi), because I need coax out and I've already have the hat.
I can purchase S.M.S.L SU-1 or HifiMe UR23 to get a toslink input, but am not sure if it's going to solve the problem you described or not.
I've got multiple sources with various rates and I guess in my case I can use something like camilla sample rate switcher and it will do the job.
Ideally I want to resample everything to 96k before sending it to camilla.
I'm fairly sure I can do something like MCHStreamer->SoX->camilladsp->pi2aes. In this case camilladsp will always get an audio stream with a constant rate from SoX.
This will require a bit of coding which I'm capable of.

 

[mdsimon2]

Have you tried to use MCHStreamer for input and output?

Yes, I was using it as a TOSLINK input and output device.

My signal path will be MCHStreamer->camilladsp->pi2aes (basically hifiberry digi), because I need coax out and I've already have the hat.

I wouldn't do that as you can just use the MCHstreamer as capture and playback device and avoid any rate adjust / resampling in CamillaDSP. Converting from TOSLINK to coaxial is easy.

I've got multiple sources with various rates and I guess in my case I can use something like camilla sample rate switcher and it will do the job.
Ideally I want to resample everything to 96k before sending it to camilla.
I'm fairly sure I can do something like MCHStreamer->SoX->camilladsp->pi2aes. In this case camilladsp will always get an audio stream with a constant rate from SoX.
This will require a bit of coding which I'm capable of.

The sample rate switcher isn't meant to be used with a TOSLINK input card. In practice detecting a rate change over SPDIF is rather challenging. I haven't come across an SPDIF input device that has the correct ALSA flags for sample rate changes. I have found that with the S2 digi CamillaDSP could detect rate changes if the capture rate was set higher than the incoming rate. However, if the capture rate was lower than the incoming rate CamillaDSP would stall.

The MCHStreamer doesn't seem capable of detecting rate changes, at least via CamillaDSP.

I'd probably just get a hardware ASRC.

Michael

 

[m_u]

The sample rate switcher isn't meant to be used with a TOSLINK input card. In practice detecting a rate change over SPDIF is rather challenging

Have you tried using a dac as an input device like S.M.S.L SU-1? I guess it's going to have the same problem as the one you described with MCHstreamer

 

[mdsimon2]

Have you tried using a dac as an input device like S.M.S.L SU-1? I guess it's going to have the same problem as the one you described with MCHstreamer

A DAC will not work as you need something that can route audio to the USB host. This means a SPDIF to USB card or a device with bi-directional USB audio like an audio interface.

Michael

 

[m_u]

A DAC will not work as you need something that can route audio to the USB host. This means a SPDIF to USB card or a device with bi-directional USB audio like an audio interface.

Michael

Ah okay, thought so.
btw found this upsampler, might be a better option then MCHStreamer. what do you think?