[Chloé Avrillon]

The LCD displays lack of a nice feature in Kodi : display a spectrum meter or a L/R channels vumeter when playing back music.


I succeeded in doing that in python using pulseaudio (see there (http://forum.kodi.tv/showthread.php?tid=221809)
I just implemente a L/R vumeter, doing a real time FFT is too slow and therefore it is better to have a some compiled code running as a server like the visualization api

but...
1) I don't know if it's possible to get those data in python directly from the Kodi Audio Engine or from the visualization library
2) The LCDProc Addon could benefit of this
3) Pulseaudio is not always the sound server used in Linux, and we need something more "cross-platform"

In order to get into this, there are several solutions :
1) expose AudioData and L/R stereo audio data to python add-ons
2) write a C add-on using visualisation doing this able to display the vumeter or the spectrum meter to the LCDProc server on demand of a Kodi add-on (like LCDProc Addon), but that would not interfere with other visualisation choosen by users

By the way I digged into the code of NastyFFt visualization which is simple enough to serve as a basis to develop other visualisations, in its simplicity, its a very good tutorial . And I have a few ideas in order to write a few visualizations addons.

Thanks for any help

[ironic_monkey]

hi chloe,

this is something i have actually wanted to do for some time, but i haven't gotten around to it.

the way to do it is to model this on the xbmc/interfaces/legacy stuff. this is C++ code for which python bindings are autogenerated using a code generator. here we should put methods like get audio data, basically code that currently is tied to the visualisation API. then there would be three users for this; python addons (like lcdproc), python based visulisations as well as the "old" visualisations in xbmc/addons/Visualisation.cpp.

[Chloé Avrillon]

Hi ironic_monkey,
Thank you for your answer and thank you for all this hard time you have for building the best mediacenter possible.

For curiosity, why was this not possible to do ? Lack of time or other hard things to sort out ?

[ironic_monkey]

just lack of time yeah.

[Chloé Avrillon]

just lack of time yeah.

Damned...
I know what is : a job, a family to take care of, friends, ...

That's life

[Skram0]

The LCD displays lack of a nice feature in Kodi : display a spectrum meter or a L/R channels vumeter when playing back music.

I'm looking into doing something similar right now. But all I want access to is the audio data that's always playing in Kodi. It doesn't have to be a "visual add-on" in case someone already has their favorite selected. I want to know the frequencies so I can draw a spectrum analyzer on an external display. That's it, nothing fancy. Just doing a lot of reading right now. I want to see if there's anything out there already made so I won't have to recode the wheel.

[ironic_monkey]

the existing hooks can be seen in xbmc/addons/Visualisation.cpp and xbmc/guilib/GUIVisualisationControl.cpp.
that will show you how to access the audio stream and such.

the code that bindings are generated against is available sits in xbmc/interfaces/legacy.
the typemaps for the generator sits in xbmc/interfaces/python/typemaps should you need additional types (probably not, primitives and vectors should do i reckon).

[pdffs]

the way to do it is to model this on the xbmc/interfaces/legacy stuff. this is C++ code for which python bindings are autogenerated using a code generator. here we should put methods like get audio data, basically code that currently is tied to the visualisation API. then there would be three users for this; python addons (like lcdproc), python based visulisations as well as the "old" visualisations in xbmc/addons/Visualisation.cpp.

Bit of a necro here, but I've been wanting this for a long time for a couple of projects. As a minor foreword - to avoid going here, I've tried getting audio data out of the ALSA device using the snd-aloop module, but it looks like the way AE works breaks that approach - I get GUI sounds as expected, but as soon as the data I want starts playing (ie via PAPlayer), the standard ALSA device goes dead (I presume AE is changing ALSA sinks on the fly or something similar, I haven't investigated). So, the sort of approach in this thread seems likely the only feasible option.

I am a little confused by your suggestion here though. My very naive reading of the code suggests that AudioData will only be called by Kodi on the currently initialized visualization, so if the current vis addon APIs were exposed via the legacy interface as Python bindings, that would only allow for writing Python visualization addons at best, right? Whereas ideally we want multiple processes to be able to access the audio.

It seems like what OP (and I) really want is just to be able to register an OnAudioData callback. Since the vis is already producing FFT, it would be nice to be able to use that, rather than re-processing the audio, but I can't see a nice way of doing that without refactoring FFT out to a different part of the stack (like, a separate callback).

Am I making sense at all here?

I have to say, C++ is not my forte at all, so any tips on how to approach this would help a lot.

[mblovell]

It seems like what OP (and I) really want is just to be able to register an OnAudioData callback. Since the vis is already producing FFT, it would be nice to be able to use that, rather than re-processing the audio, but I can't see a nice way of doing that without refactoring FFT out to a different part of the stack (like, a separate callback).

I now I am reviving (again) a somewhat dead thread, but was anything ever done with this idea -- namely, allowing more than just a single callback (outside of, say, a selected visualization addon) receive audio frequency data?

I ask since I'm hoping to experiment with mpd_oled:

https://github.com/antiprism/mpd_oled#readme

That program combines driving a 128x64 OLED display with the spectrum analyzer from C.A.V.A.

https://github.com/karlstav/cava

C.A.V.A. was originally written to take data from (I believe) a FIFO file resulting from an ALSA loopback device. Per it's name, mpd_oled switched focus to MPD (thus the focus on the various MPD distributions of MoOde, Volumio, and RuneAudio).

Locally, I have Odroid C2 and C4 boards, and a graphical OLED display is on order. It would be fun to play with this setup for kodi.

I have a related, more general post on the CoreELEC forums, since I'm unsure what sort of development environment is available from a "native" CoreELEC installation on an Odroid.

Thanks for any pointers or suggestions,
Matt