search

antiprism / mpd_oled

MPD, Volumio, RuneAudio and Moode OLED status and spectrum display for Raspberry Pi (and similar)
Other
168 stars 45 forks source link

All OK but no spectrum analyser #11

Closed supercrab closed 6 years ago

supercrab commented 6 years ago

Running on Pi0w v1.3.

Everything compiles OK. No equliaser for Spotify.

supercrab commented 6 years ago

It seems the equaliser doesn't work for Spotify streaming. Am I right in thinking this functionality is not supported yet?

antiprism commented 6 years ago

Hi

The issue is more with the mpd_oled installation instructions, than with the program itself. The mpd_oled program requires a copy of the currently playing audio on a FIFO. The instructions configure the MPD daemon to provide the FIFO. The Spotify player doesn't use MPD, and so there is no copy of the audio on the FIFO, and hence no spectrum data.

To work for everything the FIFO needs to receive its copy of the audio from ALSA (for players that don't use a sound daemon like Pulseaudio). I have written a small program that can work with ALSA to set up a FIFO (or multiple FIFOs, as Snapcast also needs one), and it is working for me locally. However, I believe that it will be very difficult for me to provide installation instructions for it, as the music players regenerate the ALSA configuration and my current setup needs to be "interleaved" into the configuration (i.e. the players would need patching, but it is not just a question of adding a block of text).

I will continue to look at this, but ideally the FIFO would be provided by the player OS (Volumio, RuneAudio, etc). A copy of the audio isn't just needed for the mpd_oled spectrum analyser, any kind of real-time visualisation would need a copy, and also Snapcast needs one.

The open issue on this is: https://github.com/antiprism/mpd_oled/issues/4

Adrian.

supercrab commented 6 years ago

Thanks for the update! I did see the related issue and hence closed my call. It sounds pretty complicated to me and I'm a developer. I totally understand that your program is working exactly as it should be. I think having this functionality is a nice-to-have as everything else works as it's should.

My messages from last night seem a bit short - it was late night. Thanks to all your hard work - I'm grateful!

There is potentially another way around this... Do you want to read my idea? Well, if this code was ported to Arduino then it could be possible to measure the audio voltage and use the arduino to update the equaliser display. The PI could send the track information using UART to the arduino. I'd be well up to tackle this task but would an arduino be powerful enough to keep up with 25FPS? Let me know what you think!

Mase

antiprism commented 6 years ago

Hi Mase

Short messages are fine!

It looks like Cava has been ported to Arduino

https://github.com/krilek/cava-arduino

It may be possible to adapt it to update the screen based on the audio data obtained on pins and text data sent from the player by an adapted version of mpd_oled. It seems like hard work though!

Other software alternatives involve installing a sound server (Pulseaudio or Jack), which can be much more easily configured to provide a FIFO, although could affect any player OS sound quality tweaks. But, maybe reading audio data from hardware also affects sound quality. I believe my current ALSA setup also has a minor affect on sound quality, that I would like to remove.

Adrian.

supercrab commented 6 years ago

Hi!

Thanks for the link to cava-arduino!

I've written a graphical equaliser on Arduino before using a simple FFT library and it was pretty straight forward. I would have to adapt mpd_oled but the arduino library for the display is very similar to the pi version.

If I feed the audio into an amplifier in parallel it should act as buffer and not affect sound quality :)

The only question is whether an arduino can process the audio, update the screen and still be available to receive serial messages at the same time!

I'll have a look at this :)

supercrab commented 5 years ago

For anyone interested: porting the visualiser to Arduino did work but it left very little space for any other features. I scrapped this idea because of this.

I managed to make CAVA use the mic input as it's audio source and therefore bypassing the need to read any streams. The visualiser now works for all audio plugins but some routing of audio cables is required.