Why not "support" resampling for mic measurements?

[Quickmcj]

Hi

I have tried searching on Google, REW Help section, Minidsp and the forums with no luck.

I use pipewire to resample every output to 192kHz at the moment (Will likely use 96kHz later on).

When using the UMIK 1, it has a locked sampling frequency of 48kHz.

As the difference is an exact factor of 4, why are we not happy about this configuration, and instead "insist" to have the output run at 48kHz as well, when doing speaker measurements? Is it because we do not know the millisecond delay added from resampling (so that phase/time is completely off in measurements), or what are the exact reasons? I would imagine some kind of resampling scale factor in REW, to account for any OS resampling.

I would rather not have to change sampling frequency on the output, if I have made and implemented 96kHz FIR/impulse response filters, implemented in CamillaDSP, etc. Other option would be to buy UMIK 2, but that seems like overkill for that particular issue.

Maybe I am missing something obvious.

Kind regards
Michael

 

[John Mulcahy]

Input and output data need to be at the same sample rate to calculate the transfer function. Difficult to see the point of upsampling the mic data since there wouldn't be anything past 24 kHz anyway.

 

[Quickmcj]

Input and output data need to be at the same sample rate to calculate the transfer function. Difficult to see the point of upsampling the mic data since there wouldn't be anything past 24 kHz anyway.

Hi John, thanks for answering.

This would be purely for compatibility and convenience, as people run their systems at many different samplerates. If you use the Umik 1, you would need to reconfigure a number of configuration files for pipewire and Camilladsp, to change sample frequency on the whole system and be able to do measurements in REW (with that mic). If you have made FIR filters for another sample frequency than 48kHz, you cant use these filters during measurements or you need to resample them "manually".

If you have pipewire or alsa resampling the input from the mic (which I think is what is currently happening, as I can select 192kHz in REW with Umik 1 on plughw:4,0 and see input SPL), I guess a scaling factor in REW would be the "only" thing needed, to adjust samples accordingly, so transfer function is correct and measurement data is shown correct in plots.

I do not know if it is preferable to have the OS doing the resampling, or have REW do it on input/output.

Basically that would make Umik 1 act as a poor mans Umik 2, which supports multiple sampling frequencies. I (think) the majority of measurement microphones on the DIY market, is Umik 1.

You will be the judge if this is a beneficial feature for REW or not

And as always, many thanks for your hard work.

Kind regards Michael

 

[phofman]

@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

 

[Quickmcj]

@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

 

[ddude003]

I may not fully understand what/why you are asking for this feature... And I think this is something that is or can be handled by your convolution engine... For instance the Hang Loose Convolver uses r8brain resampling to upsample and match FIR files to incoming music data rates on the fly... So, I just create 44kHz and 48kHz wav files and let the Hang Loose Convolver do the rest...

 

[phofman]

Michael, I am glad you are getting forward fast. If PW works for you, very good. Alsa device plughw:XX should resample from/to any rate (due to the universal plug plugin), but PW does the same too, nice.

 

[Quickmcj]

I may not fully understand what/why you are asking for this feature... And I think this is something that is or can be handled by your convolution engine... For instance the Hang Loose Convolver uses r8brain resampling to upsample and match FIR files to incoming music data rates on the fly... So, I just create 44kHz and 48kHz wav files and let the Hang Loose Convolver do the rest...

Yes I looked at HLC some time ago, but missed that it is actually resampling the FIR filters on the fly. I do prefer using and supporting CamillaDSP. I am OK with resampling everything as long as quality is high (https://src.infinitewave.ca/) If current setup create new problems, I might switch to HLC.

 

[Quickmcj]

Michael, I am glad you are getting forward fast. If PW works for you, very good. Alsa device plughw:XX should resample from/to any rate (due to the universal plug plugin), but PW does the same too, nice.

I would prefer the purist way (ALSA) but I just do not got the time or chops for it, it seems After a short "messing with linux audio" recuperation period, I might give it a go again. The guy behind PW seems extremely capable, so I am currently placing my trust in him. That said, I do see something weird in current REW measurements which fluctuates, not yet knowing if its user error, PW, REW or something else going on. Will create a new thread for that issue and do experiments.