Upstream eq with raspberry pi

[MCH]

Hi,
I use an integrated streamer/DAC/amplifier so if i want to apply some equalization to music played from a NAS it needs to be done "upstream", that is, somewhere between the NAS and the streamer.
To have a desktop computer or a laptop continuously on to do this is no option for me.
Before investing in dedicated equipment, i wanted to explore the possibility of using a raspberry pi. Is this possible at all?
The only thing i have found so far that might work is installing bubbleupnp server in a pi, but i haven't found any clear information on how to do this and even if this would allow to eq the signal prior to streaming it.
Thank you for any clues or comments!
(Well i guess i don't need to say i am a newbie, sorry if this is too evident or too crazy)

 

[amper42]

The latest version of Moode offers EQ options. You might want to check it out on a RPi4.
https://moodeaudio.org

 

[MCH]

Thank you Amper, yes i use moode in other pi renderers, but in this case the renderer is internal in my amplifier (not raspberry pi). It works with whatever firmware from the manufacturer so i cannot install moode or any other software.
The idea behind my question is to use the eq in a pi that acts as a "server" (don't know if the terminology is fully correct) not as a renderer (receiving music)

 

[DeLub]

This is what I'm trying to achieve as well.

It is possible to use the USB C power port of a Pi 4 as a (audio) data input as well. The incoming audio signal can then be eq-ed, and output through usb, or a hat on your pi. I got it working, but the sample rate is fixed due to a limitation in the current linux kernel.

Somehow, however, my Pi got fried during the experiments...

 

[MCH]

Hm, fried pies is not my favourite lunch...
So did you manage to eq in the pi and stream the resulting audio to a different streamer (receiver)? If yes, what software did you use? Thanks

 

[DeLub]

Yes. My setup is iPad -> USB C cable -> Pi -> USB A cable -> Topping E30. You actually don't need much for it. You need to configure a kernel module. Then I started ffmpeg (bus sox would work as well) to read from the USB input device, do the eq, and have it output to the USB output.

It acutally worked for a couple of days...

I can make a more detailed description when I'm back home

 

[MCH]

in case someone is interested, mdsimon2 gave a solution in a different treath (post 25):

https://www.audiosciencereview.com/...urntable-a-conundrum.25364/page-2#post-863299

 

[phofman]

The RPi4 USB gadget is still a few mainline kernel commits from complete functionality, i.e. full async feedback support in windows (broken with the latest patches) and samplerate switching. A few more weeks I guess.

In the meantime or shortly afterwards camilladsp is likely to gain full support for the async feedback control. The two projects together will allow building a very powerful DSP/equalizer with USB-audio input and output.

 

[MCH]

Hi Phofman, thank you for your input. Where can i find updated information about the changes you are describing?

 

[abdo123]

The RPi4 USB gadget is still a few mainline kernel commits from complete functionality, i.e. full async feedback support in windows (broken with the latest patches) and samplerate switching. A few more weeks I guess.

In the meantime or shortly afterwards camilladsp is likely to gain full support for the async feedback control. The two projects together will allow building a very powerful DSP/equalizer with USB-audio input and output.

I'm interested as well.

 

[phofman]

As of camilladsp - https://github.com/HEnquist/camilladsp/pull/125.

As of the audio gadget - the regression of Win10 enumeration is simple to fix https://www.spinics.net/lists/linux-usb/msg214619.html , rebased patches for rate switching originally authored by Julian https://lore.kernel.org/patchwork/patch/803422/ are waiting on my computer for Julian's approval. Plus TBD optional patches for communicating stream start/stop from host to the gadget side https://lore.kernel.org/linux-usb/[email protected]/T/

 

[DeLub]

As of camilladsp - https://github.com/HEnquist/camilladsp/pull/125.

To make use of this feature, I've compiled the 5.14 kernel from raspberry pi. I noticed also two additional options ('rate_measure_interval', 'stop_on_rate_change'). Could these be used in combination with your patches that support multiple rates?

 

[phofman]

I guess these are more aimed at SPDIF input where the samplerate can change without the SPDIF receiver noticing some stream interruption.

We are discussing with Henrik options for communicating that a stream has started/stopped on the USB host side. The patched gadget alsa devices define read-only Capture Rate and Playback Rate controls which report the current rate requested by the host. Clients using the gadget alsa device could register for notifications about changes in values of these controls (e.g. alsamixer does that when displaying the bar charts). E.g. a change from 0 -> 48k would mean a stream at 48k was started on the USB host side. It will take a bit because I have to discuss the proposal in the respective mailing lists first.