@Quickmcj : IIUC you want to run REW at 192kHz so that it generates filter configs at that samplerate, right? If so, then IMO you should be able to capture your 48kHz-only mike at 192kHz using alsa built-in resampling. Either plughw:CARD (as you noted), or defining a device with hard-coded rate in .asoundrc and selecting it with PCM:devicename in REW.
You can fine-tune the alsa-lib resampling algorithm with
https://github.com/Themaister/alsa-plugins-rsound/blob/master/doc/samplerate.txt or
https://github.com/Themaister/alsa-plugins-rsound/blob/master/doc/speexrate.txt
Hi phofman
Many thanks for your valuable contributions to multiple important topics, on many many different forums online through the years. There is no way people would learn things like these as fast, if your contributions where not there to find. Also thanks for your contributions to camilladsp and possibly REW.
Basically what this is, is me learning Pipewire, Wireplumber, Pulse Audio (pipewire emulation) and ALSA, combined with how REW works in Linux via Java sound engine.
I would not lie if I say that I have spent 50-100 hours trying to understand how the above interact, half parts reading documentation, half parts trying things out on my system and debugging. Fairly difficult when combined with work and family life! Have had a lot of fun with quantum.limit, buffers, period sizes, chuck size, rate adjust, samplerate, etc.
My findings are something like this:
- Work with ALSA if you read most of the documentation and have a deep understanding on what is going on. Its nice that you can interact directly with the hardware, its not nice if you do not know what you are doing, as it can be complex and difficult for a novice to debug. I would not advise it for novice users wanting to forward audio from several applications (Tidal client, qobuz in browser, REW) etc. Some applications show hardware devices directly, some dont, some show everything (hardware devices, PCM devices, Pulse Audio devices which may control said hardware devices) and some only use "default device" with no direct option to change it.
- Dont work with Pulse Audio as it is dead.
- Learn Pipewire. Pipewire is in itself pretty confusing, will require setup in (at least) three configuration files if you want to use resampling for any random application (including pulse audio applications), will require possible knowledge of wireplumber and Lua scripts. If using pipewire, do not touch anything related to ALSA directly at all and do not let applications interact with hardware devices directly. Its confusing if its Pipewire or ALSA which are in control/in use. Pipewire should be the go to audio server/framework for novice users, even though it can still be a steep mountain to climb and let ALSA be something pipewire interacts with in kernel.
- If phofman, John or HEnquist, remove pipewire and wireplumber service and use ALSA directly.
Initially, REW was not happy if I selected "default device" (which was the UMIK 1 in Gnome sound settings default device, which only uses pipewire when active), I got no input on SPL meter, so I pointed REW directly to the hardware plug device, which had no resampling apparently. With some magic dust, a reboot and a beer later, REW is working properly with "default device" (or "alsa_playback/capture.java" also, which I assume amounts to the same) on input, and do not care if I select 48kHz or 192kHz, as pipewire will handle the resampling (both input and output, have highest quality enabled). Have removed any custom alsa configurations. REW is still finicky with selecting UMIK 1 as default device at 192kHz, but it will work.
REW often tries to fall back to plughw as input device instead of using "default device" during its UMIK 1 discovery. Will often give following error when doing so: (Edit: Dont press "Yes" when discovering Umik 1 during REW boot)
javax.sound.sampled.LineUnavailableException: U18dB [plughw:2,0] does not have any lines supporting PCM_SIGNED 192000.0 Hz, 24 bit, stereo, 6 bytes/frame, little-endian
Attached files are dumps from pw-top, showing its resampling the UMIK 1 (and I assume its pipewire and not ALSA doing that).
Unless you guys tell me otherwise, the only thing to do now, is to make sure that the (hopefully more or less) fixed time-delay in the measurements are corrected, so that phase-information is trustworthy. Which is a feature John already have in REW.
If you see something completely out of the ordinary let me know.
Kind regards Michael