python-pulse-control: Can't get get_peak_sample() to ever return any values > 0

I’m sure this is pilot error in some way, but no matter what I do, I can’t seem to get back a non-zero return from .get_peak_sample().

I’m hoping to do it to a source/input (it’s a USB device, but Linux think’s it’s a 4-channel microphone). But I can’t even get it to work on a sink monitor or anything. I’ve verified that I can set the volume on the sink, so it’s not a permissions issue or something like that.

import pulsectl
p = pulsectl.Pulse('tst')
p.sink_list()
# [<PulseSinkInfo at ae5a2af0 - description='miniDSP 2x4HD Analog Stereo', index=0, mute=0, name='alsa_output.usb-miniDSP_miniDSP_2x4HD-00.analog-stereo', channels=2, volumes=[100% 100%]>]
sink = p.sink_list()[0]

# this works:
p.volume_set_all_chans(sink, 0.5)

# this never does:
p.get_peak_sample(sink, 2)
# 0

And yes, it’s playing 😃 I’ve also tried attaching to the monitor source, the real source, etc.

I’m sure I’m missing something fundamental, but I am stuck. I’m on PA 12.2 running on a rPi4. Thanks!

About this issue

  • Original URL
  • State: closed
  • Created 3 years ago
  • Comments: 20 (20 by maintainers)

Commits related to this issue

Most upvoted comments

It’s possible that my local config is confounding your tests in some manner.

Yeah, most likely. While pulse daemon has custom .pa config and XDG dir for its sockets and stuff for tests, it still reads global daemon.conf, which is probably where system mode was enabled. Might want to check if it can be overidden somehow, iirc there wasn’t a simple option.

I’m happy to continue trying to track it down if you’d like to solve it. If you’re over it, I don’t need to either, of course. If you WANT to track this down, I’m more than happy to help.

Don’t think it’s terribly important, as otherwise someone would’ve probably reported an issue with some similar configuration already, but should probably take at least a brief look at all other pulse configuration like daemon.conf and how to skip/substitute those for a testing instance, see if maybe it’s just a line or two, which is likely the problem here. Will definitely mention the change here, if any. Thanks.

It looks like it’s shedding permissions before trying to start that directory, and of course it should be able to in /tmp, but yeah, I don’t understand either. I see you’re tired.

Yeah, that error makes sense, just looked funny on the first reading to me atm, hence the first “what the F” take and the reversal. Nothing that a simple sleep can’t fix, anyway 😃

thank you SO MUCH for your help. This is the second time you’ve helped me on this (see #3 from 5 years ago!).

You’re welcome, and again, thanks for bringing these up and testing stuff out too.