The principles are identical, also the device capabilities. ASIO/wasapi exclusive is just as unforgiving as alsa hw:X - you have to use only stream parameters supported by the device/driver.
If you tried running the loopback CDSP on windows with wasapi exclusive or asio, you would be hitting the very same issues as in linux.
Question: the device can handle lots of in's and out's but to see al of the unused channels in the plot, dis not very comfortable.
Is there a way to show only channels used in the mixer?
Is there a way to show only channels used in the mixer?
I got a question about high-Q IIR, specifically for BM. I am using CamillaDSP 3.0.1 on a Mac mini M1 and 2 Okto dac8pro's. One of the dac8pro is handling the subwoofer output, and the BM is running on one of the CamillDSP instance before Dirac Standalone Processor.
After playing something, but not always, I hear a low-level sound like soft tapping or bubbling from my SVS SB13 Ultra. So far with the testing, it never happened before the BM on Camilla running. After it started happening, it almost never goes away(only once so far). Killing and restarting CamillaDSP never helped yet. Even turning off/on the dac8pro with the front UI(not power cycle), the sound went away then come back with the unit back on. This is very confusing.
The S/W suspect in my mind is the very high-Q IIR LPF for BM. It's around 40~100Hz @ 96kHz Fs. But DP computation in theory should clear out the 32-bit output going to the DAC...
Anyone care to suggest a theory or test method?
After playing something, but not always, I hear a low-level sound like soft tapping or bubbling from my SVS SB13 Ultra. So far with the testing, it never happened before the BM on Camilla running. After it started happening, it almost never goes away(only once so far). Killing and restarting CamillaDSP never helped yet. Even turning off/on the dac8pro with the front UI(not power cycle), the sound went away then come back with the unit back on. This is very confusing.
The S/W suspect in my mind is the very high-Q IIR LPF for BM. It's around 40~100Hz @ 96kHz Fs. But DP computation in theory should clear out the 32-bit output going to the DAC...
Anyone care to suggest a theory or test method?
I see what you mean and agree... but in most cases you don't need to adjust for eg. count of in- and outputs... its handled by the driver. so i never get in touch by the need to configure this hardware wise 😉
Choosing the right interface normaly result in the fact, that the software already knows these parameters by itself.
What i am wondering now is, that with this hw without plug i can use only fs up to 48kHz, what is correct by using all channels on ADAT... but SPDIF is supporting more on this device... but that's something i can live with 😉
How high Q? And what is BM short for?
If you can hear the noise then it's at a fairly high level, far above any normal noise floor. Do you see anything on the camilladsp input and output level meters?
There is no way at the moment but I agree that doesn't look very good. I'll think about if something could be done.
Don't recall the formula at the time... It's 40Hz Fc LR4 LPF @ 96kHz Fs. I meant bass management with BM.
I don't know how to check I/O level meters(used only with text interface), but will find out and report tonight.
Actually my experience with direct windows access (ASIO, WASAPI Exclusive) is almost identical to linux. IME direct access to the driver does not adjust channel count etc., the client (player software) must use supported values only. In addition to this, in WASAPI Exclusive the client must also guess supported channel mask which is a major PITA - see e.g. https://github.com/pavhofman/csjsound-wasapi#detected-formats or https://www.avnirvana.com/threads/v5-20-12-v5-20-13-release.11029/post-85053
How would the software know? In fact there is no API in WASAPI for reporting supported parameters, only method isFormatSupported which needs to be called with every possible combination of channel count, sample length, sample rate, AND channel mask. It's a major deficiency of that API, IMO. Of course in WASAPI Shared basically any parameter works, because the windows mixer accepts any, just like the plug plugin in alsa (plughw:xxx). Of course then the mixer must use only supported params when talking to the sound driver, letting user select a combination from the supported values (learned via repeated questioning the device, unless it uses some undocumented API).
In ASIO and alsa there are methods to ask the driver about supported parameters of the device. But CDSP does not use them, it lets user specify the details exactly (which IMO is the correct way, in this particular case).
BTW it's likely your soundcard supports more samplesize/channel/rate combinations than the one chosen by the plug plugin (34 channels). Check file
/proc/asound/CARD_NAME/stream0 which will tell you many very useful details about your USB audio device. You will not find any report like that in windows, BTW 🙂A question:
I haven't installed any driver, so where is this folder with hardware-information coming from?
Is this something what happens automatically from Linux?
uhhh...
Does it mean, i have to change numbers of input/outputs when i want to use higher sampling rates than 48kHz without plug?
Good question. Drivers are part of linux kernel, in fact a majority of the kernel source code and commits are drivers, the actual core is quite small.
The kernel including the drivers is open source. As a result each driver is not written from scratch, but built on top of core facilites provided by the particular driver subsystem. Alsa (sound) drivers all use low-level alsa driver infrastructure which provides standardized API to userspace but also standardized reporting features - e.g. most of the files in /proc/asound. Every alsa soundcard driver (be it USB audio, PCI-e, HDA, virtual loopback device, etc.) has these and their authors did not have to do anything for that, it's provided by the alsa driver core.
Since windows has no such infrastructure for driver authors, every driver is different and no common reporting is available.
Your soundcard is more or less standard UAC2 device. Since the UAC2 standard is rather incomplete and does not cover the pecularities of digital inputs (incoming master clock, changing incoming rate), good UAC2 devices with SPDIF/ADAT inputs which want to provide important info to the driver/client have to use additional proprietary controls. And the patches sent to 6.12 add support for these additional controls on top of the basic UAC2, so that the soundcard can be used properly.
From the infrastructure POW - the alsa UAC1/UAC2 driver (built on alsa driver core, of course) is extended with many quirks for various soundcards - see https://github.com/torvalds/linux/blob/master/sound/usb/mixer_quirks.c , https://github.com/torvalds/linux/blob/master/sound/usb/quirks-table.h . In 2024 volunteers added support for Digiface to the quirks, see e.g. https://github.com/torvalds/linux/commit/c032044e9672408c534d64a6df2b1ba14449e948 , https://github.com/torvalds/linux/commit/611a96f6acf2e74fe28cb90908a9c183862348ce (most likely through painstaking reverse engineering captured USB communication with the windows driver) - see the commit series post https://lkml.iu.edu/hypermail/linux/kernel/2409.0/00330.html
Last edited:
Yes, it's described in the Digiface manual in detail. That's why you were limited to 48kHz max with your config. Use fewer channels (as reported by that file) and the card will accept higher samplerates (there is a total bandwidth limit on each USB isochronous transfer).
The stream0 virtual file is generated by the alsa usb driver, for every USB soundcard. It basically prints out in a nice audio-specific form the USB configuration descriptor which every USB device sends to the host during enumeration. The device has identical capabilities on any OS - that's why you would face the same issues in windows if directly accessing the driver, without any "alignment" layer like the windows mixer. Just in linux you have a chance to learn these important device details - and now you know how 🙂
Ok, then it's time to start looking at the camilladsp logs. Please set it to debug level and run until the problem appears. And then post all of it, doesn't matter if it's megabytes.