Thank you for your donation!


Cloudsmith graciously provides open-source package management and distribution for our project.


Solved: allow local mpd modifications without overwriting them
#1
Hi,

I love this system and its great hardware integration!

One thing that I'd like to do is modify the mpd config file (/etc/mpd.conf) without having my changes overwritten by the web interface.  This could easily be accommodated by including a line in the mpd.conf file.

From the mpd docs regarding their configuration file options:

Quote:You can use
Code:
include_optional
instead if you want the included file to be optional; the directive will be ignored if the file does not exist:
include_optional "may_not_exist.conf"

My use case is that I want to use the fifo plugin from mpd, but I don't see somewhere to set that up from Moode's exposed configuration settings.  Defining a file for additional mpd configuration that will persist through configuration writes from the Moode interface would be most excellent.

Thoughts?
Reply
#2
There is already a way to use custom mpd settings.
  • Create an /etc/mpd.custom.conf
  • Enable the dev tweaks with:
Code:
moodeutl -A add 32768
moodeutl -r

If you inspect the content of /etc/mpc.conf you will see that it now also contains your settings.
The settings are not only added, but also merged with existing settings. So you can even overwrite existing ones.

If this solves your issue please mark this post as solved.
Reply
#3
Hi hindumagic

If you are adding an audio_output section to /etc/mpd.conf then, unless there have been any changes to Moode (bitlab might be able to comment on this), there will be no option to enable it.

If it cannot be enabled, then I have some patches here that can enable an MPD FIFO

   https://github.com/antiprism/mpd_oled/bl...l-mpd_oled

Adrian.
Reply
#4
You can add an output without patching the code, just by hijacking an existing one :-)

For example with the release of 7.0.0 I did this for an experimental camilladsp output. There I reused the "ALSA graphic eq" for the camilladsp device.
With the fifo output you probably want a parallel output, so if you ain't using the moode http stream port server I would hijacking this one.
It requires:
  • in mpd.custom.conf overwrite the http server settings  (You can take experimental camilladsp setup for example).
  • enabling the http server to enable the output
Reply
#5
Hi bitlab

Thanks for the extra information.

Adrian.
Reply
#6
Hi Bitlab, thanks for the great summary. I will try that.

Unfortunately, I want to add a fifo output.
But to be clear, it sounds like you can't add another output using mpd.custom.conf. Correct?

It's unfortunate that I have to take away the option of streaming via http to hack this in. (if I understand you right - I'm new with this system but loving it so far)

I love the idea of the mpd.custom.conf and how it is merged into the final /etc/mpd.conf. That avoids the potential nameclash that my approach would allow (not sure how mpd responds to that - could test). I will see if I can define a fifo output through the custom file and report back.
Reply
#7
(02-07-2021, 07:47 AM)hindumagic Wrote: Hi,

I love this system and its great hardware integration!

One thing that I'd like to do is modify the mpd config file (/etc/mpd.conf) without having my changes overwritten by the web interface.  This could easily be accommodated by including a line in the mpd.conf file.

From the mpd docs regarding their configuration file options:

Quote:You can use
Code:
include_optional
instead if you want the included file to be optional; the directive will be ignored if the file does not exist:
include_optional "may_not_exist.conf"

My use case is that I want to use the fifo plugin from mpd, but I don't see somewhere to set that up from Moode's exposed configuration settings.  Defining a file for additional mpd configuration that will persist through configuration writes from the Moode interface would be most excellent.

Thoughts?

What's your usage scenario for MPD FIFO?

If it's a generally applicable scenario you could make the case that a dedicated option should be added to Audio Config.
Enjoy the Music!
moodeaudio.org | Mastodon Feed | GitHub
Reply
#8
Success!  Thanks for your help, BitLocker.

Using the /etc/mpd.custom.conf approach worked perfectly.  I have the new output plugin defined in mpd's config file.  ...and I just poked around a little bit with moodeutl - nice!

How do I mark this thread as solved?
Reply
#9
Just keep in mind that what you are using is a developer tweak meant to make testing new things easier. It's not a feature and it might not exist in upcoming versions of moOde.

Your best bet is to make a case for an MPD fifo output to be included in stock moOde.
Enjoy the Music!
moodeaudio.org | Mastodon Feed | GitHub
Reply
#10
(02-08-2021, 12:35 AM)Tim Curtis Wrote: What's your usage scenario for MPD FIFO?

If it's a generally applicable scenario you could make the case that a dedicated option should be added to Audio Config.

It is a corner case, but one that others might want to go down.  I have this pi hat that is a tube headphone amplifier, and I'm really digging the lush sound coming from it.  It is stuck in a bare bones, open sided case that doesn't protect it too much and is too light - I've swept it off the table twice already.

I figured that I'd build it a case that would really show it off, black walnut, tube/caps/heat sink all poking out the top, big volume/on/off knob, couple of discreet momentary buttons to pause/play and skip, and an LED strip.  The LED strip is going to take the most time...

I plan on putting up a stereo spectrum visualizer or something along those lines, and so need to push the audio output through an FFT for my own purposes, which is the plan for the FIFO.  I was going to base my code off of this project I found: https://github.com/David96/mpd_visualizer , and look into the ncmpcpp codebase which uses the same approach.
I've mostly a C/C++ background and I wanted to explore python more with this project.  End result would be a python program to interpret the audio into a nice visual output to drive the LED strip (via the pi's SPI).  I could abstract it out so others could use it - basically define the length of the LED strip in a config file and you'd be good to go.

I not in a hurry to do this.  It's just for fun and there are a bunch of other parts that need to come together.  Thanks for your interest..
Reply


Forum Jump: