unreliable impedance measurement

[jschwender]

I noticed that sometimes impedance measurement shows crazy, impossible results. I reproduced this by just repeating the same mesurement over and over without changing anything.
I would expect to get always the same results, but that does not happen:
The upper curve are measurements that are correct, repeated several times.
Then suddenly the result of the lower curve is plotted.

INFORMATION: REW V5.20 running JRE 1.8.0_292 64-bit on Ubuntu linux, Kernel 5.12.7-xeon, de, DE, UTF-8, Soundcard is a Xonar U7.
Is there an explanation? Has anyone else seen similar bugs?

 

[John Mulcahy]

Most likely is a dropout during the audio capture, if you look at the "Captured" graph after a measurement you may see a section of missing data.

 

[jschwender]

ok, right: In these cases the capture is empty! But how does that come? Any idea?

 

[John Mulcahy]

The capture graph only shows data for the last measurement that was made, you need to check it immediately after seeing a problem.

 

[jschwender]

I still could not find the cause. And it is not only impedance measurement, it is also on other measurements. if i just run measurement after measurement, i get more failures than successes. If i check the capture, it is never empty, but in case of failure it looks strange. The only way i found out to get reliable results is to start the measurement, abort it, and run it again within 1…2 seconds. This way i would say results are reliable. I notices that also the small input monitor in the measurement windows shows if it works ok or not. In case of defect it looks like this:

And if i interrupt it and start again it looks like this:

That shows the proper level, and the measurement result looks like expected. I investigated if it is a hardware issue: hooked up a oscilloscope parallel to it but the hardware side works as expected, all levels are normal. Whatever i do with the sound card either from pulseaudio or alsa level, the sound card never ever showed any unexpected behaviour, i would say it perfectly ok.
I played around with different java versions: Ubuntu i have comes with version 11 default, but 1.8.0 can be installed in parallel. Comparing both versions revealed that with version 11 the percentage that leads to failures is clearly higher. With 1.8.0 it is much better, but the failures still occur from time to time. So that issue is not solved for me. Please comment.

 

[John Mulcahy]

The second image shows heavy clipping of the input, that can't be the "proper level" image, can it? Are the images the wrong way around? Do you get more reliable results at lower sample rates?

You could try increasing the memory available to Java by editing the roomeqwizard.vmoptions file and increasing the -Xmx figure, e.g. -Xmx2048m for 2GB.

 

[jschwender]

It is close to, but it is not clipping. I will test sample rate and vmoptions.

 

[jschwender]

vm memory, buffers, sampling rate do not make any difference. The only difference that i can find is that it works reliably on my desktop pc Ubuntu 20.10, and that it mostly fails on my lab laptop, which uses Ubuntu 21.04. They both run the identical vanilla kernel, but i tried also with standard kernel, that does not help. Sometimes i see on both machines error messages at starting rew, saying javax.sound.sampled.LineUnavailableException. Then i close rew and repeat until it works. To me that looks like rew tries to access sound via pulseaudio, imho that is not so good because you can never be shure that there is no re-sampling or scaling involved. is there a way to force alsa? My impression is, that measuring without timing reference has higher failure rate. If i get it to work by interrupting and restarting, there is a little slope in the input monitor. If this slope is visible, the sampling works. If this slope is invisible, the sampling fails. What is the explanation for the slope, that is not the acoustic timing reference, right?

 

[John Mulcahy]

I don't have a Linux environment, so difficult to comment on what might be going wrong. It almost looks like a byte ordering or sample data alignment problem. Altering the default format might help, some discussion in this thread.

I did recently receive an email from another Ubuntu user (Stefano) who had been having problems with V.19 that may be relevant:

In Ubuntu MATE 18.04 I had to make several changes (I forget exactly
what) because pulseaudio would hold all the audio devices it knew about
open and would prevent other programs from using alsa.

After upgrading to Ubuntu MATE 20.04, the behaviour is much more
reasonable. Basically REW can use the alsa device now *if* pulse audio
is not using it. Using it though may mean different things. Simply
having VLC open hogs the audio device. Whereas the UI sounds use the
audio device on demand.

Also, the "default" device on alsa is plumbed into Pulse audio and
works. To use it in REW, you just need to select the "default
[default]" device. The "Default Device" (?) doesn't work (no audio).
The "PulseAudio Mixer" (icedtea) doesn't work (no audio). The
attached screenshot shows the right option. As I recall, this option
didn't work in 18.04, but I can't test it to be certain. Perhaps it
did and I missed it.

The current behaviour gives the most flexibility now. Happy they fixed
this in 20.04. As I said before everything worked fine in 16.04,
nothing worked in 18.04, and everything seems to work fine in 20.04.
Fingers crossed it stays that way.

If anyone else on linux has problems relating to playback through
pulseaudio, you might want to suggest using the "default [default]"
device. Curiously, the "Default Device" works fine with recording and
uses the PulseAudio selected device.

 

[jschwender]

Thank you for your support, i appreciate that a lot.
I think i found a work-around without utilizing pulseaudio: It looks like a problem when rew starts up. In case i get failures, right after the start the status line looks like this:

16 bit do not make sense!. I wrote a little script that does all necessary settings to alsamixer. If i run that prior to start rew, i get reliably good results, and the status line after start up looks like expected:

this is the script:
CARD_ID=U7
amixer -D "hw:$CARD_ID" set 'Mic' nocap # Line input ON
amixer -D "hw:$CARD_ID" set 'Line' cap # Mike OFF
amixer -D "hw:$CARD_ID" set 'PCM Capture Source',0 'Line' # Line as source
amixer -D "hw:$CARD_ID" set 'Input Gain Pad Control',0 1,1 # In/Out gain to 50%
amixer -D "hw:$CARD_ID" set 'PCM',0 0db # PCM output to 100%
I know that "Input Gain" is overridden by rew during start up, but left it in despite that.

• Advantage of directly accessing alsa is that you know for sure there is no conversion in the stream.
• Disadvantage is that access to alsa is blocking, so that if it is utilized by another application this one blocks it for rew.
• Advantage of pulseaudio is that it is non-blocking.
• Disadvantage of pulseaudio is transparent conversion, so you can pull a 32 stream from an 8 bit webcam-audio, of course with 8 bit quality, but it does not complain. That is a nice feature for listening, but i think not for measuring.

Therefore, my question if it is possible to force alsa for rew?
greetings

 

[John Mulcahy]

The sources of audio data are determined by the mixer providers defined in the Java runtime. I'm not sure there is a way for REW to distinguish between PulseAudio and Alsa mixers if both are provided, if you use the Generate Debug File... button on the REW soundcard preferences you can see all the info REW can access about the audio sources.

 

[jschwender]

Here is what i still can reproduce:make impedance measurement, repeat it over and over and look each time to the captured. I noticed that the channels (input and ref) are sometimes swapped, sometimes not, and that makes results look odd sometimes. If i do the tests with interrupting and then start again, it seems not to behave like that. Any idea why that could be?

 

[John Mulcahy]

Not really, perhaps some stream dropout results in sample misalignment since the data has left and right channels alternating.

 

[jschwender]

Sometimes i have seen error messages saying "misalignment by 1 sample" detected. But not as often as i see those failures. I also noticed, that this channel swapping sometimes happens by running the RTA measurement.