Thank you for your donation!


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


Instruction Guide 128x64 OLED with Song Status and Spectrum Display on Raspberry Pi
Great! Thanks for letting me know.
Reply
(01-28-2020, 08:40 AM)adrii Wrote: Hi Tim

mpd_oled includes a spectrum analyser visualisation, and for this to work it needs a copy of the audio that is playing.

A basic way to do this is to get MPD to make a copy and send it to a FIFO. The current mpd_oled installation instructions patch Moode to append the contents of a file (/usr/local/etc/mpd_oled_fifo.conf) to /etc/mpd.conf and enable mpd_oled_FIFO as a second output. The file contains

Code:
audio_output {
        type            "fifo"
        name            "mpd_oled_FIFO"
        path            "/tmp/mpd_oled_fifo"
        format          "44100:16:2"
}

For Moode to support this approach to duplicating the audio generally, a possibility is to have a directory, e.g. /etc/audio_outputs, which could contain files containing the lines that should appear in an audio_outputs section. You could check that lines have the formats (with appropriate extra whitespace)

key "value"
#comment

and put a limit on the file length.

If the file is valid, and there is a name key, then the contents would be written to an audio_output section in /etc/mpd.conf and the name would be enabled for ouput.

However, this approach doesn't work with Spotify, so it might not be worth the effort. For something simpler, perhaps you could have a UI box for the number of FIFO copies and just add them as
Code:
audio_output {
        type            "fifo"
        name            "audio_copy_1_FIFO"
        path            "/tmp/audio_copy_1_fifo"
        format          "44100:16:2"
}

Accepting that the format may not suit all applications (but this could now be the default for mpd_oled, as Cava, which produces the spectrum analysis, will now handle a 48000 sample rate FIFO for input).


A much better solution though would be for Moode to provide a duplicate copy (or copies) of the currently playing ALSA stream. You can see my attempt to do this with Moode here (works for me with an I2S device and a USB device)

   https://github.com/antiprism/mpd_oled/is...-567146826

It seems like a lot of work for a little spectrum analyser, but imagine passing on the duplicate stream to another computer attached to a largescreen TV for an artistic-type audio visualisation that doesn't affect audio quality

  https://github.com/projectM-visualizer/projectm

And, if the Pi Zero can run a spectrum analyser, maybe some lighter-weight visualisations could be run on a Pi directly, and displayed on a local screen (touchscreen or over HDMI).

[I also found, when researching the ALSA configuration, that some people want the same audio to go to more than one device e.g. headphones and speakers, which is also supported by duplicating the ALSA stream.]

I appreciate that providing a configuration option for duplicating the ALSA stream likely involves core changes to Moode and the potential for extreme breakage.

Thanks for your interest!

Adrian.

Hi Adrian,

I see that your ALSA config duplicates hw:0 to Loopback,0. Are you using the alsaloop command to then duplicate it to Loopback,1 or is this automatically done by snd-aloop driver?

Im not very experienced in ALSA coding and the API is heavily under documented...

-Tim
Enjoy the Music!
moodeaudio.org | Mastodon Feed | GitHub
Reply
Hi Tim

I know very little about ALSA, what I know is just from trying to duplicate a stream!

The loopback is handled by the snd_aloop driver.

There are three configuration files in the mpd_oled issue, but it is worth reviewing all of them

My Moode config: https://github.com/antiprism/mpd_oled/is...-567146826

In my Moode /etc/mpd.conf file, mpd is outputing to "hw:0,0". I don't know how to overload "hw:0,0" (I am not sure if it can be done) but I can overload "hw", and this is what the configuration file does. It means that whenever Moode/mpd writes to hw:X or hw:X,Y the overload will be used and a copy sent to the loopback device. It may have consequences, because it is used whenever "hw" is used.

Sergey's Volumio config: https://github.com/antiprism/mpd_oled/is...-536098398

I think when Volumio uses hardware volume it outputs to the "default" ALSA device. This can be overriden. However, the original output device is not known, and so needs to be specified, in this case "hw:IQaudIODAC,0"

My Volumio config: https://github.com/antiprism/mpd_oled/is...-423255641

Using Volomio software volume the system set up an alsa config file with pcm.softvolume that called pcm.softvol. I changed pcm.softvolume to call  my duplication config plugin, which then called the origional pcm.softvol.


I think the last approach is the way to go. When Moode wants to play something it would always play it to the same named ALSA plugin, e.g. "playerout". When Moode configures a device, it wouldn't refer to a "hw" name directly, but configure it in a plugin, say "deviceout". Then, in a global configuration file "deviceout" is a slave of "playerout", so anything that plays to "playerout" is heard on the "deviceout" device.

Now, if anybody wants to do anything with the audio before it is played they can override "playerout" and have "deviceout" as a slave, and the processed audio will go to the configured device.

I'll give an example. On Ubuntu I have created a global ALSA config /etc/asoundrc
Code:
pcm.playerout {
    type plug
    slave.pcm "deviceout"
}

pcm.deviceout {
    type plug
    slave.pcm "hw:1"
}

I can now play some audio to the "playerout" device and it comes out of my speakers

Code:
aplay -D playerout tmp.wav

If I want to duplicate the audio, I can simply write an .asoundrc file to override "playerout", and send the audio to be played on to "deviceout" and I don't need to know the hardware device name

Code:
pcm.!playerout {
    type plug
    slave.pcm {
        type multi
        slaves {
            a { channels 2 pcm "deviceout" }  # the real device
            b { channels 2 pcm "plughw:Loopback,0" }  # the loopback driver
        }
        bindings {
            0 { slave a channel 0 }
            1 { slave a channel 1 }
            2 { slave b channel 0 }
            3 { slave b channel 1 }
        }
    }
    ttable [
        [ 1 0 1 0 ]   # left  -> a.left,  b.left
        [ 0 1 0 1 ]   # right -> a.right, b.right
    ]
}

I can now play audio as before, with the sound coming out the speakers

Code:
aplay -D playerout tmp.wav


In a separate terminal I can now show a spectrum analyser for the audio with cava by creating a config file conf.txt

Code:
[input]
method = alsa
source = hw:Loopback,1

And running cava with this configuration

Code:
cava -p conf.txt

   

For Moode you could probably specify a Moode-only config file in /usr/share/alsa/alsa.conf, then the user overrides could be put in /etc/asound.conf as now. Moode could create some duplicate streams in the UI with the same kind of configuration override, playerout -> moode processing/duplicates -> moodeout -> user processing/duplicates -> deviceout (the user would override moodeout in this chain). But even if Moode doesn't provide anything in the UI, the ALSA config file for creating duplicates is now much easier to write and should be robust over different audio configurations.

Adrian.
Reply
Looks like we are in the same boat trying to understand ALSA configs :-0

I like the idea of a generic way to duplicate the audio stream to ALSA Loopback as you have shown in your post. I think it should work fine for PCM. I'll try to run some test when time permits :-)
Enjoy the Music!
moodeaudio.org | Mastodon Feed | GitHub
Reply
Hi @adrii,
Thanks for your great work. I have a 2.42 "OLED SSD1309 SPI / i2c. Works great as an i2c with RST to the GPIO.
Reply
Hello everyone. Let me ask for your advice. I use a display with mpd_oled plugin. I need to change the default font to the font with Czech characters . Please advise. Thank you.
Reply
Hi diablo

I am afraid there is no way to configure a different font. This is a longstanding issue, https://github.com/antiprism/mpd_oled/issues/9, but one that I still intend to fix.

Adrian.
Reply
Hi leobo

Thanks for the feedback!

Adrian.
Reply
I just updated from Moode 6.4.1 with the mpd_oled install instructions applied, to Moode 6.4.2. The update completed correctly, with mpd_oled still working except for the spectrum display. The fix is to reapply the Moode system patch from the mpd_oled directory

Code:
sudo patch -d/ -p0 -N < moode_mpd_fifo.patch

And restart the machine.

Adrian.
Reply
Thanks @adrii works perfectly.
Reply


Forum Jump: