Analog audio crackling filter project.

[phofman]

Very good. Did you try raising the sample bitwidth from 16? IMO both audio devices should support 24 or 32bits, then no need to drop information by truncating to 16 bits. Most likely inaudible, of course.

 

[atomant]

If memory serves, the CMI8738 supports only 16. In 2-3 weeks, I'm getting an Asus Xonar D1, which supports 24 @ 192kHz. Tired of all those constant clicks, crackles which seem to be a linux only problem.

Always had my Windows record/playback settings set to 16 @ 44.1/48 kHz anyways. Being deaf to frequencies above 8kHz, I won't notice either.

 

[atomant]

You're willing to have an old soundcard shipped all the way from an island in the middle of the Mediterranean Sea? 'kay, whatever...

Xonar D1 arrived today. It's amazing. Same level on analog audio as my onboard S/PDIF, very comparable audio quality (I noticed immediately), no noise (similar to digital). I've regained the 30dB I lost with el cheapo CMI8738 and I can leave the Z906 volume alone, centered as it always was. No more clicks or crackling.

Sole adjustment to compensate for the auto limiter on fedora:

 amixer -c D1 set Master 123
Simple mixer control 'Master',0
  Capabilities: pvolume pswitch pswitch-joined
  Playback channels: Front Left - Front Right - Rear Left - Rear Right - Front Center - Woofer - Side Left - Side Right
  Limits: Playback 67 - 127
  Mono:
  Front Left: Playback 123 [93%] [-4.00dB] [on]
  Front Right: Playback 123 [93%] [-4.00dB] [on]
  Rear Left: Playback 123 [93%] [-4.00dB] [on]
  Rear Right: Playback 123 [93%] [-4.00dB] [on]
  Front Center: Playback 123 [93%] [-4.00dB] [on]
  Woofer: Playback 123 [93%] [-4.00dB] [on]
  Side Left: Playback 123 [93%] [-4.00dB] [on]
  Side Right: Playback 123 [93%] [-4.00dB] [on]

Thanks so much for the suggestion. I'm very pleased with my purchase.

Therefore this project box is no longer needed.

 

[antcollinet]

Not grounded (2 prongs AC plug).

What about the TV or any other devices connected to the AVR. Any of those grounded - in any way at all.

Or do you have a loop in the interconnect (eg audio to AVR (RCA), Video to AVR (HDMI), or Video to TV with video also from AVR to TV.

All of these can cause a ground loop that has nothing to do with mains ground.


As a test it would be worth disconnecting everything from the AVR, except speakers, and a single stereo audio from the PC.

Still get crackling?

 

[atomant]

What about the TV or any other devices connected to the AVR. Any of those grounded - in any way at all.

TOSLINK

Or do you have a loop in the interconnect (eg audio to AVR (RCA), Video to AVR (HDMI), or Video to TV with video also from AVR to TV.

None of that connected

All of these can cause a ground loop that has nothing to do with mains ground.

I know. Very well aware of the potential issue.

As a test it would be worth disconnecting everything from the AVR, except speakers, and a single stereo audio from the PC.

The sole ground path to the AVR is via the shileded audio cables to the PC

Still get crackling?

No, it's completely gone the minute I plugged the new card in. Thanks for your assistance.

 

[antcollinet]

No, it's completely gone the minute I plugged the new card in. Thanks for your assistance.

Note to self - never reply until reading complete thread

 

[atomant]

Very good. Did you try raising the sample bitwidth from 16? IMO both audio devices should support 24 or 32bits, then no need to drop information by truncating to 16 bits. Most likely inaudible, of course.

I followed your suggestion and set everything to SE32LE on linux; Win config is yet to be redone. Dual boot system.

3: `Multichannel' Analog audio output on device Xonar D1
    -hardware address:               hw:1,0  (or hw:D1,0)
    -formats:                        S16_LE, S32_LE
    -usb audio class:                (n/a)
    -streamfile:                     (n/a)
    -character device:               /dev/snd/pcmC1D0p
    -monitor file:                   /proc/asound/card1/pcm0p/sub0/hw_params

 

[atomant]

Very good. Did you try raising the sample bitwidth from 16? IMO both audio devices should support 24 or 32bits, then no need to drop information by truncating to 16 bits. Most likely inaudible, of course.

Pardon me if those are stupid questions but I'm really wondering as I never tried more resolution than 16 bits and more bandwidth than 48kHz.

On linux I tried to set the playback device format (audio card via pipewire) to 32 bits but the increased latency is too important for videos: audio and video are out of sync just enough to be distracting, in the bad sense. Back to 16 bits fixed the problem. There is latency too but it's supportable. For music, there is no noticeable audible difference anyway.

Mp3 are sampled at 16 bits. Padding them with zeroes would only add to processing time. I understand that CDSP already do that to promote the bitrate to 64, for 64 bit computers I guess. For youtube videos for example, I might see an improvement. Some are sampled at 24 bits. But they are compressed as well and 2 channels only.

On windows 7, it seems the max supported by the OS is 24 bits. I might be wrong, but its the maximum I see in the Sound/playback panel. I did not bother to test it yet, given the experience with linux.

My sound card supports 192 kHz SR. Most of my material is 44.1, most videos I watch online are 48. I do not play any commercial DVD or Blue-ray. Why would I want to set the sampling rate higher than 48 kHz? I'm not interested in studying bats behavior. Are there any advantages? I can only see the potential disadvantage of increasing latency further more, making the system unsuitable for movies, right? Besides, with the condition of my hearing, I would not notice the difference in bandwidth even though the recordings were sampled at 22 kHz, or even 16 according to the Nyquist criterion..

A final note on listdevices.exe. It seems to only report the sample rate selected in Sound/playback instead of listing the card capabilities, ignores the selected bitrate and reports FLOAT32LE, but has the number of channels correct. It's great to fetch the proper devices names.

E:\Program Files\camilla\dsp>listdevices.exe
Available hosts:
  [Wasapi]
WASAPI
  Default Input Device:
    Ok("Line 1 (Virtual Audio Cable)")
  Default Output Device:
    Ok("Line 1 (Virtual Audio Cable)")

  Devices:
  Device: "Speakers (ASUS Xonar D1 Audio Device)"
  ============================================================

    Capture
    ------------------------------------------------------------

    Playback
    ------------------------------------------------------------
    Default output stream config:
      channels: 6, samplerate: 48000, format: FLOAT32LE
    All supported output stream configs:
      channels: 6, samplerate min: 48000 max: 48000, format: FLOAT32LE

 

[phofman]

On linux I tried to set the playback device format (audio card via pipewire) to 32 bits but the increased latency is too important for videos: audio and video are out of sync just enough to be distracting, in the bad sense. Back to 16 bits fixed the problem. There is latency too but it's supportable. For music, there is no noticeable audible difference anyway.

Why should increasing bitwidth raise latency? I do not see any technical reason.

Why pipewire when using CDSP? I am afraid I do not understand.

A final note on listdevices.exe. It seems to only report the sample rate selected in Sound/playback instead of listing the card capabilities, ignores the selected bitrate and reports FLOAT32LE, but has the number of channels correct. It's great to fetch the proper devices names.

If that binary comes from https://github.com/HEnquist/cpal-listdevices/tree/master , it uses shared-mode access only and the soundcard parameters listed are irrelevant to the exclusive mode access. It's hinted already by the float32 format which almost no hardware device supports natively.

 

[atomant]

Why should increasing bitwidth raise latency? I do not see any technical reason.

I have near zero knowledge on digital audio technicalities. It's only a constatation, an undenyable fact.

Depends on the source too. I'm still experimenting. A video from Odysee is not affected. A local video is badly affected: after 2 minutes you want to shut it off:

Input #0, mpegts, from '/mnt/linux486/mythtv/1111_20240930230100.ts':
  Duration: 00:28:59.56, start: 10775.128589, bitrate: 18241 kb/s
  Program 1
  Stream #0:0[0x31]: Video: mpeg2video (Main) ([2][0][0][0] / 0x0002), yuv420p(tv, bt709, progressive), 1280x720 [SAR 1:1 DAR 16:9], Closed Captions, 59.94 fps, 59.94 tbr, 90k tbn
    Side data:
      cpb: bitrate max/min/avg: 80000000/0/0 buffer size: 9781248 vbv_delay: N/A
  Stream #0:1[0x34](fre): Audio: ac3 (AC-3 / 0x332D4341), 48000 Hz, 5.1(side), fltp, 384 kb/s (clean effects)
  Stream #0:2[0x35](frm): Audio: ac3 (AC-3 / 0x332D4341), 48000 Hz, stereo, fltp, 192 kb/s (visual impaired) (descriptions)

Why pipewire when using CDSP? I am afraid I do not understand.

It's my playback device. I mean alsaipewire.

If that binary comes from https://github.com/HEnquist/cpal-listdevices/tree/master , it uses shared-mode access only and the soundcard parameters listed are irrelevant to the exclusive mode access. It's hinted already by the float32 format which almost no hardware device supports natively.

Yes, that's the one. Oh! thanks!

UPDATE

Strange issue while I was trying to reconfigure Windows for 24 bits instead of 16. At some point it kinda worked
format: S24LE3 for both the capture and playback. I had to enable 24 bits in the VAC first. Seemed pretty straightforward. So I skipped the full backup and saved 40 minutes.

However VLC suddenly started to output stereo mp3 to all 6 channels at full volume. It took me 3.5 hours to figure out what was happening. Reverting settings one by one to 16 bits didn't help. Neither rebooting. I would have normally restored from a full backup at that point but had none recent since I installed the new sound card.

It required a computer power down AND erasing VLC config to get things back to normal. I alone decide how stereo material is being played on this computer. Certainly not windows, or VLC. That's not acceptable. Strangely enough, never had a single issue with VLC in years until today. Here's the diff file in case you wonder why or how it happened. I don't have the config before changing to 24 bits. The following is the diff after the 24 bits set and a fresh config. At first, no audio at all until I select waveout. Never used that before. Seems DirectSound is no more an option or is not detected and configured automatically.

$ diff -ubB vlcrc.old vlcrc
--- vlcrc.old   2024-10-22 22:02:47.146951000 -0400
+++ vlcrc       2024-10-22 22:19:31.850532200 -0400
@@ -381,22 +381,22 @@
 #scene-format=png

 # Image width (integer)
-scene-width=320
+#scene-width=-1

 # Image height (integer)
-scene-height=240
+#scene-height=-1

 # Filename prefix (string)
 #scene-prefix=scene

 # Directory path prefix (string)
-scene-path=e:\temp\wintmp
+#scene-path=

 # Always write to the same file (boolean)
 #scene-replace=0

 # Recording ratio (integer)
-scene-ratio=15
+#scene-ratio=50

 [rotate] # Rotate video filter

@@ -548,10 +548,10 @@
 [croppadd] # Video cropping filter

 # Pixels to crop from top (integer)
-croppadd-croptop=33
+#croppadd-croptop=0

 # Pixels to crop from bottom (integer)
-croppadd-cropbottom=33
+#croppadd-cropbottom=0

 # Pixels to crop from left (integer)
 #croppadd-cropleft=0
@@ -1574,7 +1574,7 @@
 #file-logging=0

 # Log filename (string)
-logfile=e:\temp\vlc.log
+#logfile=

 # Log format (string)
 #logmode=text
@@ -1645,7 +1645,7 @@
 #qt-fs-controller=1

 # Save the recently played items in the menu (boolean)
-qt-recentplay=0
+#qt-recentplay=1

 # List of words separated by | to filter (string)
 #qt-recentplay-filter=
@@ -2289,10 +2289,10 @@
 #sout-x264-stats=x264_2pass.log

 # Default preset setting used (string)
-#sout-x264-preset=
+sout-x264-preset=ultrafast

 # Default tune setting used (string)
-#sout-x264-tune=
+sout-x264-tune=film

 # x264 advanced options (string)
 #sout-x264-options=
@@ -2622,7 +2622,7 @@
 [schroedinger] # Dirac video decoder using libschroedinger

 # Rate control method (string)
-sout-schro-rate-control=constant_noise_threshold
+#sout-schro-rate-control=

 # Constant quality factor (float)
 #sout-schro-quality=-1.000000
@@ -2640,7 +2640,7 @@
 #sout-schro-min-bitrate=-1

 # GOP structure (string)
-sout-schro-gop-structure=adaptive
+#sout-schro-gop-structure=

 # GOP length (integer)
 #sout-schro-gop-length=-1
@@ -2652,13 +2652,13 @@
 #sout-schro-coding-mode=auto

 # Motion Vector precision (string)
-sout-schro-mv-precision=1
+#sout-schro-mv-precision=

 # Size of motion compensation blocks (string)
-sout-schro-motion-block-size=automatic
+#sout-schro-motion-block-size=

 # Overlap of motion compensation blocks (string)
-sout-schro-motion-block-overlap=automatic
+#sout-schro-motion-block-overlap=

 # Three component motion estimation (integer)
 #sout-schro-me-combined=-1
@@ -2676,10 +2676,10 @@
 #sout-schro-enable-phasecorr-me=-1

 # Intra picture DWT filter (string)
-sout-schro-intra-wavelet=desl_dubuc_9_7
+#sout-schro-intra-wavelet=

 # Inter picture DWT filter (string)
-sout-schro-inter-wavelet=desl_dubuc_9_7
+#sout-schro-inter-wavelet=

 # Number of DWT iterations (integer)
 #sout-schro-transform-depth=-1
@@ -2688,10 +2688,10 @@
 #sout-schro-enable-multiquant=-1

 # Size of code blocks in each subband (string)
-sout-schro-codeblock-size=automatic
+#sout-schro-codeblock-size=

 # Prefilter (string)
-sout-schro-filtering=none
+#sout-schro-filtering=

 # Amount of prefiltering (float)
 #sout-schro-filter-value=-1.000000
@@ -2700,7 +2700,7 @@
 #sout-schro-enable-scd=-1

 # perceptual weighting method (string)
-sout-schro-perceptual-weighting=none
+#sout-schro-perceptual-weighting=

 # perceptual distance (float)
 #sout-schro-perceptual-distance=-1.000000
@@ -2715,7 +2715,7 @@
 #sout-schro-vert-slices=-1

 # Force Profile (string)
-sout-schro-force-profile=auto
+#sout-schro-force-profile=

 [qsv] # Intel QuickSync Video encoder for MPEG4-Part10/MPEG2 (aka H.264/H.262)

@@ -3013,10 +3013,10 @@
 [waveout] # WaveOut audio output

 # Select Audio Device (string)
-waveout-audio-device=Speakers (Realtek AC'97 Audio) ($1,$64)
+waveout-audio-device=Line 1 (Virtual Audio Cable) ($1,$64)

 # Audio volume (float)
-#waveout-volume=1.000000
+waveout-volume=0.824983

 # Use float32 output (boolean)
 #waveout-float32=1
@@ -3041,16 +3041,16 @@
 [directsound] # DirectX audio output

 # Output device (string)
-directx-audio-device=Primary Sound Driver
+#directx-audio-device=

 # Use float32 output (boolean)
 #directx-audio-float32=1

 # Speaker configuration (string)
-directx-audio-speaker=5.1
+#directx-audio-speaker=Windows default

 # Audio volume (float)
-directx-volume=1.100000
+#directx-volume=1.000000

 [amem] # Audio memory output

@@ -3271,7 +3271,7 @@
 #equalizer-vlcfreqs=1

 # Global gain (float)
-equalizer-preamp=0.000000
+#equalizer-preamp=12.000000

 [compressor] # Dynamic range compressor

@@ -3279,22 +3279,22 @@
 #compressor-rms-peak=0.200000

 # Attack time (float)
-compressor-attack=1.400000
+#compressor-attack=25.000000

 # Release time (float)
-compressor-release=1.900000
+#compressor-release=100.000000

 # Threshold level (float)
-compressor-threshold=0.000000
+#compressor-threshold=-11.000000

 # Ratio (float)
-compressor-ratio=1.000000
+#compressor-ratio=4.000000

 # Knee radius (float)
-compressor-knee=1.000000
+#compressor-knee=5.000000

 # Makeup gain (float)
-compressor-makeup-gain=0.000000
+#compressor-makeup-gain=7.000000

 [chorus_flanger] # Sound Delay

@@ -4056,7 +4056,7 @@
 #volume-save=1

 # Force S/PDIF support (boolean)
-spdif=1
+#spdif=0

 # Force detection of Dolby Surround (integer)
 #force-dolby-surround=0
@@ -4083,7 +4083,7 @@
 #audio-time-stretch=1

 # Audio output module (string)
-aout=aout_directx
+aout=waveout

 # Media role (string)
 #role=video
@@ -4149,7 +4149,7 @@
 #mouse-hide-timeout=1000

 # Video snapshot directory (or filename) (string)
-snapshot-path=e:\temp
+#snapshot-path=

 # Video snapshot file prefix (string)
 #snapshot-prefix=vlcsnap-
@@ -4392,7 +4392,7 @@
 #meta-url=

 # File caching (ms) (integer)
-file-caching=10000
+#file-caching=1000

 # Live capture caching (ms) (integer)
 #live-caching=300
@@ -4401,10 +4401,10 @@
 #disc-caching=300

 # Network caching (ms) (integer)
-network-caching=30000
+#network-caching=1000

 # Clock reference average counter (integer)
-cr-average=4000
+#cr-average=40

 # Clock synchronisation (integer)
 #clock-synchro=-1
@@ -4413,7 +4413,7 @@
 #clock-jitter=5000

 # Network synchronisation (boolean)
-network-synchronisation=1
+#network-synchronisation=0

 # Record directory (string)
 #input-record-path=
@@ -4527,7 +4527,7 @@
 #repeat=0

 # Play and exit (boolean)
-play-and-exit=1
+#play-and-exit=0

 # Play and stop (boolean)
 #play-and-stop=0
@@ -4545,7 +4545,7 @@
 #playlist-cork=1

 # Allow only one running instance (boolean)
-one-instance=1
+#one-instance=0

 # Use only one instance when started from file manager (boolean)
 #one-instance-when-started-from-file=1
@@ -4569,7 +4569,7 @@
 #preparse-timeout=5000

 # Allow metadata network access (boolean)
-#metadata-network-access=0
+metadata-network-access=1

 # Subdirectory behavior (string)
 #recursive=collapse
@@ -5295,7 +5295,7 @@
 #bookmark3=

 # Playlist bookmark 4 (string)
-bookmark4=file://gateway/mythtv/mp4/Les_Surhumains_-_Untitled_-_12.05.20.mp4
+#bookmark4=

 # Playlist bookmark 5 (string)
 #bookmark5=

 

[phofman]

I have near zero knowledge on digital audio technicalities. It's only a constatation, an undenyable fact.

Well, then something is incorrectly setup in your chain. Audio is processed in blocks, and the block size in samples determines the latency. Only some very CPU-intensive task could increase the latency (buffers + some CPU processing) but that would have to be quite a large load to be noticeable.

Re your VLC config - compressor setup? different volume settings?

 

[kysa]

On linux I tried to set the playback device format (audio card via pipewire) to 32 bits but the increased latency is too important for videos: audio and video are out of sync just enough to be distracting, in the bad sense. Back to 16 bits fixed the problem. There is latency too but it's supportable. For music, there is no noticeable audible difference anyway.

You can manipulate the audio delay using your media player of choice.

Analog audio crackling filter project.​

Why not simply disable interface suspend?

 

[kysa]

Well, then something is incorrectly setup in your chain. Audio is processed in blocks, and the block size in samples determines the latency. Only some very CPU-intensive task could increase the latency (buffers + some CPU processing) but that would have to be quite a large load to be noticeable.

Re your VLC config - compressor setup? different volume settings?

The problem is caused by too high 'high quality' resampling settings, most likely. I don't want to read the whole thread to simply find out the answer, but OP should switch from whatever he's using to pipewire.

 

[atomant]

Well, then something is incorrectly setup in your chain. Audio is processed in blocks, and the block size in samples determines the latency. Only some very CPU-intensive task could increase the latency (buffers + some CPU processing) but that would have to be quite a large load to be noticeable.

I don't see anything obvious. Latency is 17 msec for this video. Maybe it's because it's 60 fps. Most of my material is 24-30 fps.

2024-10-23 12:03:37.689 T:45      debug <general>: CActiveAESink::OpenSink - trying to open device PIPEWIRE:alsa-sink
2024-10-23 12:03:37.689 T:45      debug <general>: CPipewireStream::StateChanged - stream state changed unconnected -> connecting
2024-10-23 12:03:37.690 T:270     debug <general>: ScanForExternalSubtitles: END (total time: 4 ms)
2024-10-23 12:03:37.690 T:270     debug <general>: LoadItemLookup: trying to extract filestream details from video file /mnt/linux486/mythtv/1151_20230121040400.ts
2024-10-23 12:03:37.692 T:45      debug <general>: CAESinkPipewire::Initialize - rate: 48000
2024-10-23 12:03:37.692 T:45      debug <general>: CAESinkPipewire::Initialize - channels: 6
2024-10-23 12:03:37.692 T:45      debug <general>: CAESinkPipewire::Initialize - format: f32
2024-10-23 12:03:37.692 T:45      debug <general>: CAESinkPipewire::Initialize - samplesize: 4
2024-10-23 12:03:37.692 T:45      debug <general>: CAESinkPipewire::Initialize - framesize: 24
2024-10-23 12:03:37.692 T:45      debug <general>: CAESinkPipewire::Initialize - latency: 2400/48000 (0.017s)
2024-10-23 12:03:37.692 T:45      debug <general>: CAESinkPipewire::Initialize - waiting
2024-10-23 12:03:37.692 T:270     debug <general>: ffmpeg[0x561d899eed80]: [mpegts] Could not detect TS packet size, defaulting to non-FEC/DVHS
2024-10-23 12:03:37.692 T:270     debug <general>: Open - avformat_find_stream_info starting
2024-10-23 12:03:37.692 T:270     debug <general>: Open - av_find_stream_info finished
2024-10-23 12:03:37.692 T:270     debug <general>: ScanForExternalSubtitles: Searching for subtitles...
2024-10-23 12:03:37.692 T:12      debug <general>: CPipewireStream::StateChanged - stream state changed connecting -> paused
2024-10-23 12:03:37.693 T:45      debug <general>: CAESinkPipewire::Initialize - initialized
2024-10-23 12:03:37.693 T:45      debug <general>: CActiveAESink::OpenSink - PIPEWIRE Initialized:
2024-10-23 12:03:37.693 T:45      debug <general>:   Output Device : Alsa Loopback
2024-10-23 12:03:37.693 T:45      debug <general>:   Sample Rate   : 48000
2024-10-23 12:03:37.693 T:45      debug <general>:   Sample Format : AE_FMT_FLOAT
2024-10-23 12:03:37.693 T:45      debug <general>:   Channel Count : 6
2024-10-23 12:03:37.693 T:45      debug <general>:   Channel Layout: FL, FR, FC, LFE, SL, SR
2024-10-23 12:03:37.693 T:45      debug <general>:   Frames        : 2400
2024-10-23 12:03:37.693 T:45      debug <general>:   Frame Size    : 24

UPDATE

Got the Windows setup to 24 bits at last. The trick was to go step by step and reboot often which keeps windows happy. Since the audio card only supports 16/24 bits, it's really a bad idea to set the VAC to anything larger than 8-24 bits!

devices:
  adjust_period: 30
  capture:
    channels: 6
    device: Line 1 (Virtual Audio Cable)
    exclusive: true
    format: S24LE3
    labels:
    - FL
    - FR
    - FC
    - LFE
    - RL
    - RR
    loopback: null
    type: Wasapi
  capture_samplerate: null
  chunksize: 2048
  enable_rate_adjust: true
  multithreaded: null
  playback:
    channels: 6
    device: Speakers (ASUS Xonar D1 Audio Device)
    exclusive: true
    format: S24LE3
    type: Wasapi

 

[atomant]

Windows 7 Update

And it's a disaster.

After reconfiguring CDSP for 24 bits instead of 16, I had the bad idea to delete from the registry an entry for the CMI8738 in the control panel that wouldn't disappear.
After a reboot, strange things started. VLC started playing stereo sounds on all 6 channels and required a reset. No sound came out of Media Player Classic. Games like Silent Hill 2 and 4 crashed on startup. In short, everything that didn't use Wasapi or Waveout now refused to use the VAC! DirectSound looks broken.

I tried everything: reconfiguring CDSP for 16 bits again, removing the ASUS card and putting the CMI8738 back, reinstalling the CMI8738 drivers and uninstalling them properly, putting the ASUS card back and reinstalling the drivers, reinstalling the VAC, reinstalling DirectX, doing a few passes of 'sfc /scannow' followed by 'DISM /Online /Cleanup-Image /ScanHealth'. Nothing would fix it.

To continue playing my games, I have to set the Asus sound card to default card. Which defeats the purpose. I keep Windows 7 for gaming only and now I'm back to square one. No CDSP that works for games.

If you have a solution, I'd be happy to explore it.

Second point:

In https://github.com/HEnquist/camilladsp/blob/master/backend_wasapi.md it is mentioned that you can use a loopback. Does anyone have a real example of this, because I don't understand anything about it. I don't have a second sound card. I have a sound card with an analog output and a digital output. And I also have the VAC. In other words. in concrete terms, how do you do it? I thought to myself: if there's an issue with the current setup using the VAC as default card, maybe I could try that loopback option...

 

[HenrikEnquist]

In https://github.com/HEnquist/camilladsp/blob/master/backend_wasapi.md it is mentioned that you can use a loopback. Does anyone have a real example of this, because I don't understand anything about it. I don't have a second sound card.

Loopback capture in wasapi means you capture sound from a playback device. To use it with CamillaDSP, you would set a second (unused) sound card as the default device, and let CamillaDSP capture from that one in loopback mode. And then you configure CamillaDSP to play the processed sound on the device you actually want to listen to. You need a second sound card to make use of it.

 

[atomant]

Loopback capture in wasapi means you capture sound from a playback device. To use it with CamillaDSP, you would set a second (unused) sound card as the default device, and let CamillaDSP capture from that one in loopback mode. And then you configure CamillaDSP to play the processed sound on the device you actually want to listen to. You need a second sound card to make use of it.

Thanks Henrik,

Clear enough.

I re-activated the onboard SPDIF output as default device (loopback). I could see the VU meter moving in Windows sound. But CDSP didn't pick it up as capture device. Either a Win 7 issue (unsupported) or my system sound is too damaged.

Best!

 

[HenrikEnquist]

But CDSP didn't pick it up as capture device.

What do you mean by "didn't pick it up"?

 

[atomant]

What do you mean by "didn't pick it up"?

i.e. absolutely nothing happened. no activity in CDSP. like it wan't listening at all. all meters halted in the gui. nothing in the log.

 

[HenrikEnquist]

Seems like it won't work on win7. CamillaDSP uses event driven mode.

In versions of Windows prior to Windows 10 1703, pull-mode capture client does not receive any events when a stream is initialized with event-driven buffering and is loopback-enabled. To work around this, initialize a render stream in event-driven mode. Each time the client receives an event for the render stream, it must signal the capture client to run the capture thread that reads the next set of samples from the capture endpoint buffer. In Windows 10 versions 1703 and higher, event-driven loopback clients are supported, and no longer need the workaround involving the render stream.

From: https://learn.microsoft.com/en-us/windows/win32/coreaudio/loopback-recording