PeppyMeter

Weird, the only thing I can think of is the Pygame version, that I'm doing something that is not supported in the new version. One way to test that is to install the older version:
pip3 install pygame==1.9.4
It will need the older version of SDL, hopefully it will get it.
 
Well, I switched to bellini, which can grab data from squeezelite directly via shared memory, doesn't require SDL2 or Pygame, writes directly to the framebuffer. Works nicely on a Pi Zero with Hyperpixel 4" display.

AA66E5BA-E9F2-41CE-A964-E214EC792363.jpeg
 
Spectrum data flow

Hello Rpi, hello everybody,
I am working on my initiative to group some information on the same screen: in this particular case I would like to insert frequency spectrum, info on the input and output music flow and a bar VU Meter.
As you can see from the attached image everything is working but I had to use CAVA as the source for the spectrum and, of course, peppyalsa as the source of the VU meter.
My goal is to use peppy alsa's two FIFO files for both applications, but unfortunately I failed. In particular, if I insert "spectrum_size 30" in the configuration I expect to receive 60 bytes with the info: High and Low Freq.1 ..... up to ..... High and Low Freq.30, and instead I receive 120 bytes of which the first pair is significant and the second is not (only zero). It would seem as if, even for the spectrum, there is "LEFT and RIGHT" even if the second pair (the one that could, according to this theory be the right channel) is always at zero.
Trying to decode the info it would seem that the frequencies are not like what I hoped to expect (25, 32, 40, 50, 63, 79, 100, 126, 157, 197, 250, 320, 400, 500, 630, 790, 1000, 1260, 1570, 1970, 2500, 3200, 4000, 5000, 6300, 7900, 10000, 12600, 15700, 19700).
Is anyone able and willing to help me?
Thanks in advance and best regards to all,
Francesco
 

Attachments

  • WhatsApp Image 2021-10-13 at 18.25.59.jpeg
    WhatsApp Image 2021-10-13 at 18.25.59.jpeg
    263.6 KB · Views: 190
Hi rpi,
Thanks for the reply, the result is unfortunately not changed because I was already taking the least significant bytes into account; probably the frequencies I have considered are not correct: would you be kind enough to show me where I can find them?
Sincerely and thanks again,
Francesco
 
Hi Phofman,
Thanks for your reply, but I have problems to interpreter that program.
I have tried with some fixed frequency source and the results are many different from the expected: changing the "windows" parameter on the config, I always see 4 or 5 bars raising.
Thanks a lot again and best regards,
Francesco.
P.S. in the afternoon I will try to take some pictures to explain better
 
Hi fdealexa,

for every spectrum 512 time-domain-samples are taken. The fftw-algorithm calculates an output of 512/2+1 values, while the first one is the DC-part of the signal.

If you select a linear frequency axes of 30 values, the frequencies are

f(n) = n * (sample_rate/2) / 30

resulting in x kHz:
Code:
0.735000000000000	1.47000000000000	2.20500000000000	2.94000000000000	3.67500000000000	4.41000000000000	5.14500000000000	5.88000000000000	6.61500000000000	7.35000000000000	8.08500000000000	8.82000000000000	9.55500000000000	10.2900000000000	11.0250000000000	11.7600000000000	12.4950000000000	13.2300000000000	13.9650000000000	14.7000000000000	15.4350000000000	16.1700000000000	16.9050000000000	17.6400000000000	18.3750000000000	19.1100000000000	19.8450000000000	20.5800000000000	21.3150000000000	22.0500000000000

for an input if 41.1kHz. For log-spaced frequencies it is more complicated, as for the lower frequencies the resolution of the fft is not high enough to use log spacing in the lower frequency band.


the log-spaced frequencies are [kHz]:
Code:
0.0861328125000000	0.172265625000000	0.258398437500000	0.344531250000000	0.430664062500000	0.516796875000000	0.602929687500000	0.689062500000000	0.775195312500000	0.861328125000000	0.947460937500000	1.03359375000000	1.11972656250000	1.20585937500000	1.37812500000000	1.63652343750000	1.98105468750000	2.41171875000000	2.92851562500000	3.44531250000000	4.22050781250000	4.99570312500000	6.02929687500000	7.23515625000000	8.78554687500000	10.5082031250000	12.6615234375000	15.2455078125000	18.3462890625000	22.0500000000000

You can find a graphical representation in the attachment.

Unfortunately there is no physical correct way to combine the frequency bins, so the fft output is summed up over the values inside of a bin. This can cause a bit of overlapping.

The output is unsigned int, mono.

I got really good results using PeppyPlayer and the screensaver in it. I tested it using a frequency-generator-app on my mobile connected via bluetooth. You can see the result of a frequency sweep for spectrum_size = 32 in the attached movie.

If the amplitude of the signal is to high, there is distortion resulting in additional frequencies.
If you use spectrum_size = 256 you will get fine needles for pure sine input.

Kind regards

Tobias
 

Attachments

  • freq.jpg
    freq.jpg
    15.7 KB · Views: 166
  • Spectrum.mp4
    788.7 KB
Thanks, Tobias, hi all
I will try with 256 and inform you.
in attachement (Photo Test.zip) you can find the compared (CAVA vs PEPPY) results of some sine wave.
Furthermore you can see, in attached too (Video Test.zip), the compared results of the same short music.
All of them have been created with the following parameters:
type peppyalsa
decay_ms 400
meter "/var/tmp/peppyfifo"
meter_max 100
meter_show 0
spectrum "/var/tmp/peppyfifosa"
spectrum_max 100
spectrum_size 30
logarithmic_frequency 0
logarithmic_amplitude 1
smoothing_factor 20
window 1
Best regards and thanks to all of you,
Francesco

Photo Test.zip

Video Test.zip
 
Hi,

I forgot to mention that there might be still a bug in the Spectrum part of Peppyalsa. Did you compile it by yourself? You can try this:

in spectrum.c, lines 190 and 191:
pow( output_buffer[m][ 0 ], 2 ) +
pow( output_buffer[m][ 1 ], 2 ) );

you have to change the index m to x:

pow( output_buffer[x][ 0 ], 2 ) +
pow( output_buffer[x][ 1 ], 2 ) );

In the next release it will be certainly fixed.

Best regards

Tobias
 
Hi Tobias,
the problem was, most likely, related to the fact that I applied the change to the package downloaded directly from the PEPPYALSA GITHUB.
By downloading from your GITHUB and applying the change, both the "console spectrum" and my program work.
There is still a small area, larger in the linear case, that is not used because it is really outside the frequencies normally used in HiFi. For this, do you think a fixed frequency scale may be possible?
Thanks again and greetings,
Francesco
 
Hi Francesco,

that's interesting. I have to check where the difference in both sources is.

If you don't like to see the upper most frequencies, you can simply request a spectrum with e.g. 31 bins and ignore the last value.

It is also possible to hard-code the frequencies in spectrum.c, if needed. All you need is to create fill
Code:
unsigned int bins[spectrum_size+1];
with the indices where your frequencies are. The index can can range from 0 to 256, where 0 is 0Hz and 256 is samplerate/2. The frequencies are equidistant distributed.

Kind regards

Tobias

Tobias
 
Hi Tobias,
first of all thank you for your willingness to help me. Unfortunately I can't be that experienced to follow your guidance on how to modify "spectrum.c". What I would like to do is to have the following reference frequencies: 16; 20; 26; 32; 40; 51; 64; 81; 102; 128; 162; 204; 256; 324; 408; 512; 647; 816; 1024; 1294; 1632; 2048; 2589; 3264; 4096; 5178; 6528; 8192; 10355; 13056; 16384; 20710, possibly without any compensation (window) (note that trying "window 0 doesn't seem to work).
Please don't hesitate to let me know if I'm asking too much.
Thanks again and greetings,
Francesco