Current state of CAVA (visualizer) support (especially for streaming sources)?

Next Volumio buster will provide a easy way to mod the alsa asound.conf. adding a pipe, a loopback or any signal traitement (EQ, DSP) via a plugin, available for any source will be straight forward.
IMHO, do not spend time with 2.8xx serie. A new beta should be available soon :wink:

1 Like

Hi balbuze

I don’t follow Volumio development. Are the beta and plugin pretty much fully working (apart from bugs), so that when the new beta is available any regular user could install the beta and expect a reasonable Volumio experience and will be able to install the plugin and configure a copy of the playing audio in the UI?

Adrian.

1 Like

The plugin itself will take care of adding the proper alsa configuration when the plugin is enabled, so no need for user manual edits anymore!

1 Like

From the perspective of a user very new to Volumio, it’s hard to overstate how great this feature will be. Thanks to whatever folks and machinations made this into a priority!

Now if only I didn’t risk being left out in the cold by whatever’s going on with kernel updates and the Kali/Piano/Volt bundle. X)

Getting the news below that a feature is immanent to make this trivial is pretty exciting. I don’t know exactly how soon that is: if you happen to find it valuable anyway to set up the audio copy, I’d love a detailed list of steps, but I certainly don’t want to lay any claim to your time and effort.

Hi nate_eagle

I just configured the ALSA loopback copy, and it worked out fine. These are the steps

Enable software mixer: Settings > Playback Options > Mixer

Check your soundcard name

aplay -l

Mine is sndrpihifiberry

card 2: sndrpihifiberry [snd_rpi_hifiberry_dac], device 0: HifiBerry DAC HiFi pcm5102a-hifi-0 [HifiBerry DAC HiFi pcm5102a-hifi-0]
  Subdevices: 1/1
  Subdevice #0: subdevice #0

Edit /etc/asound.conf

nano /etc/asound.conf

remove what is there and add the following, but use your sound card name where mine appears

pcm.softvolume {
    type             plug
    #slave.pcm       "softvol"
    slave.pcm       "softvolume2"
}


pcm.softvol {
    type            softvol
    slave {
        pcm         "plughw:sndrpihifiberry,0"
    }
    control {
        name        "SoftMaster"
        card        1
        device      0
    }
max_dB 0.0
min_dB -50.0
resolution 100
}
pcm.softvolume2 {
    type plug
    slave.pcm {
        type multi
        slaves {
            a { channels 2 pcm "softvol" }  # the real device
            b { channels 2 pcm "hw: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
    ]
}

Add the loopback device to load at boot. Edit the following file

sudo nano /etc/modules

Add the line

snd-aloop

Reboot!

Check the loopback device is loaded

aplay -l

You should see lines like

card 0: Loopback [Loopback], device 0: Loopback PCM [Loopback PCM]
  Subdevices: 7/8
  Subdevice #0: subdevice #0
...

When you play audio you can now get a copy from plughw:Loopback,1

Using mpd_oled the command to use this copy is something like

sudo mpd_oled -o 6 -b 21 -g 1 -f 15 -c alsa,plughw:Loopback,1

Thats it!

Adrian.

1 Like

It will be very easy to implement this with next Volumio buster. I already have a plugin using loopback (brutefir), and an other using route (peppymeter). To be implemented soon…:stuck_out_tongue_winking_eye:

2 Likes

This worked perfectly. The pieces I was missing were understanding how to use the software mixer, where exactly to put the name of my soundcard, and using plughw instead of hw in the source for CAVA. I’ve now got a responsive CAVA and suddenly life is great. I really appreciate your taking the time to write a piece that made a few of the steps really explicit.

Great! I am pleased it worked out!

Adrian.

Running into two interesting issues:

  1. There definitely seems to be a syncing issue with at least the music I play via Spotify. I’m trying to hone in on exactly how out of sync it is—it seems to start and stop correctly—but it’s definitely off. I’ll try to investigate this more tonight.
  2. It doesn’t work for airport (shairport-sync): I had thought this ought to cover literally everything that gets played through the device. Is shairport left out of this solution?
  1. If you have sync issues, try reducing the number of bars and the frame rate, if the synchronisation improves it might be that the processor is struggling to keep up.

  2. I don’t know anything about shairpoint_sync, but maybe it is currently configured to use your soundcard directly and needs to be configured to use the softvolume output instead. See
    Airplay hardware volume control

Adrian.

RE: syncing issues, thanks for the tips! I’ll investigate that as a possibility, though this is running on a beefy pi4 with reduced bars/framerate (100 bars, 30fr) that is smooth as butter on a separate pi3. Still: checking out processor load is a good idea, and I hadn’t been thinking about that possibility.

RE: the softvolume stuff, thanks for the pointer: I haven’t dealt with that at all before using your configuration, so I wouldn’t have known to check that direction.

Again, thanks for the response: I hope you don’t feel like I’m treating you as unpaid tech support, but it’s a huge help to have someone with your experience on this topic.

@nate_eagle Have you seen my plugin that can be used to configure mpd_oled? The steps to install it are on the post, you seem like the kind who might find this useful:

It has been tested with Buster.

The installation script is the same as the steps to install mpd_oled. If you have done this already then it won’t be installed again. It will change mpd.conf.tmpl, if you haven’t already changed it. Changing this file stops Volumio updates but you can easily uninstall the plugin to get around this and reinstall the plugin after an update.

I’m looking for a way to allow mpd_oled to use a different audio source as described in this post. I tried the loopback but couldn’t never get it working. I’m looking at other ways like @balbuze suggested…

I did check out your plugin, as it definitely seems proximate to my needs. I’m not using the mpd_oled project, though: all I want is to be able to use CAVA with anything played through Volumio. I have an independent CAVA config that I use to drive a fadecandy-controlled light setup. So I, like mpd_oled, am using CAVA’s raw output, but that’s where we part ways with our needs.

If I understand @balbuze’s earlier post correctly, there will be a plugin coming with the next Volumio buster that should handle pipes/loopbacks to make getting CAVA responsiveness “straightforward.” (Hopefully even straightforward enough for someone like me!)

Ah, right. I see, I misread sorry! Thanks for swinging by and checking out my plugin.
CAVA is great and really versatile. I had no idea you could do so much with it. Do you have a picture of your setup in action?

There is definitely a need for an easy way access to the audio stream. I’m hoping the solution will present itself soon… :slight_smile:

No worries! Happy to make contact with as many people as possible who are working with rPi audio and visualization.

Always happy to share my setup, though you’re making me realize I should get some more better videos / images. This is what I could find quickly on my phone:

The hue slowly strobes through the spectrum, and then the intensity responds to individual bars coming from CAVA. It’s all driven by a very simple node program (I’m a JavaScript dev, so I always like to use that when I can) that receives the raw CAVA output via STDIN. (CAVA’s ability to just pipe raw data to STDOUT is incredibly, incredibly, incredibly useful.)

It’s worked swimmingly for about a year using PulseAudio. Hoping I can work my way back to similarly smooth functionality with Volumio, as its control GUI is lovely.

I was able to figure out last night that the Kali reclocker “buffer[s] the DATA 0.7s.” (It would be useful to actually understand the technology I’m using, eh?) I introduced a 700ms delay to my lights and, wham, was back to correctly synced visuals.

I’m pleased you found the issue. I did have a request for adding a delay into mpd_oled before because of the Kali reclocker. Maybe I should add it in!

Adrian.

I was also able to get shairport_sync working, again due to your assistance.

I edited /tmp/shairport-sync.conf, which I am aware is temporary (see this thread for finding the right template file to edit), but I needed to change the name of the alsa device it pointed to to “softvolume”.

alsa =
{
  #output_device = "plughw:1,0"; ← the previous default
  #output_device = "softvol"; ← the first thing I thought to try
  #output_device = "softvolume2"; ← the second thing I thought to try
  output_device = "softvolume";
}

May this stand as a testament to how incompletely I understand Alsa config and, hopefully, a bit of help to anyone of my skill level who follows in my tracks.

I can write C++ and javascript all day but given me an ALSA config file and I shit my pants :frowning:

1 Like