REW fails to output audio to linux pulseaudio_dnla device.

[oomzay]

Configuration: REW V5.30.2 / Linux Mint / Laptop

Use case: Using REW to perform calibration of moOde-based audio systems. An extremely convenient way to output audio from a (linux) host to a moOde server is via DLNA by using pulseaudio_dnla to map the moode DLNA server as the default audio device. I have this audio path working reliably with the standard linux speaker-test application.

Problem: When generating output with REW Generator the audio is sent to the local built-in speakers not the default, moOde DLNA device.

There is some ongoing activity in the pulse audio log whilst the REW audio plays on the local (builtin) speakers:

01-03 18:15:19 pulseaudio_dlna.pulseaudio INFO on_new_playback_stream "/org/pulseaudio/core1/playback_stream104"
01-03 18:15:19 pulseaudio_dlna.pulseaudio INFO on_playback_stream_removed "/org/pulseaudio/core1/playback_stream104"
01-03 18:15:19 pulseaudio_dlna.pulseaudio INFO on_new_playback_stream "/org/pulseaudio/core1/playback_stream105"
01-03 18:15:19 pulseaudio_dlna.pulseaudio INFO on_playback_stream_removed "/org/pulseaudio/core1/playback_stream105"

But this does not follow the pattern of successful playback via the speaker-test application. An example of successful playback:

01-03 17:12:08 pulseaudio_dlna.pulseaudio INFO on_new_playback_stream "/org/pulseaudio/core1/playback_stream98"
01-03 17:12:09 pulseaudio_dlna.pulseaudio INFO _async_handle_sink_update /org/pulseaudio/core1/sink3
01-03 17:12:09 pulseaudio_dlna.pulseaudio INFO Instructing the device "Dairy (DLNA)" to play ...
01-03 17:12:09 pulseaudio_dlna.plugins.dlna.renderer INFO Device state is stopped. Sending play command.
01-03 17:12:09 pulseaudio_dlna.pulseaudio INFO The device "Dairy (DLNA)" is playing.

This may well be due to some pulse device or moOde configuration. I am not familiar with debugging such problems.

Are there other diagnostic logs I should be looking at?

Thanks.

 

[phofman]

Pulseaudio javasound connector may not implement all PA API features correctly. It's not part of standard openjdk distribution https://github.com/openjdk/jdk/tree...06c52/src/java.desktop/linux/native/libjsound , but outsourced in the IcedTea JDK patches, many many years old.

If the speaker-test app works OK on your setup, you may try playback to PCM: default device in REW, instead of to pulseaudio. The speaker-test app uses the "default" alsa device too which on PA-enabled linux distributions points to the pulse alsa plugin -> PA -> default PA device.

 

[oomzay]

Thanks for the hints. I tried setting REW Output Device to "Default Device", "PCM:default", "default [default]" all without any success.

I really need to get a handle on how to visualize/debug what is going on in pulse/alsa etc. What black-hole is the REW stream7 going into? Why is it behaving differently to other applications?

Youtube/Firefox & speaker-test all play happily and reliably via DLNA by default.

 

[phofman]

What is "without any success" specifically?

IIUC the chain with REW for some reason refuses the DLNA playback device and switches the stream to another device. Is that the case?

Verbose PA logs would likely tell more, e.g. https://wiki.ubuntu.com/PulseAudio/Log

 

[oomzay]

After a reboot of the linux host REW "PCM: default" and "default [default]" both map to the DLNA device. So this issue has resolved itself for now.

I am not clear how/why a reboot fixed things, as this isn't windoze, but I will enable the pulse logging if the issue reappears.

I did notice that several more "PCM: *" devices appeared in the REW dropdown list after the system reboot. May be this is a clue as to what changed.

Thanks for you input.

 

[phofman]

After a reboot of the linux host REW "PCM: default" and "default [default]" both map to the DLNA device. So this issue has resolved itself for now.

Interesting. Did your speaker-test and REW tests run under the same user? PA is by default configured to run under logged-in user starting X session, there could be some permission issues which were fixed by re-logging upon reboot. Just guessing...

I did notice that several more "PCM: *" devices appeared in the REW dropdown list after the system reboot. May be this is a clue as to what changed.

Hm, that would suggest there were some changes to alsa configs/audio devices during the previous logged-in session which got through upon re-logging. Probably not important anymore...

Thanks for you input.

You are welcome. I guess very few people use REW -> PA, let alone DLNA output :-) Did you check PA does no resampling or changes to your REW-generated data? Does your DLNA transfer use bitperfect codecs (wav/flac)?

 

[oomzay]

I guess very few people use REW -> PA, let alone DLNA output

Provided that the quality is preserved this seemed to be the simple/natural way to get audio from REW into the moOde system under test
and I would be surprised if others don't want to do this. I.M.O., at ~£50, the rPi4 is a game-changer for active speaker systems as it can run complex EQ and crossovers with ease and output up to 8 digital channels over HDMI.

Does your DLNA transfer use bitperfect codecs (wav/flac)?

I just assumed it would, but now I am not sure ...

 

[oomzay]

pulseaudio dlna help is encouraging...

-c --codec=<codecs> Set the audio codec.
Possible codecs are:
- mp3 MPEG Audio Layer III (MP3)
- ogg Ogg Vorbis (OGG)
- flac Free Lossless Audio Codec (FLAC)
- wav Waveform Audio File Format (WAV)
- opus Opus Interactive Audio Codec (OPUS)
- aac Advanced Audio Coding (AAC)
- l16 Linear PCM (L16)

...now have to see what actually works.

 

[oomzay]

Well at least wav16 is working. I'll see if I can configure wav24. Not clear what depth REW wants to output?

 

[phofman]

IMO all the wav encoder backends are configured at 16 bits https://github.com/masmu/pulseaudio...9daec411023ab0/pulseaudio_dlna/codecs.py#L217

 

[oomzay]

So it looks like pulseaudio wav is fixed at wav16 at the moment - but pulseaudio just calls sox encoder so I could hack the call or add a "rule" to set the bit-depth.

Anyway I think we can say that this thread has served its purpose: If anyone encounters issues outputing from REW to a dnla device after installing pureaudio_dnla - try a reboot.

 

[oomzay]

IMO all the wav encoder backends are configured at 16 bits https://github.com/masmu/pulseaudio...9daec411023ab0/pulseaudio_dlna/codecs.py#L217

Yes. This is where I was going to hack (or make configurable): https://github.com/masmu/pulseaudio...seaudio_dlna/encoders/generic.py#L42C1-L53C27 & https://github.com/masmu/pulseaudio...aec411023ab0/pulseaudio_dlna/recorders.py#L32

 

[phofman]

IMO the PA needs to be told to send appropriate high-resolution format to this python code. Also DLNA may have some metadata signalling where details are requested (I do not know the DLNA protocol), something around https://github.com/masmu/pulseaudio...aec411023ab0/pulseaudio_dlna/recorders.py#L37 . IMO it will not be trivial...

 

[oomzay]

Yes, I saw that bit of code .. feels like pulling on a piece of string ... I'll carry on for a bit...

How bad would 16bit be with REW? Many recording are only 16bit!

 

[phofman]

It really depends on your needs. For acoustic measurements 16bits should be enough, for measuring electronic gear params 24bits would be useful.

 

[oomzay]

Gonna stop banging head against this wall for a bit - and try a different wall: Get REW running on the rPi4/bookworm itself [issues here]. Provided the X forwarding isn't too ghastly slow this should be better from the real-time measurement point of view.

 

[phofman]

IME REW runs much better on linux with OpenGL enabled. Without OpenGL I get dropouts in RTA which I explain (maybe incorrectly) as the GUI threads slowing down the other threads, leading to capture/playback breaks. Generally Xwindow graphics is slower than the windows GUI layer (hence the push for simplier Wayland). I would be afraid that X forwarding (very inefficient by itself) will make this seriously worse (plus it may not work with OpenGL, IIUC). Also RPi4 performance may not be enough for this.

IMO the best way would be finding a way to fetch the digital audio stream to moode.