I'm very new to all this, but so far have successfully created an ALSA loopback to start at boot-up, and have directed CamillaDSP to capture from it. I get a few 'SetSpeed' debug messages, but otherwise cdsp seems to run happily.
However, I was expecting a loopback virtual device to appear in the desktop's sound settings, i.e. as another option to play to. But I still just see the hardware cards. I'm not sure if this is because my expectations are simply incorrect, or if it is because Debian now uses uses pipewire, or something else. So basically I don't even know how to direct audio into the loopback sink.
Before I spend yet more time trying to find my answers, could anyone possibly help to prod me in the right direction?
Thanks!
Kev
However, I was expecting a loopback virtual device to appear in the desktop's sound settings, i.e. as another option to play to. But I still just see the hardware cards. I'm not sure if this is because my expectations are simply incorrect, or if it is because Debian now uses uses pipewire, or something else. So basically I don't even know how to direct audio into the loopback sink.
Before I spend yet more time trying to find my answers, could anyone possibly help to prod me in the right direction?
Thanks!
Kev
I think you misunderstand the ALSA loopback. You are only making its creation possible by putting snd-aloop in modules or using modprobe. When you connect CamillaDSP to one of the create-able pipes, you are only connecting one end of the pipe to something (to CDSP). The other end of the pipe has been created, but is not connected to anything. This is why is does not "appear" anywhere else. It is waiting to be connected to something first, for example you could connect any audio source to it if that source can directly connect to an ALSA device.
The other issue is that when you create the loopback you are (typically) not setting any audio format parameters, e.g. rate and format. If you just connect CDSP to it without specifying these, CDSP gets the default rate and format programmed into ALSA, which is usually 44.1k and 16-bits IIRC. Once the loopback pipe has been connected you cannot change these audio format parameters later on. This means they will be fixed for the duration of the loopback pipe's existence. So make sure you invoke the loopback with which ever parameters you desire right from the beginning.
The other issue is that when you create the loopback you are (typically) not setting any audio format parameters, e.g. rate and format. If you just connect CDSP to it without specifying these, CDSP gets the default rate and format programmed into ALSA, which is usually 44.1k and 16-bits IIRC. Once the loopback pipe has been connected you cannot change these audio format parameters later on. This means they will be fixed for the duration of the loopback pipe's existence. So make sure you invoke the loopback with which ever parameters you desire right from the beginning.
Ah, thank you Carlie. You are quite correct, my understanding of the ALSA loopback is/was flawed; thank you for helping me to understand. I had at least set the rate and format in CDSP, if I understand correctly the first end of the pipe to be opened should also set the ALSA loopback. But I'd not grasped that the other end of the pipe wasn't going to magically appear as a sink.
I've now had chance to try Henrik's guidance on using pipewire (link in post #2) to offer an audio sink that the desktop can be set to use as default, which connects to the input end of my ALSA loopback. This has it's own parameters too; so far I've set these and CDSP to 44100 32-bit so that they hang together.
There is an adaptive plugin for CDSP by scripple but I've yet to look into that. So far applications seem to adapt to my pipewire sink parameters okay, as they would an actual soundcard. So perhaps I could just set these (and in CDSP) to high enough rates that nothing gets downscaled/downsampled.
I've now had chance to try Henrik's guidance on using pipewire (link in post #2) to offer an audio sink that the desktop can be set to use as default, which connects to the input end of my ALSA loopback. This has it's own parameters too; so far I've set these and CDSP to 44100 32-bit so that they hang together.
There is an adaptive plugin for CDSP by scripple but I've yet to look into that. So far applications seem to adapt to my pipewire sink parameters okay, as they would an actual soundcard. So perhaps I could just set these (and in CDSP) to high enough rates that nothing gets downscaled/downsampled.
I cannot avoid resampling in my own system, so I just choose a rate and format that I think will be best overall. Audio is resampled to that by PulseAudio and then stays in that format through the rest of the playback chain. I make sure to set up PulseAudio so that the resampler is a high quality one such as Soxr-vhq and use a 32-bit data format.
Thanks again, Charlie. Yes, that is the kind of approach I was thinking of, but your 'best overall' would be an improvement. I'd been imagining that a lot of headroom would avoid down-sampling in any eventuality. But actually the vast majority of the music I listen to is the exact same (CD quality), and the rest tends to be lower; I have very little at higher resolutions. So it could be much better to preserve my most common, native rate and bit-depth throughout and then let the remainder resample.
I'm a beginner with linux audio so will need to look into how my system resamples, and attempt to alter it if necessary. Should I begin to expand my higher-res collection then it certainly would become of great interest. Until now I've not paid much interest into how it handles already degraded lossy and low-rate formats, but perhaps i should as increasingly (and upsettingly) that is sometimes the best one can obtain for newer releases.
I'm a beginner with linux audio so will need to look into how my system resamples, and attempt to alter it if necessary. Should I begin to expand my higher-res collection then it certainly would become of great interest. Until now I've not paid much interest into how it handles already degraded lossy and low-rate formats, but perhaps i should as increasingly (and upsettingly) that is sometimes the best one can obtain for newer releases.
Lower? I would be surprised if there is currently any music available anywhere that is in a LOWER quality format than "CD-quality" (16bit, 44.1kHz). MP3 and other lossy codecs are typically converted back to this CD-quality level during playback.
IMO resampling gets a bad rap these days. It's like jitter - essentially a non-problem. When you use the best resampling algorithms (and why wouldn't you?) available via computer audio processing then there is essentially no/zero/zilch/nada degradation for one pass of the algorithm. If you lose sleep at night because someone showed that when you take the an audio track and pass it through the resampling algorithm 100 times it generates audible effects, than you need to seek professional help (you, the random reader of this post, not you Kev06) because that will never happen.
Based on what I wrote above, I resample everything to 24/96. 24 bits provides flexibility to scale the playback volume digitally without losing audible bits. 24 bits is much more dynamic range than pretty much ANY amplifier (range between the noise floor and maximum playback level) and many "24bit" DACs in reality do not have much more than 20 bits of S/N anyway (see: https://www.eevblog.com/forum/projects/32-bit-dac-is-that-even-possible/). 96kHz gives you a useful amount of "frequency room" between 20kHz and the Nyquist frequency. Digital filters often show some warping near Fs/2 and for 96kHz you get a whole 28kHz between frequencies that you can hear and Fs/2, which puts any deviations in the filter response far above the hearing range. In contrast, at 44.1kHz this "room" is only between 20k and 22.05kHz, which is not much or enough. Really high sample rates like 192k+ Hz are just stupid IMO, and so is high rate DSD. Frequencies in digital audio are split up or discriminated on a LINEAR not logarithmic scale. As an example, for a sampling rate of 96kHz already more than HALF of the frequency range that the digital audio can encode is essentially wasted because it is above the human hearing range. When you make the rate even higher, this "wasted" band just gets larger with no change to the band up to 20kHz! There is no need to have better "time resolution" by using very high sample rates. That is just not how hearing works. End rant.
IMO resampling gets a bad rap these days. It's like jitter - essentially a non-problem. When you use the best resampling algorithms (and why wouldn't you?) available via computer audio processing then there is essentially no/zero/zilch/nada degradation for one pass of the algorithm. If you lose sleep at night because someone showed that when you take the an audio track and pass it through the resampling algorithm 100 times it generates audible effects, than you need to seek professional help (you, the random reader of this post, not you Kev06) because that will never happen.
Based on what I wrote above, I resample everything to 24/96. 24 bits provides flexibility to scale the playback volume digitally without losing audible bits. 24 bits is much more dynamic range than pretty much ANY amplifier (range between the noise floor and maximum playback level) and many "24bit" DACs in reality do not have much more than 20 bits of S/N anyway (see: https://www.eevblog.com/forum/projects/32-bit-dac-is-that-even-possible/). 96kHz gives you a useful amount of "frequency room" between 20kHz and the Nyquist frequency. Digital filters often show some warping near Fs/2 and for 96kHz you get a whole 28kHz between frequencies that you can hear and Fs/2, which puts any deviations in the filter response far above the hearing range. In contrast, at 44.1kHz this "room" is only between 20k and 22.05kHz, which is not much or enough. Really high sample rates like 192k+ Hz are just stupid IMO, and so is high rate DSD. Frequencies in digital audio are split up or discriminated on a LINEAR not logarithmic scale. As an example, for a sampling rate of 96kHz already more than HALF of the frequency range that the digital audio can encode is essentially wasted because it is above the human hearing range. When you make the rate even higher, this "wasted" band just gets larger with no change to the band up to 20kHz! There is no need to have better "time resolution" by using very high sample rates. That is just not how hearing works. End rant.
Far from a rant, I found it extremely useful; thank you! Yes I'm happy enough with resampling during playback, but lacked the factual detail needed for making the best decisions and choices. Thanks to your post, I can see these in much clearer context, now; superb stuff!
I will need to examine how the PC goes about resampling its various formats and sources. Some of them don't matter much, such as already degraded low-res internet stuff. But others, such as playing my local FLAC library (of CD-rips), are going warrant some attention.
I will need to examine how the PC goes about resampling its various formats and sources. Some of them don't matter much, such as already degraded low-res internet stuff. But others, such as playing my local FLAC library (of CD-rips), are going warrant some attention.
I use the Alsa Loopback device and pipewire without any problems.
see here
https://www.diyaudio.com/community/...studio-pipewire-and-calf.404960/#post-7509784
and here
https://www.sdrutah.org/info/high_rate_loopback_websdr.html
see here
https://www.diyaudio.com/community/...studio-pipewire-and-calf.404960/#post-7509784
and here
https://www.sdrutah.org/info/high_rate_loopback_websdr.html
Thank you for those links, you provide more detail than I'd previously found on the loopback- especially on the various options that can be applied to one. The other post is also very interesting; you have an impressive configuration there. Probably my needs are less extensive, but I have also been considering a small dedicated machine for this role, so what you have done there is quite inspiring.
I've been using an alsa loopback with pipewire and CamillaDSP for a few weeks now with generally good success. There is one oddity: occasionally I must turn my (debian) PC's LAN connection off and on again to regain internet access. I haven't yet had chance to narrow down the conditions under which this occurs though (e.g. only when internet streaming, only with loopback+CamillaDSP or only with them both), so it may not be related.
I've been using an alsa loopback with pipewire and CamillaDSP for a few weeks now with generally good success. There is one oddity: occasionally I must turn my (debian) PC's LAN connection off and on again to regain internet access. I haven't yet had chance to narrow down the conditions under which this occurs though (e.g. only when internet streaming, only with loopback+CamillaDSP or only with them both), so it may not be related.