[mk9pa]

Hi everyone, newbie here.

This year's hobby effort is getting an RPi 3 being a high quality music player with JRiver MediaCenter and DRC. MC playback is going well and I'm working on integrating filters and/or convolution. So far I have been getting my feet wet with REW to generate filters.

At the moment I have run into an issue that appears to be REW-specific. I have a HiFiBerry DAC+ Pro running and JRiver MC outputs just fine to it. With REW, I can select the HiFiBerry as the output device in the Preferences window, but whenever I try to play something, either to check levels or do a measurement, the sound is output for about 1 second and then stops, and the output device selection is reset to "Default Device". REW stops as if the test is over after 1 second. This is 100% repeatable.

Note, the HiFiBerry is an I2S device, not USB or other interface, in case that is important. I don't see any messages in log files, including the REW log files under the REW directory.

Info:

$uname -a
Linux audiopi 4.4.47-v7+ #961 SMP Sun Feb 5 20:17:00 GMT 2017 armv7l GNU/Linux

$ aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: sndrpihifiberry [snd_rpi_hifiberry_dacplus], device 0: HiFiBerry DAC+ Pro HiFi pcm512x-hifi-0 []
  Subdevices: 1/1
  Subdevice #0: subdevice #0

$ cat .asoundrc
pcm.!default {
	type hw
	card 0
}

ctl.!default {
	type hw
	card 0
}

$ cat REW/roomeq_wizard0.log.txt
Feb 06, 2017 10:01:51 PM roomeqwizard.RoomEQ_Wizard main
INFO: REW V5.18 running JRE 1.8.0_65 32-bit on linux 4.4.47-v7+
Feb 06, 2017 10:02:03 PM roomeqwizard.CalData calFileLoader
INFO: Mic sensitivity -19.942 dB
Feb 06, 2017 10:02:10 PM roomeqwizard.CalData calFileLoader
INFO: Mic sensitivity -19.942 dB

Does anyone know if there is a way to find out why REW is resetting the output device selection?

 

[JohnM]

Sounds as if the device is disappearing from the available device list for some reason. Does the REW sample rate match the soundcard?

By the way, the mic cal file seems to be loaded twice - you don't have it specified in soundcard cal as well as mic cal, do you? That would double the corrections.

 

[mk9pa]

Sounds as if the device is disappearing from the available device list for some reason. Does the REW sample rate match the soundcard?

By the way, the mic cal file seems to be loaded twice - you don't have it specified in soundcard cal as well as mic cal, do you? That would double the corrections.

Hi John, thanks for the quick response!

Yes, that appears to be what is happening. After 1 second, the input device and output device are both reset to the default selection in drop-downs, and the level bars on the right side go dark. Actually, now that I've tried it many times, the time varies quite a bit, although it tends to be roughly 1 sec most often.

The sample rate dropdown offers me 44.1k and 48k and behavior is the same either way. The sound card runs at both rates and a few multiples higher.

I've disabled PulseAudio in case that was conflicting, and no change.

Running REW into a USB DAC works fine. That's a reasonable fallback for me if I can't get the HiFiBerry to work, and unlikely to cause much difference in results.

On a hunch that it might be related to insufficient power (I have been running the setup with a 2.5 A wall wart into the Pi's micro-USB connector), I brought home a heavy duty 6 A bench supply from work, set it to 5 V, and connected it directly to the HiFiBerry board, which in turn powers the Pi underneath. Same problem.

It does seem that I am getting two mic cals but I'm not sure why. The mic/meter page has a calibration file shown, but then when I start REW it asks me if I want to use the mic that's plugged in (a USB mic) and if I have a calibration file for it. I've always answered yes. That might be the two cals? What's the right approach for this?

I don't want to take your time if this isn't a REW-specific issue, vs. a general one. JRiver MC runs fine, so I thought maybe this is specific to REW and somebody here might know what to look for.

 

[JohnM]

If the mic is disappearing and reappearing during startup that might cause REW to ask for the file again.

 

[mk9pa]

I've tried running audio through the HiFiBerry as many ways as I could find. JRiver MC22 works fine (for hours). I tried installing SOX and ran:

$ play -c 2 -n synth sine 1000

which ran over 5 minutes without problems. Same with:

speaker-test -c 2 -D plughw:0
speaker-test -c 2 -D hw:0
aplay -c 2 -D hw:0 <file>.wav

Now, thinking my USB DAC (Schiit Modi) would work as it had previously, I disabled the HiFiBerry, rebooted, plugged in the Schiit, and find the same behavior: REW stops after about a second, but "play", "aplay", and "speaker-test" run as with the HiFiBerry. These are sources in both 44.1 and 48k sample rates, and the .wav file is over the network.

Java version: "1.8.0_65". REW log file same as before: nothing obvious:

Feb 08, 2017 9:35:26 PM roomeqwizard.RoomEQ_Wizard main
INFO: REW V5.18 running JRE 1.8.0_65 32-bit on linux 4.4.47-v7+
Feb 08, 2017 9:35:33 PM roomeqwizard.CalData calFileLoader
INFO: Mic sensitivity -19.942 dB

Not sure what to do next; REW is the one app that is not cooperating, now both over USB and on HiFiBerry.

 

[JohnM]

Likely Java-specific rather than REW-specific. Could try Oracle's latest JRE in case there have been any improvements there.

 

[mk9pa]

Likely Java-specific rather than REW-specific. Could try Oracle's latest JRE in case there have been any improvements there.

I tried a few Java versions, all available from the Raspbian repository:

Installed by default (oracle-java8-jdk): 1.8.0_65
Older Oracle version 7 (oracle-java7-jdk): 1.7.0_60
OpenJDK version 8 (openjdk-8-jre): 1.8.0_40-internal

The two Oracle Java versions are about equivalent in performance judging from the startup time and interactivity of REW. OpenJDK is far, far slower and essentially unusable. Running REW on OpenJDK 8 results in pops and crackles as the audio is simply not keeping up, not even close. CPU usage for Java alone is running around 280%. There's a note about the OpenJDK release being interpreted which may explain this.

But in all cases, the REW output runs for a second or two, stops, and the audio devices, both input and output, get reset to default. So it's likely something fundamental with the RPi, or a wide range of Java versions, or REW.

I tried a few recent Linux kernels including 4.4.38, 4.4.45, 4.4.46, 4.4.47, and 4.4.48, and all show the same behavior.

I also tried installing a number of REW versions: 5.15, 5.16, and 5.19 beta 2. In all cases the first run with a newly-installed version runs longer, 5-10 seconds, and then following runs show the same roughly 1-second run time.

 

[mk9pa]

Since things were not adding up, I completely rebuilt the Pi from ground up; reinstalled Raspbian and installed just the minimum additional to be able to get REW to run (which is very little).

I found a definitely factor in the issue I was observing before. The description of the audio devices in .asoundrc had a direct effect on whether this device reset happened or not. I do not have a fully repeatable set of conditions, but with the default .asoundrc specifying the audio devices as "plughw" (which utilize ALSA's conversion features, I think), I had the failures as described. By describing them as "hw" they worked.

I haven't experimented with all the parameters to see which one(s) have the most direct influence on the failure, so I can't say for sure which are the direct causes. I also am not at all familiar with ALSA and could certainly use some help from anyone who knows it better to determine the right settings, and why a particular set do or don't work.

My .asoundrc now looks like this, thanks to [a website whose URL I cannot post yet but search for "archlinux hw plughw alsa troubleshooting"]:

pcm.!default {
	type asym
	playback.pcm {
		type hw
		slave.pcm "hw:1,0"
	}
	capture.pcm {
		type hw
		slave.pcm "hw:0,0"
	}
}

ctl.!default {
	type hw
	card 0
}

 

[JohnM]

Don't know why that makes a difference but well done for tracking it down!