Shoot up with maximum value and decay/discharge with decay? Just like in pivumeter pivumeter/pivumeter.c at master * pimoroni/pivumeter * GitHub
IMO all you have to do in your plugin is to display the value you get from pivumeter.
IMO all you have to do in your plugin is to display the value you get from pivumeter.
That's right, should be pretty simple. Actually I compared 'ameter' code with 'pivumeter'. It's almost the same. They just removed all code related to SDL and introduced devices. BTW, there are couple "devices" in 'pivumeter' with Spectrum Analyzer (SA) output. One is for 11 bands and another for 17 bands. I'll try output that to pipe too as I was planning to show SA in Peppy player. But probably when VU Meter is done.
I've just finished the initial implementation of the new ALSA plugin. Pipe writer (any audio player) and reader (program in any language) can be started at any order. More details can be found on the project's wiki page:
Home * project-owner/peppyalsa Wiki * GitHub
The next step is to integrate that plugin into PeppyMeter and Peppy Player. Then add Spectrum Analyzer functionality to the same plugin.
Home * project-owner/peppyalsa Wiki * GitHub
The next step is to integrate that plugin into PeppyMeter and Peppy Player. Then add Spectrum Analyzer functionality to the same plugin.
New version of the PeppyMeter which levereges peppyalsa plugin was just released:
GitHub - project-owner/PeppyMeter: PeppyMeter Repository
GitHub - project-owner/PeppyMeter: PeppyMeter Repository
New version of the PeppyMeter was just released.
New features:
More details can be found on the meter wiki page:
PWM VU Meter * project-owner/PeppyMeter.doc Wiki * GitHub
New features:
- Fixed 'Display' output. If disabled it will be possible to output signal to a hardware only. No UI will be displaied in this case.
- Added 'PWM' output. It will allow to use LEDs and gas tubes as a hardware VU Meters.
More details can be found on the meter wiki page:
PWM VU Meter * project-owner/PeppyMeter.doc Wiki * GitHub
Thank you! The new project which I'm working on will include one more component from the past - tube amplifier 
More details about that can be found in another thread on this forum:
Need 3-5W tube amp
More details about that can be found in another thread on this forum:Need 3-5W tube amp
Sure you can as soon as the sound goes through the ALSA audio system. Meaning that your card was recognized by ALSA. To see that that happened you can run the command:
aplay -l
Here is the example output from that command:
card 1: DAC [USB AUDIO DAC], device 0: USB Audio [USB Audio]
Subdevices: 0/1
Subdevice #0: subdevice #0
aplay -l
Here is the example output from that command:
card 1: DAC [USB AUDIO DAC], device 0: USB Audio [USB Audio]
Subdevices: 0/1
Subdevice #0: subdevice #0
Last edited:
Hi. I'm basically new here.
Thanks for the software. I need a pointer to help get around a problem with PeppyMeter.
I'm on a desktop computer running Gentoo. I want to have a meter but only for mpd. In this case, I assumed I only need to define the fifo output in mpd.conf. peppyalsa and the .asoundrc definitions are not needed. Is this correct?
Here's the fifo definition:
audio_output {
type "fifo"
name "fifo"
path "/my/linuxdesktop/var/tmp/mpdfifo"
format "44100:16:2"
}
PeppyMeter works but seems to be extremely sensitive. Almost all the time it shows the signal to be clipping even on quiet songs.
Using amixer to change the soundcard (USB AK4495 DSD DAC hacked to work with the kernel) levels has no effect. Tweaking values in config.txt has no effect.
Setting "type" to "constant" with level "0" works as expected.
Where to look next?
Thanks,
Den
Thanks for the software. I need a pointer to help get around a problem with PeppyMeter.
I'm on a desktop computer running Gentoo. I want to have a meter but only for mpd. In this case, I assumed I only need to define the fifo output in mpd.conf. peppyalsa and the .asoundrc definitions are not needed. Is this correct?
Here's the fifo definition:
audio_output {
type "fifo"
name "fifo"
path "/my/linuxdesktop/var/tmp/mpdfifo"
format "44100:16:2"
}
PeppyMeter works but seems to be extremely sensitive. Almost all the time it shows the signal to be clipping even on quiet songs.
Using amixer to change the soundcard (USB AK4495 DSD DAC hacked to work with the kernel) levels has no effect. Tweaking values in config.txt has no effect.
Setting "type" to "constant" with level "0" works as expected.
Where to look next?
Thanks,
Den
Home * project-owner/peppyalsa.doc Wiki * GitHub
Whereas you are sending to the named pipe unprocessed audio samples, directly from MPD.
Whereas you are sending to the named pipe unprocessed audio samples, directly from MPD.
Thanks for the distinction. So I'll need to use peppyalsa. (I tried an older version of PeppyMeter - vermeer edition - and went direct from mpd fifo but it was still mainly indicating clipping).
I compiled peppyalsa and tried with 2 soundcards: PCIe and USB DAC. Same result for both: audio works as it should across various resolutions but no output at the pipes.
Then I ran strace using aplay (aplay -D thepeppyalsaplugin ...) on two cases: where the fifos don't exist and where they do. See below for results:
When the fifos don't exist:
rt_sigaction(SIGPIPE, {sa_handler=0x7fd1ffda7a60, sa_mask=[], sa_flags=SA_RESTORER, sa_restorer=0x7fd1ffc7f610}, NULL, 8) = 0
mknod("/tmp/meter-pipe", S_IFIFO|0666) = 0
openat(AT_FDCWD, "/tmp/meter-pipe", O_WRONLY|O_NONBLOCK) = -1 ENXIO (No such device or address)
rt_sigaction(SIGPIPE, {sa_handler=0x7fd1ffda7a30, sa_mask=[], sa_flags=SA_RESTORER, sa_restorer=0x7fd1ffc7f610}, NULL, 8) = 0
mknod("/tmp/spectrum-pipe", S_IFIFO|0666) = 0
openat(AT_FDCWD, "/tmp/spectrum-pipe", O_WRONLY|O_NONBLOCK) = -1 ENXIO (No such device or address)
When the fifos exist and have permissions 666:
rt_sigaction(SIGPIPE, {sa_handler=0x7fae9e71ca60, sa_mask=[], sa_flags=SA_RESTORER, sa_restorer=0x7fae9e5f4610}, NULL, 8) = 0
mknod("/tmp/meter-pipe", S_IFIFO|0666) = -1 EEXIST (File exists)
openat(AT_FDCWD, "/tmp/meter-pipe", O_WRONLY|O_NONBLOCK) = -1 ENXIO (No such device or address)
rt_sigaction(SIGPIPE, {sa_handler=0x7fae9e71ca30, sa_mask=[], sa_flags=SA_RESTORER, sa_restorer=0x7fae9e5f4610}, NULL, 8) = 0
mknod("/tmp/spectrum-pipe", S_IFIFO|0666) = -1 EEXIST (File exists)
openat(AT_FDCWD, "/tmp/spectrum-pipe", O_WRONLY|O_NONBLOCK) = -1 ENXIO (No such device or address)
Why doesn't the openat() recognize them? Any help is appreciated.
I compiled peppyalsa and tried with 2 soundcards: PCIe and USB DAC. Same result for both: audio works as it should across various resolutions but no output at the pipes.
Then I ran strace using aplay (aplay -D thepeppyalsaplugin ...) on two cases: where the fifos don't exist and where they do. See below for results:
When the fifos don't exist:
rt_sigaction(SIGPIPE, {sa_handler=0x7fd1ffda7a60, sa_mask=[], sa_flags=SA_RESTORER, sa_restorer=0x7fd1ffc7f610}, NULL, 8) = 0
mknod("/tmp/meter-pipe", S_IFIFO|0666) = 0
openat(AT_FDCWD, "/tmp/meter-pipe", O_WRONLY|O_NONBLOCK) = -1 ENXIO (No such device or address)
rt_sigaction(SIGPIPE, {sa_handler=0x7fd1ffda7a30, sa_mask=[], sa_flags=SA_RESTORER, sa_restorer=0x7fd1ffc7f610}, NULL, 8) = 0
mknod("/tmp/spectrum-pipe", S_IFIFO|0666) = 0
openat(AT_FDCWD, "/tmp/spectrum-pipe", O_WRONLY|O_NONBLOCK) = -1 ENXIO (No such device or address)
When the fifos exist and have permissions 666:
rt_sigaction(SIGPIPE, {sa_handler=0x7fae9e71ca60, sa_mask=[], sa_flags=SA_RESTORER, sa_restorer=0x7fae9e5f4610}, NULL, 8) = 0
mknod("/tmp/meter-pipe", S_IFIFO|0666) = -1 EEXIST (File exists)
openat(AT_FDCWD, "/tmp/meter-pipe", O_WRONLY|O_NONBLOCK) = -1 ENXIO (No such device or address)
rt_sigaction(SIGPIPE, {sa_handler=0x7fae9e71ca30, sa_mask=[], sa_flags=SA_RESTORER, sa_restorer=0x7fae9e5f4610}, NULL, 8) = 0
mknod("/tmp/spectrum-pipe", S_IFIFO|0666) = -1 EEXIST (File exists)
openat(AT_FDCWD, "/tmp/spectrum-pipe", O_WRONLY|O_NONBLOCK) = -1 ENXIO (No such device or address)
Why doesn't the openat() recognize them? Any help is appreciated.
I'm sorry for delay just found your message.
If you use Vermeer edition you don't need peppyalsa. You have correct mpd configuration for the pipe.
Have you tried to play with such parameters as volume.max and adjust.mpd ?
peppyalsa was created to support players other than mpd - vlc, mplayer etc:
peppyalsa - ALSA plugin for VU Meters and Spectrum Analyzers
If you use peppyalsa you don't need to specify pipe for mpd in it's config file. You need to prepare .asoundrc file:
Configuration * project-owner/peppyalsa.doc Wiki * GitHub
and define the same ALSA device for mpd or any other player.
If it's still not working please show your .asoundrc file.
Good luck!
If you use Vermeer edition you don't need peppyalsa. You have correct mpd configuration for the pipe.
Have you tried to play with such parameters as volume.max and adjust.mpd ?
peppyalsa was created to support players other than mpd - vlc, mplayer etc:
peppyalsa - ALSA plugin for VU Meters and Spectrum Analyzers
If you use peppyalsa you don't need to specify pipe for mpd in it's config file. You need to prepare .asoundrc file:
Configuration * project-owner/peppyalsa.doc Wiki * GitHub
and define the same ALSA device for mpd or any other player.
If it's still not working please show your .asoundrc file.
Good luck!
Hi,
Thank you for creating the very attractive product!
Unfortunately I experience some problems and do hope you could help me.
I found sporadic the level indication and so tried to use
[current]
meter = blue
[data.source]
type = .....
in config.txt
to test
The arrow sways nearly arbitrary and doesn’t follow the expected level at all.
So If
[data.source]
type = saw, triangle and sine (consequentially)
with
volume.min = 0.0
volume.max = 100.0
I expected smooth swings from right to left, but the results were the same. Generally the arrow/needle behaves like indicating a noise, varies its speed and doesn’t reach left and right borders at all.
I tried on “Debian Buster with Raspberry Pi Desktop” virtual machine before putting the program to a real Pi hardware
When I tried to run PeppyMeter on Windows 10/Python 3.8.2
the problem remains
with
type = saw
I noticed the following
pygame 1.9.6
Hello from the pygame community. Contribute - pygame wiki
libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: known incorrect sRGB profile
When
type = triangle
volume.min = 30.0
volume.max = 60.0
the program crashed with the stack below
pygame 1.9.6
Hello from the pygame community. Contribute - pygame wiki
Exception in thread Thread-1:
Traceback (most recent call last):
File "C:\Python38\lib\threading.py", line 932, in _bootstrap_inner
self.run()
File "C:\Python38\lib\threading.py", line 870, in run
self._target(*self._args, **self._kwargs)
File "C:\Temp\PeppyMeter\PeppyMeter-master\datasource.py", line 129, in get_data
self.data = self.get_value()
File "C:\Temp\PeppyMeter\PeppyMeter-master\datasource.py", line 143, in get_value
d = self.get_triangle_value()
File "C:\Temp\PeppyMeter\PeppyMeter-master\datasource.py", line 184, in get_triangle_value
value = self.double_rng[self.v]
IndexError: list index out of range
libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: known incorrect sRGB profile
I believe the problem could be easily solved.
Might I ask you to help me
Thank you,
Serge
Thank you for creating the very attractive product!
Unfortunately I experience some problems and do hope you could help me.
I found sporadic the level indication and so tried to use
[current]
meter = blue
[data.source]
type = .....
in config.txt
to test
The arrow sways nearly arbitrary and doesn’t follow the expected level at all.
So If
[data.source]
type = saw, triangle and sine (consequentially)
with
volume.min = 0.0
volume.max = 100.0
I expected smooth swings from right to left, but the results were the same. Generally the arrow/needle behaves like indicating a noise, varies its speed and doesn’t reach left and right borders at all.
I tried on “Debian Buster with Raspberry Pi Desktop” virtual machine before putting the program to a real Pi hardware
When I tried to run PeppyMeter on Windows 10/Python 3.8.2
the problem remains
with
type = saw
I noticed the following
pygame 1.9.6
Hello from the pygame community. Contribute - pygame wiki
libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: known incorrect sRGB profile
When
type = triangle
volume.min = 30.0
volume.max = 60.0
the program crashed with the stack below
pygame 1.9.6
Hello from the pygame community. Contribute - pygame wiki
Exception in thread Thread-1:
Traceback (most recent call last):
File "C:\Python38\lib\threading.py", line 932, in _bootstrap_inner
self.run()
File "C:\Python38\lib\threading.py", line 870, in run
self._target(*self._args, **self._kwargs)
File "C:\Temp\PeppyMeter\PeppyMeter-master\datasource.py", line 129, in get_data
self.data = self.get_value()
File "C:\Temp\PeppyMeter\PeppyMeter-master\datasource.py", line 143, in get_value
d = self.get_triangle_value()
File "C:\Temp\PeppyMeter\PeppyMeter-master\datasource.py", line 184, in get_triangle_value
value = self.double_rng[self.v]
IndexError: list index out of range
libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: known incorrect sRGB profile
I believe the problem could be easily solved.
Might I ask you to help me
Thank you,
Serge
Hi Serge,
Thank you for the interest in PeppyMeter.
The behavior which you observed caused by the fact that there are two separate threads in the program: one for the data source and another for UI. The UI thread gets the data generated by the data source thread. Both threads are independent. Therefore you see that with the triangle data source it works like with noise source. That makes sense with real pipe data source but it probably doesn't make sense with testing data sources like sine, saw etc.
I will modify the code and start the data source thread only when the pipe data source is in use. In all other cases it will not start thread and data will be just fetched from the pre-defined list by the UI thread. I'm not sure how long time it will take to make this change. If you are a hands-on developer I can give you the code changes and you can modify the code without waiting for the official release. It's up to you.
Best regards.
Thank you for the interest in PeppyMeter.
The behavior which you observed caused by the fact that there are two separate threads in the program: one for the data source and another for UI. The UI thread gets the data generated by the data source thread. Both threads are independent. Therefore you see that with the triangle data source it works like with noise source. That makes sense with real pipe data source but it probably doesn't make sense with testing data sources like sine, saw etc.
I will modify the code and start the data source thread only when the pipe data source is in use. In all other cases it will not start thread and data will be just fetched from the pre-defined list by the UI thread. I'm not sure how long time it will take to make this change. If you are a hands-on developer I can give you the code changes and you can modify the code without waiting for the official release. It's up to you.
Best regards.