• WANTED: Happy members who like to discuss audio and other topics related to our interest. Desire to learn and share knowledge of science required. There are many reviews of audio hardware and expert members to help answer your questions. Click here to have your audio equipment measured for free!

Analog audio crackling filter project.

atomant

Member
Joined
Sep 8, 2024
Messages
64
Likes
8
Hi,

I recently changed my S/PDIF interface I've been using for 2 decades for a PCI 6 ch analog audio card because the audio on this motherboard was toasted.

With several audio cards, come crackling noise. I've had a look on Amazon and even Soundblasters are plagued by this. Not wanting to test a bunch of audio cards, I sat and thought of a solution.

I could plug a noise reduction box between the PC and the AVR. Nothing fancy based on NE572 or LM1894. Simple RC divider being turned on and off with a 4066 or 4016. That sould be controlled by an Arduino Nano, reading it's data from the CamillaDSP status.

Material needed: a project box, an Arduino Nano, a USB cable, some resistors and capacitors, value to be determined experimentally, 6x 1/8 jacks and 3 stereo 1/8 audio cables, 2x 4016 or 4066 ICs.

The idea is to switch a resistor on to diminish the output going to the AVR when the CamillaDSP is paused, so the crackling is below audition level, and to remove the resistor from the circuit when CamillaDSP is running.


Arduino Nano:

C:
const int relayPin = 2;  // Replace with the correct pin number

void setup() {
  Serial.begin(9600);
  pinMode(relayPin, OUTPUT);
  digitalWrite(relayPin, LOW);  // Ensure pin 2 starts in a known state (LOW)
}

void loop() {
  if (Serial.available() > 0) {
    char incomingByte = Serial.read();
    if (incomingByte == '1') {
      digitalWrite(relayPin, HIGH);
    } else if (incomingByte == '0') {
      digitalWrite(relayPin, LOW);
    }
  }
}

PC:

Python:
import serial
# get config
from camilladsp import CamillaClient
import sys
import time


port = 1234

cdsp = CamillaClient("127.0.0.1", port)
cdsp.connect()

# Open the serial connection to the Arduino Nano
ser = serial.Serial('COM3', 9600, timeout=1)  # Replace COM3 with the correct port

while True:
    # Query the CamillaDSP server for the current state
    result = cdsp.query("GetState")
    print(result)

    # Toggle the digital pin on the Arduino Nano based on the result
    if result == "Paused":
        ser.write(b'1')  # Send a byte to toggle the pin high
    else:
        ser.write(b'0')  # Send a byte to toggle the pin low

    # Wait for a short period before querying again
    time.sleep(0.5)


Code at this stage is minimal. More to come in the next weeks.
 
Seems a bit like a Rube Goldberg solution. Would it not be simpler to get a relatively inexpensive 6 or 8 channel audio interface that wouldn't have this crackling problem?
 
1 - According to reviews on Amazon, good luck finding one. Do not read top reviews. Read reviews with 1 star or 2. Quality isn't what it used to be 20 years ago. And I have a $15 card purchased 10-15 years ago. It worked on Windows 98.
2 - With DSP, the audio signal is reduced to such an extent that you cannot possibly completely get rid of crackling unless you made more noise with music for example. And finally, my S/PDIF was some 30 dB louder, not to mention Toslink is immune to noise.
 
I had in mind something like this:

USB audio interface with 8 channels. $189 for it. Not the right choice if you are doing surround sound.
 
I had in mind something like this:

USB audio interface with 8 channels. $189 for it. Not the right choice if you are doing surround sound.
Thanks for the suggestion but it's completely overkill. The audio card I have connects to a Z906 by Logitech. Perfectly acceptable surround sound when corrected with DSP. Problem with it was DSP correction was bypassed using S/PDIF input (AC3/DTS pass-through). Therefore to benefit from correction to all 6 channels, I had to switch to analog audio, with all the aberrations coming with that. After a couple of weeks, I'm getting extremely annoyed by all this continuous crackling when the room is silent. The audio quality though is amazing compared to a stock Z906 with no correction. I'm using convolution filters made with REW and exported to CamillaDSP. The speaker delays are set in CDSP too. The LFE channel now benefits from a 80 Hz LPF and the satellites a 80 Hz HPF to eliminate crosstalk. I lost around 9 dB in the process I should compensate with the volume control, which in turns increases the noise. No hum fortunately.

Since the crackling is produced by the sound card itself, there is no way to correct the problem with filters as the filtered result is what feeds the sound card. I tried. Hence the hardware approach. Besides, I like playing with electronics. Always have been since the 70s.
 
Dropouts issues are by no means new... back when I had a BX board and some Envy24HT based cards, I'd be running some tool to tweak chipset registers to change PCI latency from 32 to 0. Later I had to increase the buffer size in Audacity to make recording from a Xonar D1 reliable. So things definitely weren't better in the olden days.

These problems generally have more to do with the computer the card is in rather than the card itself. (Joe Average generally has never even heard of DPC latency.) Although some can be a real bear to get to work at all due to buggy or incorrectly configured USB controllers or PCIe-PCI bridges.
Yes, you heard that correctly, USB controllers. There's a fair few cards out there with PCIe USB controllers so that they can use USB interface chips (generally CM6632AX or CM6620). I have been wondering for a while whether those could be modified with a breakout cable to use an internal USB2 header, disconnecting the USB controller entirely and only using the slot for power.
 
Dropouts issues are by no means new... back when I had a BX board and some Envy24HT based cards, I'd be running some tool to tweak chipset registers to change PCI latency from 32 to 0. Later I had to increase the buffer size in Audacity to make recording from a Xonar D1 reliable. So things definitely weren't better in the olden days.

These problems generally have more to do with the computer the card is in rather than the card itself. (Joe Average generally has never even heard of DPC latency.) Although some can be a real bear to get to work at all due to buggy or incorrectly configured USB controllers or PCIe-PCI bridges.
Yes, you heard that correctly, USB controllers. There's a fair few cards out there with PCIe USB controllers so that they can use USB interface chips (generally CM6632AX or CM6620). I have been wondering for a while whether those could be modified with a breakout cable to use an internal USB2 header, disconnecting the USB controller entirely and only using the slot for power.
Interesting. Makes sense. I'm on Fedora 40 most of the time (dual boot) but when I boot into windows 7 next time, I'll try the tweaks suggested in https://www.cantabilesoftware.com/glitchfree/

I have on of those PCI CMI8738 based 6 ch audio card. Never tested before so I cannot affirm whether or not it had issues on another motherboard.

IIRC we didn't have this issue in the early 90s. Well before the Sound Blaster and AdLib cards era, I've designed and built a sound card with a DAC-08 for my MC-10, that was around 1984. At the end of the 90s I duplicated the circuit to make it stereo, added the required logic ICs to get it to work on a V-20 based PC in an ISA slot at ports &h330-337. Never had any issue with dropout, noises, etc. All we needed to take care of is to put enough filtering (decoupling capacitors) for the logic chips. It sounded better than a Sound Blaster, thanks to the integrated stereo power amp. Only speakers were needed. I stopped using it when Sound Blaster became a standard and fewer programs and games were able to access a DAC directly. I still have it though, as well as a 386DX40 board. PC CPU clocks were anything from 4.7 MHz to 100 MHz, the CoCo had a 890 kHz clock, the Z-80 or 6502 based computers ran at 1 or 2 MHz. Nowadays, we're in the GHz region.
 
IIRC we didn't have this issue in the early 90s. Well before the Sound Blaster and AdLib cards era,
Computers are faster but the operating system is doing more and there is usually more junk running in the background so there are are more and longer-lasting interrupts.
 
Computers are faster but the operating system is doing more and there is usually more junk running in the background so there are are more and longer-lasting interrupts.
Et voila!

Seriously, a 8086 based computer with NNANSI installed was faster to print a text file to screen than any modern multi-GHz PC. Naturally that was before ATI removed int 10h from their graphic card ROMs
 
IMO a low-level cracking noise which can be suppressed by slightly attenuating the signal and is audible during silent musical sections (or no music at all) does not seem like buffer dropouts. The dropouts cause discontinuities in the data stream and therefore are as loud as the music itself.

IMO the symptoms would hint at a ground loop effect (if the AVR is grounded) or a noisy soundcard indeed.
 
IMO the symptoms would hint at a ground loop effect (if the AVR is grounded) or a noisy soundcard indeed.
With the former being a good deal more likely. Ever since I downgraded to onboard audio, I haven't quite been able to keep slight clicks from my fridge compressor turning on/off out of my computer playback chain either, I guess the Behringer HD400's CMRR is steadily diminishing towards the treble and higher output impedance does its thing as well. I haven't been very motivated to do anything about since that's literally the only thing of this kind that's audible, and it's not very frequent, plus I don't particularly fancy increasing idle power consumption (getting a modern rig with an i7 and a regular ATX power supply down to 14.5 W is no mean feat as-is).
 
IMO a low-level cracking noise which can be suppressed by slightly attenuating the signal and is audible during silent musical sections (or no music at all) does not seem like buffer dropouts. The dropouts cause discontinuities in the data stream and therefore are as loud as the music itself.
We do experiment dropouts as well from time to time. Tolerable.
IMO the symptoms would hint at a ground loop effect (if the AVR is grounded) or a noisy soundcard indeed.
Not grounded (2 prongs AC plug). The sole ground potential in this AVR is coming from the audio cables themselves. I haver a pair of audio isolation transformers to check for ground loops and eliminate them.

Could be EMI I'd say. Those cards were manufactured in a period with CPU clock frequencies were in the Mhz region. Nowadays with several GHz, everything with leads acts as a receiving antenna. I put ferrite cores at the ends of audio cable. Can't say for sure whether there is a noticeable difference. Bottom line is that the problem is still present.

It also seems worst on Fedora than on Windows 7. Can't be 100% certain. Too many variables (alsa master gain, alsa dsp gain, loopback gain, etc) are causing the linux box to play louder at the same AVR volume setting without clipping. The configuration for the filtering is identical though: I wrote a python script to remap channels from linux config to windows and update other parameters so whenever I make a change in a CDSP config file on linux, it's readily exported to windows and ready to run, with the proper settings.
 
Interesting. Makes sense. I'm on Fedora 40 most of the time (dual boot) but when I boot into windows 7 next time, I'll try the tweaks suggested in https://www.cantabilesoftware.com/glitchfree/

I have on of those PCI CMI8738 based 6 ch audio card. Never tested before so I cannot affirm whether or not it had issues on another motherboard.

IIRC we didn't have this issue in the early 90s. Well before the Sound Blaster and AdLib cards era, I've designed and built a sound card with a DAC-08 for my MC-10, that was around 1984. At the end of the 90s I duplicated the circuit to make it stereo, added the required logic ICs to get it to work on a V-20 based PC in an ISA slot at ports &h330-337. Never had any issue with dropout, noises, etc. All we needed to take care of is to put enough filtering (decoupling capacitors) for the logic chips. It sounded better than a Sound Blaster, thanks to the integrated stereo power amp. Only speakers were needed. I stopped using it when Sound Blaster became a standard and fewer programs and games were able to access a DAC directly. I still have it though, as well as a 386DX40 board. PC CPU clocks were anything from 4.7 MHz to 100 MHz, the CoCo had a 890 kHz clock, the Z-80 or 6502 based computers ran at 1 or 2 MHz. Nowadays, we're in the GHz region.
After applying all the Windows 7 tweaks specified in the GlitchFree guide mentioned above, I ran Latencymon and clearly the CMI8738 driver is problematic.

Camilla.log:
Code:
2024-10-13 11:40:24.633582 INFO  [src/bin.rs:683] CamillaDSP version 2.0.3
2024-10-13 11:40:24.636582 INFO  [src/bin.rs:684] Running on windows, x86_64
2024-10-13 11:40:32.790618 WARN  [src\wasapidevice.rs:398] Playback interrupted, no data available
2024-10-13 11:40:32.840624 INFO  [src\wasapidevice.rs:382] Restarting playback after buffer underrun
2024-10-13 11:41:25.520814 WARN  [src\wasapidevice.rs:398] Playback interrupted, no data available
2024-10-13 11:42:20.379280 WARN  [src\wasapidevice.rs:361] Missing event! Resetting stream. Interval 0.019145833333325868 s, expected 0.01 s
2024-10-13 11:42:41.189922 WARN  [src\wasapidevice.rs:361] Missing event! Resetting stream. Interval 0.02008333333333212 s, expected 0.01 s
2024-10-13 11:42:44.354824 WARN  [src\wasapidevice.rs:361] Missing event! Resetting stream. Interval 0.035208333333333286 s, expected 0.02 s
2024-10-13 11:42:48.578361 WARN  [src\wasapidevice.rs:361] Missing event! Resetting stream. Interval 0.018395833333333833 s, expected 0.01 s
2024-10-13 11:42:58.088568 WARN  [src\wasapidevice.rs:361] Missing event! Resetting stream. Interval 0.018562499999999815 s, expected 0.01 s
2024-10-13 11:43:09.087965 WARN  [src\wasapidevice.rs:361] Missing event! Resetting stream. Interval 0.01814583333333175 s, expected 0.01 s
2024-10-13 11:44:15.040840 WARN  [src\wasapidevice.rs:361] Missing event! Resetting stream. Interval 0.021250000000009095 s, expected 0.01 s
2024-10-13 11:44:46.753367 WARN  [src\wasapidevice.rs:361] Missing event! Resetting stream. Interval 0.058020833333333854 s, expected 0.03 s
2024-10-13 11:44:51.754002 WARN  [src\wasapidevice.rs:361] Missing event! Resetting stream. Interval 0.024020833333333158 s, expected 0.01 s
2024-10-13 11:44:52.813136 WARN  [src\wasapidevice.rs:361] Missing event! Resetting stream. Interval 0.06191666666666673 s, expected 0.03 s
2024-10-13 11:45:16.316121 WARN  [src\wasapidevice.rs:361] Missing event! Resetting stream. Interval 0.06056249999999963 s, expected 0.03 s
2024-10-13 11:45:21.401267 WARN  [src\wasapidevice.rs:361] Missing event! Resetting stream. Interval 0.060645833333333954 s, expected 0.03 s
2024-10-13 11:45:29.485793 WARN  [src\wasapidevice.rs:361] Missing event! Resetting stream. Interval 0.02395833333333286 s, expected 0.01 s
2024-10-13 11:45:30.240389 WARN  [src\wasapidevice.rs:361] Missing event! Resetting stream. Interval 0.020187500000000025 s, expected 0.01 s
2024-10-13 11:45:37.607825 WARN  [src\wasapidevice.rs:361] Missing event! Resetting stream. Interval 0.018895833333333556 s, expected 0.01 s
2024-10-13 11:45:40.599705 WARN  [src\wasapidevice.rs:361] Missing event! Resetting stream. Interval 0.019708333333332995 s, expected 0.01 s
2024-10-13 11:45:44.208663 WARN  [src\wasapidevice.rs:361] Missing event! Resetting stream. Interval 0.018645833333333695 s, expected 0.01 s
2024-10-13 11:45:52.691240 WARN  [src\wasapidevice.rs:361] Missing event! Resetting stream. Interval 0.060645833333333954 s, expected 0.03 s
2024-10-13 11:45:53.831885 WARN  [src\wasapidevice.rs:361] Missing event! Resetting stream. Interval 0.07122916666666668 s, expected 0.03 s
2024-10-13 11:45:57.641369 WARN  [src\wasapidevice.rs:361] Missing event! Resetting stream. Interval 0.058020833333332966 s, expected 0.03 s
2024-10-13 11:46:01.840402 WARN  [src\wasapidevice.rs:361] Missing event! Resetting stream. Interval 0.018624999999999226 s, expected 0.01 s
2024-10-13 11:46:06.777529 WARN  [src\wasapidevice.rs:361] Missing event! Resetting stream. Interval 0.027000000000000135 s, expected 0.01 s
2024-10-13 11:47:28.660426 INFO  [src\wasapidevice.rs:382] Restarting playback after buffer underrun
2024-10-13 11:47:28.950463 WARN  [src\wasapidevice.rs:398] Playback interrupted, no data available
2024-10-13 11:47:28.960465 INFO  [src\wasapidevice.rs:382] Restarting playback after buffer underrun
2024-10-13 11:47:30.060604 WARN  [src\wasapidevice.rs:398] Playback interrupted, no data available
2024-10-13 11:47:30.070606 INFO  [src\wasapidevice.rs:382] Restarting playback after buffer underrun
2024-10-13 11:47:35.100744 WARN  [src\wasapidevice.rs:398] Playback interrupted, no data available
2024-10-13 11:47:35.130748 INFO  [src\wasapidevice.rs:382] Restarting playback after buffer underrun

Clipboard01.jpg

UPDATE:

CPU throttling resets itself on Win 7 despite the registry change, looks like a bug. Will investigate I re-disabled it Better report from Latencymon but still audible audio artefacts, same as before I'd say, no amelioration (yet).

Clipboard01.jpg
 
Last edited:
I only now got it... you're using the analog outputs on a CMI8738 based card? Those are - for lack of a better term - complete dogsh**, and I'm not the least bit kidding. These things were only ever useful for SPDIF I/O, preferably with the open-source drivers installed (some hoop-jumping required to install them - boot with driver signing disabled).

Since you can run one of those, you might try nabbing a used Asus Xonar D1. These guys have their quirks (basically it's shared mode or death, the drivers should not be too new, and you want to run a multiple of 48 kHz, plus the relays can be a bit intermittent), but the hardware basically performs very well. They used to be quite common for HTPC builds around 2010 over here (and quite inexpensive on the used market as a result, which is why I've got two), though I think the same may not have been the case in the US.

You can fundamentally also try a SB X-Fi card, but be warned that those shipping without a heatsink have a habit of dying, presumably due to cracking their solder balls under thermal stress (I think the occasional bad electrolytic near the EMU20K chip has also been observed). My working theory is that a reflow should revive those, but obviously you'll need the tools and skills for that. With a bit of luck, a heatgun from both sides and a ton of flux might do it, but no guarantees.
 
I only now got it... you're using the analog outputs on a CMI8738 based card? Those are - for lack of a better term - complete dogsh**, and I'm not the least bit kidding. These things were only ever useful for SPDIF I/O, preferably with the open-source drivers installed (some hoop-jumping required to install them - boot with driver signing disabled).

That's right. Your description of the analog audio is quite accurate. I remember a motherboard I had with onboard CMI8738 audio a while ago, terrible.

Since you can run one of those, you might try nabbing a used Asus Xonar D1. These guys have their quirks (basically it's shared mode or death, the drivers should not be too new, and you want to run a multiple of 48 kHz, plus the relays can be a bit intermittent), but the hardware basically performs very well. They used to be quite common for HTPC builds around 2010 over here (and quite inexpensive on the used market as a result, which is why I've got two), though I think the same may not have been the case in the US.
None on Amazon. A few Asus Xonar D1/A on Ebay for 30-70$. Can you confirm they work with Win 7 64 / Linux 6.8?



Is the D1/A a different model?

Not really comfortable buying one of those. I couldn't find any reference on the net comparing the specs so I asked an AI who replied:
Code:
Based on the information provided, here are the key differences between the Asus Xonar D1 and D1/A sound cards:

Similarities
Both are PCI-based sound cards
They likely have similar audio capabilities and features
Both use the Cirrus Logic CS4398 DAC chip
Differences
Power requirements:
The D1 requires only motherboard power
The D1/A requires an additional power connection via a floppy drive power connector
Form factor:
The D1 uses a standard PCI slot
The D1/A uses a PCI-to-PCIe bridge, allowing it to fit in PCIe slots
Compatibility:
The D1 is limited to PCI slots
The D1/A can be used in systems with PCIe slots, offering more flexibility
Key Points to Consider
The main advantage of the D1/A is its ability to use PCIe slots, which can be beneficial for systems with limited PCI slot availability.
The D1 may be preferable if you only have available PCI slots in your system.
Both cards offer similar audio quality and features, so the choice often comes down to compatibility rather than performance differences.
The D1/A requires an additional power connection, which might affect cable management in some cases.
Conclusion
While the Asus Xonar D1 and D1/A are essentially the same card in terms of audio capabilities, the D1/A offers more flexibility in terms of installation options due to its PCIe compatibility. Choose based on your system's available slots and power connectivity.

The Ebay images clearly show a PCI card. If the D1/A is PCIe, then it's clearly not the same product.

 
Last edited:
None on Amazon. A few Asus Xonar D1/A on Ebay for 30-70$.
Hmm. That seems a tad on the spendy side for a card that used to retail in the upper 50s of € here back in the day and no modern computer has a slot for any more (the only reason I am no longer using it). That being said, the new price would have been something like 85 CAD, so paying 30 of those would be like 20€, which is not an altogether bad deal even if they went for that here a decade ago. I suppose a D2 will be considerably more? They always were.

Had a look at the Canadian 'bay and spotted a few Xonar DGs on there. This was a fairly late budget "gaming" model with a better headphone driver and also a fairly clean mic input if memory serves. It has a more basic converter complement with a CS4245 codec + another CS4361 and only sports onboard-ish 1 Vrms output, but that's all still lightyears ahead of a crappy old CMI8738.
There's also a SB X-Fi Elite Pro from a seller in Quebec for what looks like a decent price. While they never were quite as clean as the Xonars, you still get some CS4398s (for all channels) and good opamps, a heatsink on the EMU chip right from the factory, and the dock and remote. Fancy.
Can you confirm they work with Win 7 64 / Linux 6.8?
My old computer ran Win7 64 last, if that's what you mean. I have no experience with Linux, but I bet it works better than Windows... at least I vaguely remember you can use multiple of the cards at once there which the Windows driver has no provisions for (it gets utterly confused).
Is the D1/A a different model?
There were a few subvariants but they only differed in what you got in the package (e.g. my D2 was a Battlefield 1942 special edition). Hardware wise, there's only the D1 and its later PCIe variant, the DX (which seems a bit failure-prone).
Then there's the D2 and the D2X, DS and DSX, and DG and DGX.
 
Last edited:
Hmm. That seems a tad on the spendy side for a card that used to retail in the upper 50s of € here back in the day and no modern computer has a slot for any more (the only reason I am no longer using it). That being said, the new price would have been something like 85 CAD, so paying 30 of those would be like 20€, which is not an altogether bad deal even if they went for that here a decade ago. I suppose a D2 will be considerably more? They always were.
Allright, for less than $50, I purchased the one from the Cyprus seller. I'll report in 2 weeks or so.

You can't imagine the hassle I had to find a serial mouse and the price I had to pay for one in reasonable condition for my 386 (no USB back then). I needed that because I designed a 20MHz oscilloscope 2 traces with EXAR MP8785 ADCs quite a while ago, controlled by I/O ports on the ISA bus, the programming was in MS Basic, modified to accept a mouse (int 33h). It used to work on a Pentium 90 board at a speed of 10 MHz for the ISA with all the rise/fall times optimized for that speed. I don't have this board anymore, only an older 386DX+387 where the plastic for the connector to hold the cache memory has desintegrated and the memory is held in place with pieces of wood.

IMGP0016.JPG
Thanks for the advice, that is very appreciated.
 
Last edited:
Camilla.log:
Code:
2024-10-13 11:40:24.633582 INFO [src/bin.rs:683] CamillaDSP version 2.0.3
2024-10-13 11:40:24.636582 INFO [src/bin.rs:684] Running on windows, x86_64
2024-10-13 11:40:32.790618 WARN [src\wasapidevice.rs:398] Playback interrupted, no data available
2024-10-13 11:40:32.840624 INFO [src\wasapidevice.rs:382] Restarting playback after buffer underrun
2024-10-13 11:41:25.520814 WARN [src\wasapidevice.rs:398] Playback interrupted, no data available
2024-10-13 11:42:20.379280 WARN [src\wasapidevice.rs:361] Missing event! Resetting stream. Interval 0.019145833333325868 s, expected 0.01 s
2024-10-13 11:42:41.189922 WARN [src\wasapidevice.rs:361] Missing event! Resetting stream. Interval 0.02008333333333212 s, expected 0.01 s
2024-10-13 11:42:44.354824 WARN [src\wasapidevice.rs:361] Missing event! Resetting stream. Interval 0.035208333333333286 s, expected 0.02 s
2024-10-13 11:42:48.578361 WARN [src\wasapidevice.rs:361] Missing event! Resetting stream. Interval 0.018395833333333833 s, expected 0.01 s
2024-10-13 11:42:58.088568 WARN [src\wasapidevice.rs:361] Missing event! Resetting stream. Interval 0.018562499999999815 s, expected 0.01 s
2024-10-13 11:43:09.087965 WARN [src\wasapidevice.rs:361] Missing ev
Is this your CDSP config https://www.audiosciencereview.com/...ing-camilla-dsp-xo-basics.57682/#post-2108995 ?

The capture and playback soundcards do not run synchronously, yet that config has rate adjust disabled and no async resampling. That can be the cause of your issues. IMO more likely than the driver missing IRQ requests by tens of millisecs.
 
Is this your CDSP config https://www.audiosciencereview.com/...ing-camilla-dsp-xo-basics.57682/#post-2108995 ?

The capture and playback soundcards do not run synchronously, yet that config has rate adjust disabled and no async resampling. That can be the cause of your issues. IMO more likely than the driver missing IRQ requests by tens of millisecs.
Yes, it is. Well, one of them. For decoding dolby surround, I have several other setups: quad, 6ch; in normal and rotated 90 degrees versions. It happened while latencymon was running. Might be irrelevant. First time I see this.

I got a message from CDSP when it starts saying the rate adjust could be handled by the VAC or audio card if memory serves so I removed it from CDSP since.
 
The rate adjust must be handled somehow if the two soundcards are not synchronous. Either the device can have its rate adjusted, or async resampler must be deployed.

AFAIK CDSP can control rate of usb gadget and alsa loopback on linux and Blackhole on OSX, no direct rate control on Wasapi https://github.com/HEnquist/camilladsp/blob/master/src/wasapidevice.rs. IMO the rate adjust must be enabled and async resampler configured in your chain to work properly. Other issues may arise (as always), but this is the basic requirement.
 
Back
Top Bottom