PeppyMeter

Jump to Latest
#681
and, BTW, I agree about Tidal - but I did not find any service that is better (sound & variety) ...
Myself, the wife and the kids are supporting ($) monthly Tidal, Apple Music, Amazon Music Spotify and probably a few others I just don't know about.
 
#682
Getting into issues with the service file - it is not created automatically, and when I manually create and edit it triggered errors.

To manually create the file I copied this sample:
https://github.com/seniorgod/ifi-ti...v-file#adjust-the-systemd-service-description

Devices file shows:
device#0=bcm2835 Headphones: - (hw:2,0)
device#1=E50: USB Audio (hw:3,0)
Number of devices = 2

So I edited the service file to this:
[Unit]
Description=Tidal Connect Service*

[Service]
Restart=on-failure
ExecStart=/usr/ifi/ifi-tidal-release/bin/tidal_connect_application \
--tc-certificate-path "/usr/ifi/ifi-tidal-release/id_certificate/IfiAudio_ZenStream.dat" \
--netif-for-deviceid eth0 \
-f "DietPi stream to project“ \
--codec-mpegh true \
--codec-mqa false \
--model-name "DietPi Streamer" \
--disable-app-security false \
--disable-web-security false \
--enable-mqa-passthrough false \
--playback-device "E50: USB Audio (hw:3,0)" \
--log-level 3
User=root
Group=root
RestartSec=1
KillMode=control-group*

[Install]
WantedBy=multi-user.target*


Yet when I try to run the application I get these errors:

services error.jpg


What am I doing wrong???
 
#683
Hi,

I have been using peppy, integrated into Kodi (with my own custom skin and signicant c++ code changes) for some time and my Kodi volume has been at 100% (given I use my DAC for volume control).

I am toying/testing the idea of using CamillaDSP for my PEQ and also using Kodi for volume control (and maybe moving to a "powerdac".. PC -> DDC -> POWERDAC)

What I discovered (at least with kodi) is that if I say have my Kodi volume at 60% then Peppy reads this as a reduced volume across the Peppy pipe and basically doesnt move.

I had assumed Peppy would be reading the RAW PCM stream to gather the VU meter values not the volume attenuated value (as noted, this might be a Kodi specific issue)

I have overcome this by hacking kodi and peppy (specifically datasource.py... never written in python so luckily the change was small!!!) so that kodi registers (via an OS file) a refactor value and datasource.py reads this refactor value thus keeping Peppy at the correct level (tested with a 1khz tone at -1dbfs for all Kodi volume levels).

The datasource.py change was simple enough (change in bold.. indents got lost in the paste)

if os.path.isfile("/home/ricko/PeppyMeter/max_in_pipe"):
with open('/home/ricko/PeppyMeter/max_in_pipe', 'r') as file:
sdat = file.read().rstrip()
self.max_in_pipe = float(sdat)
new_left = int(self.max_in_ui * ((data[length - 4] + (data[length - 3] << 8)) / self.max_in_pipe))
new_right = int(self.max_in_ui * ((data[length - 2] + (data[length - 1] << 8)) / self.max_in_pipe))
os.remove("/home/ricko/PeppyMeter/max_in_pipe")
else:
new_left = int(self.max_in_ui * ((data[length - 4] + (data[length - 3] << 8)) / self.max_in_pipe))
new_right = int(self.max_in_ui * ((data[length - 2] + (data[length - 1] << 8)) / self.max_in_pipe))

Part of the refactor table is as below (so if kodi volume is 93 then the refactor value [self.max_in_pipe above] will be 61.50)

99:98.20
98:88.50
97:82.30
96:77.00
95:73.00
94:67.00
93:61.50
92:58.00

So that all works great and didnt take me too long but my question is: Is it normal for Peppy to use the attenuated volume or is there some ALSA config in my .asoundrc (shown below) that I have screwed up

pcm.!default {
type plug
slave.pcm "peppyalsa"
}

ctl.!default {
type hw
card 1
}

pcm.peppyalsa {
type meter
slave.pcm "hw:1,1"
scopes.0 peppyalsa
}

pcm_scope.peppyalsa {
type peppyalsa
decay_ms 400
meter "/tmp/myfifo"
meter_max 100
meter_show 0
}

pcm_scope_type.peppyalsa {
lib /usr/local/lib/libpeppyalsa.so
}


Thanks


Bluck
 
#684
Bluck Mutter said:
I had assumed Peppy would be reading the RAW PCM stream to gather the VU meter values not the volume attenuated value
Click to expand...
Bluck Mutter said:
Is it normal for Peppy to use the attenuated volume
Click to expand...
If kodi attenuates, it reduces the sample values before sending them over to the alsa chain. The peppyalsa device just observes the values being passed through the chain to the soundcard and displays the levels. There is no non-attenuated raw PCM stream available for Peppy.

I could not find any config for kodi to use hw volume, like e.g. mpd offers. Then the player would not attenuate the samples, but operate an alsa volume control element provided by the soundcard driver. That way the volume control operation would bypass the alsa chain and Peppy would be receiving samples at full volume. But IMO not possible with kodi (but I may be wrong).
 
#685
"I could not find any config for kodi to use hw volume, like e.g. mpd offers. "

Thanks for the comments that addressed the issue in a clear and concise manner... and I did wonder how other players (like mpd) handled this and didnt have this issue.

Anyways my little hack works fine/seamlessly but your hint regarding hw volume will provide a path for futher investigation when time permits. I was actually deep in the kodi code that relates to ALSA device selection/initialization the other day so will start there.

Thanks again

Bluck
 
#688
default {
type plug
slave.pcm "peppyalsa"
}

ctl.!default {
type hw
card 2
}

pcm.peppyalsa {
type meter
slave.pcm {
type hw
card 2
}
scopes.0 peppyalsa
}

pcm_scope.peppyalsa {
type peppyalsa
decay_ms 400
meter "/home/pi/myfifo"
meter_max 100
meter_show 0
spectrum "/home/pi/myfifosa"
spectrum_max 100
spectrum_size 30
}

pcm_scope_type.peppyalsa {
lib /usr/local/lib/libpeppyalsa.so
}

pcm.dsp0 peppyalsa
 
#689
As far as understand the signal should be splited at this point:
pcm.peppyalsa {
type meter
slave.pcm {
type hw
card 2
}
scopes.0 peppyalsa
}
so, theoretically the path to the peppyalsa should not affect the signal which goes to the hardware. Maybe @phofman could shed some light here?
 
#694
Sorry, I meant I had tried to adjust them. Here is the reading:

pi@raspberrypi:~ $ cat /proc/asound/card2/pcm0p/sub0/hw_params
access: MMAP_INTERLEAVED
format: S32_LE
subformat: STD
channels: 2
rate: 96000 (96000/1)
period_size: 960
buffer_size: 19200
 
#697
IIUC Rygel uses gstreamer. Its playback pipeline seems to be configurable via audio-sink config item https://manpages.ubuntu.com/manpages/focal/en/man5/rygel.conf.5.html#playbin plugin

The gst alsasink has parameters buffer-time (default 200ms) and latency-time (default 10ms) - look at 'gst-inspect-1.0 alsasink'.

Now you need to find out how to pass alsasink to the playbin - seems described in https://discourse.beets.io/t/bpd-changing-device-property-of-gst-audio-sink/1140/1

So you may need to construct your playbin pipeline using gst-launch which uses the params that you want, test it, and then copy the tested audio-sink string to the rygel audio-sink config as above.

Complex but very flexible - that's typically the case with players based on gstreamer.
 
  • Like
Reactions: teacherguy
#698
Looking at this again after a very long time. Surprised that it still uses named pipes for input, vs. PyAudio. Wanted to use it to visualize input from another device (such as WiiM) via a Toslink splitter, but it requires a cumbersome arecord | aplay script to accomplish, in addition to the Alsa configuration. Found a simple C program on GitHub that can do the in->out Alsa loop nicely, and can be easily run as a daemon. Works nicely with Peppy, once modified for my specific Alsa in/out/bitrate.

https://github.com/zonque/simple-alsa-loop
 
#699
chicks said:
Surprised that it still uses named pipes for input, vs. PyAudio.
Click to expand...
IIUC your usecase is rather special as stream from your capture alsa device is already dedicated to the meter only. But how would you use PyAudio to piggy-back onto the audio stream going from a player to a soundcard?

chicks said:
Works nicely with Peppy, once modified for my specific Alsa in/out/bitrate.

https://github.com/zonque/simple-alsa-loop
Click to expand...
If the capture and playback devices do not run synchronously, eventually the buffer in the simple loopback code will under/overflow. Just like the buffer in the arecord | aplay pipe, but the pipe buffer is much longer (64kB vs. 4kB) and will take comparably longer to happen.
 
#700
I had a lot of these issues described above before.
Now I did the entire installation one more time and testing every step.
The LAST thing I installed was Spotify.

So basically the moOde player and PeppyMeter works well in auto start function before I install / activate the Spotify renderer.

I tested with web radio and the VU meters show up and show the volume.
When I pause WebRadio they disappear just the way you expect it to happen.

Once I activate Spotify they wont work and I have all sorts of issues.


Can anyone help on that ?
 
You must log in or register to reply here.
Top Bottom