Same, plenty of data flowing through, no moving needle.
A simple sprites demo of pygame works fine, as does the Space Invaders sample app, plenty of on-screen motion.
A simple sprites demo of pygame works fine, as does the Space Invaders sample app, plenty of on-screen motion.
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.
pip3 install pygame==1.9.4
It will need the older version of SDL, hopefully it will get it.
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
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
Hi Francesco,
Sorry for confusion. The signal for Spectrum Analyzer is actually 4 bytes:
peppyalsa/spectrum.c at ff7c1b92a961953f6be3b9ac73998f1241a33f6f * project-owner/peppyalsa * GitHub
I should probably use 'unsigned short' (2 bytes) instead of 'unsigned int' (4 bytes) as the code only handles values < 64K.
Best regards
Sorry for confusion. The signal for Spectrum Analyzer is actually 4 bytes:
peppyalsa/spectrum.c at ff7c1b92a961953f6be3b9ac73998f1241a33f6f * project-owner/peppyalsa * GitHub
I should probably use 'unsigned short' (2 bytes) instead of 'unsigned int' (4 bytes) as the code only handles values < 64K.
Best regards
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
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
IMO the frequencies are generated by processing FFT bins here peppyalsa/spectrum.c at master * project-owner/peppyalsa * GitHub
You can use the Spectrum screensaver code from the Peppy player as an example of handling the data from the pipe:
Peppy/spectrum.py at 5a78420ffbb0d0fe03353f88830b2baa8b54254b * project-owner/Peppy * GitHub
Peppy/spectrum.py at 5a78420ffbb0d0fe03353f88830b2baa8b54254b * project-owner/Peppy * GitHub
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
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
Thanks rpi,
As you probably understand, I am not able to work on C.
I am trying to go forward.
Thanks a lot, again and greatings,
Francesco
As you probably understand, I am not able to work on C.
I am trying to go forward.
Thanks a lot, again and greatings,
Francesco
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 * (sample_rate/2) / 30
resulting in x kHz:
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]:
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
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 * (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.0500000000000for 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.0500000000000You 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
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:
Francesco
Photo Test.zip
Video Test.zip
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:
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
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 line you mentioned to be modified is at 189 but, unfortunatly, I don't know how to compile it: is it enough "gcc -o"? Could you please be so kind to help me on this matter too?
thanks in advance and best regards,
Francesco
the line you mentioned to be modified is at 189 but, unfortunatly, I don't know how to compile it: is it enough "gcc -o"? Could you please be so kind to help me on this matter too?
thanks in advance and best regards,
Francesco
I compiled it using a PeppyPlayer image on a rPi following this intructions:
Installation * project-owner/peppyalsa.doc Wiki * GitHub
I think it will work on other environments as well.
Installation * project-owner/peppyalsa.doc Wiki * GitHub
I think it will work on other environments as well.
Hi Tobias,
with the modification you have suggested, it seems that only the first 15 bars are active.
I am sorry to disturb you.
Greatings and thanks,
Francesco
with the modification you have suggested, it seems that only the first 15 bars are active.
I am sorry to disturb you.
Greatings and thanks,
Francesco
Hmmm, that‘s strange. For debugging purposes you can use
peppyalsa/ConsoleSpectrum.py at 822cee07b493f53fc9e687d5ee04345c41c1c85a * t0bit0bsen/peppyalsa * GitHub.
If you run the script via ssh, you can see the spectrum at the console. If the error is gone, you have to search the issue in your scripts. Otherwise you can try to build PeppyMeter from my fork and see what happens.
peppyalsa/ConsoleSpectrum.py at 822cee07b493f53fc9e687d5ee04345c41c1c85a * t0bit0bsen/peppyalsa * GitHub.
If you run the script via ssh, you can see the spectrum at the console. If the error is gone, you have to search the issue in your scripts. Otherwise you can try to build PeppyMeter from my fork and see what happens.
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
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
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
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];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
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