Can't get get_peak_sample() to ever return any values > 0

[mfeif]

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!

[mk-fg]

But I can't even get it to work on a sink monitor or anything p.get_peak_sample(sink, 2)

Note that this looks incorrect, as you should use something like p.get_peak_sample(sink.monitor_source, 2) there, not sink itself. Wonder if there should be a check on if sink is passed there to raise ValueError or something... "attaching to the monitor source" or "real source" is indeed the right way to do it.

There is a test for that function, which can maybe serve as an example code, here: https://github.com/mk-fg/python-pulse-control/blob/96cfaec/pulsectl/tests/dummy_instance.py#L574-L621

You can run it with e.g. python -m unittest pulsectl.tests.all.DummyTests.test_get_peak_sample, and if it doesn't fail, then assertGreater(peak, 0) checks there pass and sampling the source seem to be working and it actually gets non-zero output from that method. Test doesn't use real hardware sinks/sources of course, just a null module with paplay --raw /dev/urandom white noise piped into it.

That method creates source-recording stream for samples in the same way as pavucontrol does (same flags, metadata, etc), so maybe check if pavucontrol shows activity on that same sinks/sources? If it does not either, then guess something doesn't work right (or muted) on pulseaudio daemon side, and maybe can be reported as a bug there, though I'd suggest double-checking stuff like "pacmd info" for any oddities first (like zero volume, mute, etc), as I imagine bugs there aren't very common these days.

[mfeif]

I'm getting a crash trying to run tests:

$ python -m unittest pulsectl.tests.all.DummyTests.test_get_peak_sample
E
======================================================================
ERROR: setUpClass (pulsectl.tests.dummy_instance.DummyTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/mjf/.cache/pypoetry/virtualenvs/hacking-ZaYkZyO--py3.7/lib/python3.7/site-packages/pulsectl/tests/dummy_instance.py", line 217, in setUpClass
    cls.instance_info = dummy_pulse_init()
  File "/home/mjf/.cache/pypoetry/virtualenvs/hacking-ZaYkZyO--py3.7/lib/python3.7/site-packages/pulsectl/tests/dummy_instance.py", line 78, in dummy_pulse_init
    try: _dummy_pulse_init(info)
  File "/home/mjf/.cache/pypoetry/virtualenvs/hacking-ZaYkZyO--py3.7/lib/python3.7/site-packages/pulsectl/tests/dummy_instance.py", line 179, in _dummy_pulse_init
    else: raise AssertionError(p)
AssertionError: /tmp/pulsectl-tests.6qizwlay/pulse/native

----------------------------------------------------------------------
Ran 0 tests in 4.518s

FAILED (errors=1)
Error in atexit._run_exitfuncs:
Traceback (most recent call last):
  File "/home/mjf/.cache/pypoetry/virtualenvs/hacking-ZaYkZyO--py3.7/lib/python3.7/site-packages/pulsectl/tests/dummy_instance.py", line 222, in tearDownClass
    dummy_pulse_cleanup(cls.instance_info)
AttributeError: type object 'DummyTests' has no attribute 'instance_info'

[mfeif]

Ok, I'm able to get SOME value with:

p.get_peak_sample(p.source_list()[0].monitor_of_sink, 0.2)
# 0.3647918701171875

(Source 0 is the monitor of the playing sink)

But my actual card inputs are still returning zeros under all conditions. So that's probably/maybe a config error, since I can get some value from this.

I think also I'm getting a little lost in the terms here; sinks have sources (which makes sense with the concept of monitor) but monitor sources have sinks even if they're not being routed into output?

Here's what pacmd list sources has to say about this device. Notice that it's suspended, even though it's playing. I expect my "bug" is there.

Source #2
    State: SUSPENDED
    Name: alsa_input.usb-miniDSP_miniDSP_2x4HD-00.multichannel-input
    Description: miniDSP 2x4HD Multichannel
    Driver: module-alsa-card.c
    Sample Specification: s32le 4ch 96000Hz
    Channel Map: front-left,front-right,rear-left,rear-right
    Owner Module: 1
    Mute: no
    Volume: front-left: 65536 / 100% / 0.00 dB,   front-right: 65536 / 100% / 0.00 dB,   rear-left: 65536 / 100% / 0.00 dB,   rear-right: 65536 / 100% / 0.00 dB
            balance 0.00
    Base Volume: 65536 / 100% / 0.00 dB
    Monitor of Sink: n/a
    Latency: 0 usec, configured 0 usec
    Flags: HARDWARE DECIBEL_VOLUME LATENCY
    Properties:
        alsa.resolution_bits = "32"
        device.api = "alsa"
        device.class = "sound"
        alsa.class = "generic"
        alsa.subclass = "generic-mix"
        alsa.name = "USB Audio"
        alsa.id = "USB Audio"
        alsa.subdevice = "0"
        alsa.subdevice_name = "subdevice #0"
        alsa.device = "0"
        alsa.card = "1"
        alsa.card_name = "miniDSP 2x4HD"
        alsa.long_card_name = "miniDSP miniDSP 2x4HD at usb-0000:01:00.0-1.2.1, high speed"
        alsa.driver_name = "snd_usb_audio"
        device.bus_path = "platform-fd500000.pcie-pci-0000:01:00.0-usb-0:1.2.1:1.0"
        sysfs.path = "/devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-1/1-1.2/1-1.2.1/1-1.2.1:1.0/sound/card1"
        udev.id = "usb-miniDSP_miniDSP_2x4HD-00"
        device.bus = "usb"
        device.vendor.id = "2752"
        device.vendor.name = "miniDSP"
        device.product.id = "0011"
        device.product.name = "miniDSP 2x4HD"
        device.serial = "miniDSP_miniDSP_2x4HD"
        device.string = "hw:1"
        device.buffering.buffer_size = "1048576"
        device.buffering.fragment_size = "524288"
        device.access_mode = "mmap+timer"
        device.profile.name = "multichannel-input"
        device.profile.description = "Multichannel"
        device.description = "miniDSP 2x4HD Multichannel"
        alsa.mixer_name = "USB Mixer"
        alsa.components = "USB2752:0011"
        module-udev-detect.discovered = "1"
        device.icon_name = "audio-card-usb"
    Ports:
        multichannel-input: Multichannel Input (priority: 0)
    Active Port: multichannel-input
    Formats:
        pcm

Thanks for your quick response. Yes, it might be nice if the function throws an exception if the first parameter isn't of a valid type.

[mk-fg]

I'm getting a crash trying to run tests:

Fixed double-error and added more descriptive error msg there.

But the issue is that dummy pulseaudio daemon seem to be failing to start or create module-native-protocol-unix socket here: https://github.com/mk-fg/python-pulse-control/blob/master/pulsectl/tests/dummy_instance.py#L139-L181

Maybe run it with PA_DEBUG=t python -m unittest pulsectl.tests.all.DummyTests.test_get_peak_sample and see what it outputs in verbose logging wrt that module-native-protocol-unix socket? Not sure if it might be some distro-specific quirk/patch where it creates socket in an oddball place, but more likely just fails to start somehow, would be interesting to see why.

[mk-fg]

I think also I'm getting a little lost in the terms here: sinks have sources (which makes sense with the concept of monitor) but monitor sources have sinks even if they're not being routed into output?

From pulseaudio daemon perspective, applications ("clients") connect to it and open "streams" of sound samples. These streams either:

• Send sound samples into "sink" (sink input stream), usually to be then routed to something that outputs these as sound.
• Or they are connected to "source" (source output stream), which can be e.g. a physical mic output, or a monitor stream from sink, which essentially mirrors all combined/mixed inputs that are sent into it.

There is a separate concept of "card", which has a collection of sinks and sources associated with its inputs and outputs, which is basically there for tying these together with physical hw metadata, switching card profiles in the driver (e.g. which jacks sink inputs/outputs sound through) and such stuff - should be irrelevant here, but thought to mention so that it won't be confused with sinks/sources.

You should be able to see all these in e.g. "pacmd info" dump or query via module methods.

get_peak_sample code is expected to be passed a "source" name or its index, and does the following things:

• Creates new "stream" from this "client" with stream_new_with_proplist.
• Registers simple read_cb function there for receiving sound samples on that stream with stream_set_read_callback.
• Connects that stream to specified (by name string or index) "source" via stream_connect_record.
• Runs libpulse eventloop for specified timeout, which should call that read_cb function when samples are there, read_cb checks value of those and stores max one, which gets returned at the end.

So you can think of it as a simple recording stream (source output stream), same as you'd open with e.g. "parecord" command to store sound from mic into a wav file, except this one doesn't actually care for storing sound samples, just compares them and picks/returns the one with max value.

Hopefully this might clear up how it all works a bit :)

[mk-fg]

Here's what pacmd list sources has to say about this device.

As per previous comment, it's not quite a "device", but rather one of the "sources" created for the specified "card". (if you set card profile to "off", there won't be any sinks/sources created for it, or you can set it to e.g. "output:analog-stereo" profile to only create sinks to output sound through, without any mic input sources)

But my actual card inputs are still returning zeros under all conditions. Notice that it's suspended, even though it's playing. I expect my "bug" is there.

So this indeed looks like one of the sources created for input from that ALSA card, getting sound from "multichannel-input" its port. (for e.g. HDA cards there can be several "ports" there which you can switch, like "analog-input-front-mic", "analog-input-rear-mic", "analog-input-linein", etc - but not the case here, so there's probably just one input mode, though "multichannel-input" name of it seem to imply that it might be through several jacks, and single TRS one usually doesn't have enough wires for "front-left,front-right,rear-left,rear-right" channels, so probably two front+rear jacks)

Volume seem to be set to 100% and source is not muted.

Don't see anything wrong with that source, and indeed would expect get_peak_sample to pick-up some non-zero values on it if hardware detects sound there and in-kernel ALSA driver doesn't malfunction and pass it through to pulseaudio.

Again, my suggestion will be to double-check if pavucontrol GUI app detects sound there under its "Input Devices" tab - should show up on the bar under volume slider (check "Output Devices" tab when some output music is playing for example). If something shows up there but get_peak_sample() returns 0 at the same time, then it's likely a bug here, otherwise pulseaudio daemon doesn't pick-up any sound, which is a separate issue to debug.

If it's the latter case - pulseaudio daemon doesn't pick-up any sound - I'd suggest stopping pulseaudio temporarily (e.g. via systemctl --user stop pulseaudio.socket pulseaudio on systemd distros), and running something like arecord -D hw:1 test.wav (note that device.string = "hw:1" from pacmd info above should correspond to raw ALSA output), then see if that wav is audible or empty (e.g. in audacity). If such basic alsa capture ends up being empty too, I'd suspect and double/triple-check jack wires and connectors first (they tend to have crappy contacts), maybe check if same card works on other device to eliminate possibility of hw issue there, then lookup how to debug snd-usb-audio driver, as that'd remain as the thing that's likely to be failing there.

[mfeif]

Here's your output:

$ PA_DEBUG=t python -m unittest pulsectl.tests.all.DummyTests.test_get_peak_sample
N: [pulseaudio] main.c: System mode refused for non-root user. Only starting the D-Bus server lookup service.
I: [pulseaudio] main.c: setrlimit(RLIMIT_NICE, (31, 31)) failed: Operation not permitted
I: [pulseaudio] main.c: setrlimit(RLIMIT_RTPRIO, (9, 9)) failed: Operation not permitted
D: [pulseaudio] core-rtclock.c: Timer slack is set to 50 us.
I: [pulseaudio] core-util.c: Failed to acquire high-priority scheduling: Permission denied
I: [pulseaudio] main.c: This is PulseAudio 12.2
D: [pulseaudio] main.c: Compilation host: arm-unknown-linux-gnueabihf
D: [pulseaudio] main.c: Compilation CFLAGS: -g -O2 -fdebug-prefix-map=/home/pi/new/pulseaudio-12.2=. -fstack-protector-strong -Wformat -Werror=format-security -Wall -W -Wextra -pipe -Wno-long-long -Wno-overlength-strings -Wunsafe-loop-optimizations -Wundef -Wformat=2 -Wlogical-op -Wsign-compare -Wformat-security -Wmissing-include-dirs -Wformat-nonliteral -Wpointer-arith -Winit-self -Wdeclaration-after-statement -Wfloat-equal -Wmissing-prototypes -Wredundant-decls -Wmissing-declarations -Wmissing-noreturn -Wshadow -Wendif-labels -Wcast-align -Wstrict-aliasing -Wwrite-strings -Wno-unused-parameter -fno-common -fdiagnostics-show-option -fdiagnostics-color=auto
D: [pulseaudio] main.c: Running on host: Linux armv7l 5.10.11-v7l+ #1399 SMP Thu Jan 28 12:09:48 GMT 2021
D: [pulseaudio] main.c: Found 4 CPUs.
I: [pulseaudio] main.c: Page size is 4096 bytes
D: [pulseaudio] main.c: Compiled with Valgrind support: yes
D: [pulseaudio] main.c: Running in valgrind mode: no
D: [pulseaudio] main.c: Running in VM: no
D: [pulseaudio] main.c: Optimized build: yes
D: [pulseaudio] main.c: FASTPATH defined, only fast path asserts disabled.
I: [pulseaudio] main.c: Machine ID is 70f066db93dc41f490990fac4dab47df.
I: [pulseaudio] main.c: Using runtime directory /tmp/pulsectl-tests.j84e_rrs/pulse.
I: [pulseaudio] main.c: Using state directory /tmp/pulsectl-tests.j84e_rrs.
I: [pulseaudio] main.c: Using modules directory /usr/lib/pulse-12.2/modules.
I: [pulseaudio] main.c: Running in system mode: no
I: [pulseaudio] main.c: System supports high resolution timers
D: [pulseaudio] memblock.c: Using shared memfd memory pool with 1024 slots of size 64.0 KiB each, total size is 64.0 MiB, maximum usable slot size is 65496
I: [pulseaudio] cpu-arm.c: CPU flags: V6 V7 VFP EDSP NEON VFPV3
I: [pulseaudio] svolume_arm.c: Initialising ARM optimized volume functions.
I: [pulseaudio] sconv_neon.c: Initialising ARM NEON optimized conversions.
I: [pulseaudio] mix_neon.c: Initialising ARM NEON optimized mixing functions.
I: [pulseaudio] remap_neon.c: Initialising ARM NEON optimized remappers.
W: [pulseaudio] server-lookup.c: Unable to contact D-Bus: org.freedesktop.DBus.Error.NotSupported: Unable to autolaunch a dbus-daemon without a $DISPLAY for X11
I: [pulseaudio] main.c: Daemon startup complete.
I: [pulseaudio] main.c: Got signal SIGTERM.
I: [pulseaudio] main.c: Exiting.
I: [pulseaudio] main.c: Daemon shutdown initiated.
I: [pulseaudio] main.c: Daemon terminated.
E
======================================================================
ERROR: setUpClass (pulsectl.tests.dummy_instance.DummyTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/mjf/.cache/pypoetry/virtualenvs/hacking-ZaYkZyO--py3.7/lib/python3.7/site-packages/pulsectl/tests/dummy_instance.py", line 217, in setUpClass
    cls.instance_info = dummy_pulse_init()
  File "/home/mjf/.cache/pypoetry/virtualenvs/hacking-ZaYkZyO--py3.7/lib/python3.7/site-packages/pulsectl/tests/dummy_instance.py", line 78, in dummy_pulse_init
    try: _dummy_pulse_init(info)
  File "/home/mjf/.cache/pypoetry/virtualenvs/hacking-ZaYkZyO--py3.7/lib/python3.7/site-packages/pulsectl/tests/dummy_instance.py", line 179, in _dummy_pulse_init
    else: raise AssertionError(p)
AssertionError: /tmp/pulsectl-tests.j84e_rrs/pulse/native

----------------------------------------------------------------------
Ran 0 tests in 4.515s

FAILED (errors=1)
Error in atexit._run_exitfuncs:
Traceback (most recent call last):
  File "/home/mjf/.cache/pypoetry/virtualenvs/hacking-ZaYkZyO--py3.7/lib/python3.7/site-packages/pulsectl/tests/dummy_instance.py", line 222, in tearDownClass
    dummy_pulse_cleanup(cls.instance_info)
AttributeError: type object 'DummyTests' has no attribute 'instance_info'

[mfeif]

Hopefully this might clear up how it all works a bit :)

I'm broadly familiar with all of this, including cards/sinks/sources/card-profiles, I just didn't understand the API here; now that I know one can just pass in the names or indices of sources, I'm less confused. I had been confused with expressions like this:

p.source_list()[0].monitor_of_sink

Because a source doesn't have a sink. Or a monitor. A sink can have a monitor source. Right? Anyway, I'm getting off-topic. Thanks for the careful write-up!

[mfeif]

(for e.g. HDA cards there can be several "ports" there which you can switch, like "analog-input-front-mic", "analog-input-rear-mic", "analog-input-linein", etc - but not the case here, so there's probably just one input mode, though "multichannel-input" name of it seem to imply that it might be through several jacks, and single TRS one usually doesn't have enough wires for "front-left,front-right,rear-left,rear-right" channels, so probably two front+rear jacks)

FWIW, it's a USB device that shows up as 2-channel output and 4-channel input all over the one USB connection. It's an external DSP type thing, so if it's playing sound, it should also be feeding samples into the "inputs". The ALSA drivers label it kinda wonky, but it's close to how it shows up on MacOS; as 2/4.

Don't see anything wrong with that source, and indeed would expect get_peak_sample to pick-up some non-zero values on it if hardware detects sound there and in-kernel ALSA driver doesn't malfunction and pass it through to pulseaudio.

Again, my suggestion will be to double-check if pavucontrol GUI app detects sound there under its "Input Devices" tab - should show up on the bar under volume slider (check "Output Devices" tab when some output music is playing for example).

I'm on a headless raspberry pi, but yes, I am aiming to prove that the driver is still passing values; it has in the past, and I've been able to use parecord to get samples. I'm working on that, but I think we can likely assume that it's not python-pulse-control's fault at this point. If I find otherwise, I'll certainly come back here.

If it's the latter case - pulseaudio daemon doesn't pick-up any sound - I'd suggest stopping pulseaudio temporarily (e.g. via systemctl --user stop pulseaudio.socket pulseaudio on systemd distros), and running something like arecord -D hw:1 test.wav (note that device.string = "hw:1" from pacmd info above should correspond to raw ALSA output), then see if that wav is audible or empty (e.g. in audacity).

Great suggestion, thanks; I had thought of the same thing; going "under" PA.

[mfeif]

Ok, arecord is not finding samples either, so it's definitely not python-pulse-control's issue.

[mk-fg]

p.get_peak_sample(p.source_list()[0].monitor_of_sink, 0.2) I had been confused with expressions like this: p.source_list()[0].monitor_of_sink

Yeah, I think kinda worked by accident due to that resulting sink index also being index of that sink's source I guess, and didn't notice it above to mention that it looks weird likely works by accident.

Because a source doesn't have a sink. Or a monitor. A sink can have a monitor source. Right?

Yeah, sink should have a monitor source, and that source has sink-index-that-it-monitors stored as that "monitor_of_sink" struct field. So in scenario above, I'd guess you have e.g. sink with index 1 and monitor source corresponding to it also with index 1, and due to crappy type system used here, both "1" values work the same for sink and source, allowing for such accidents and mixups.

Ideally p.source_list()[0].monitor_of_sink would return e.g. SinkIndex object, which will be rejected by get_peak_sample() due to it expecting SourceIndex values or something, though not sure if such strict typing will be very pythonic.

[mk-fg]

Here's your output:

Huh, weird, pulseaudio seem to start without errors there, but then doesn't seem to read anything on /dev/stdin, despite script writing it there without any errors. Will probably need to check if maybe need a flush() and some kind of delay there before close(), as iirc pipes have some quirks like that.

[mk-fg]

Ok, arecord is not finding samples either, so it's definitely not python-pulse-control's issue.

I'd also still try parecord with pulse if you haven't found the issue yet.

Seen a bunch of people in #archlinux-arm with rpis specifically (iirc) having trouble setting up stuff with alsa, but - somewhat counter-intuitively - pulseaudio "just worked", as presumably it did all the right unmuting and settings, and maybe has workarounds for some of the alsa configuration quirks, idk.

[mk-fg]

I also did replace that weird "pulseaudio -nF /dev/stdin" with using a proper file to configure that dummy testing instance in e05533b, so tests might work, if it was indeed some kind of race condition between reading and closing stdin pipe (though idk, sounds weird now that I think about it), and maybe tests will work. Not sure what else might stop pulse from processing those config lines without apparently any mention of errors and such otherwise.

[mfeif]

Ok, I've solved my initial problem; it was ALSA. The hardware device was set to mute all of the input/microphone channels, and that didn't show up in alsamixer or any tools like that. I needed to use alsactl to brute-force reinit the alsa device, and then use low-level amixer commands to turn on switches that aren't exposed in the higher level console tools. Yuk.

In case anyone lands here looking for why they can't pull in audio from a MiniDSP 2x4 HD in Linux, the solution looked like this:

# to refresh the card to something like defaults:
# with 1 being my card number
$ sudo alsactl -d -P -R init 1
# to find out what *actual* controls there are:
$ amixer -c 1 controls
# to see their values:
$ amixer -c 1 contents
# to get a single control's values:
$ amixer -c 1 cget numid=8
# and to set stuff there:
$ amixer -c 1 cset numid=8 on,on,on,on

Once I did that, I could see activity with arecord and then parecord, and then indeed

>>> p.get_peak_sample(src, 0.1)
# 0.01714739203453064

Yay! Thanks for being so amazingly responsive with all the help.

I'll check out your fix and see if I can run the tests...

[mfeif]

Checked out master, installed into a virtualenv, ran the debug command (I did it in sudo because it was complaining about not being able to get system mode).

$ sudo PA_DEBUG=t python -m unittest pulsectl.tests.all.DummyTests.test_get_peak_sample
W: [pulseaudio] main.c: Running in system mode, but --disallow-exit not set.
W: [pulseaudio] main.c: Running in system mode, but --disallow-module-loading not set.
N: [pulseaudio] main.c: Running in system mode, forcibly disabling SHM mode.
D: [pulseaudio] core-rtclock.c: Timer slack is set to 50 us.
D: [pulseaudio] core-util.c: setpriority() worked.
I: [pulseaudio] core-util.c: Successfully gained nice level -11.
I: [pulseaudio] main.c: Found user 'pulse' (UID 111) and group 'pulse' (GID 116).
I: [pulseaudio] main.c: Successfully changed user to "pulse".
I: [pulseaudio] main.c: This is PulseAudio 12.2
D: [pulseaudio] main.c: Compilation host: arm-unknown-linux-gnueabihf
D: [pulseaudio] main.c: Compilation CFLAGS: -g -O2 -fdebug-prefix-map=/home/pi/new/pulseaudio-12.2=. -fstack-protector-strong -Wformat -Werror=format-security -Wall -W -Wextra -pipe -Wno-long-long -Wno-overlength-strings -Wunsafe-loop-optimizations -Wundef -Wformat=2 -Wlogical-op -Wsign-compare -Wformat-security -Wmissing-include-dirs -Wformat-nonliteral -Wpointer-arith -Winit-self -Wdeclaration-after-statement -Wfloat-equal -Wmissing-prototypes -Wredundant-decls -Wmissing-declarations -Wmissing-noreturn -Wshadow -Wendif-labels -Wcast-align -Wstrict-aliasing -Wwrite-strings -Wno-unused-parameter -fno-common -fdiagnostics-show-option -fdiagnostics-color=auto
D: [pulseaudio] main.c: Running on host: Linux armv7l 5.10.11-v7l+ #1399 SMP Thu Jan 28 12:09:48 GMT 2021
D: [pulseaudio] main.c: Found 4 CPUs.
I: [pulseaudio] main.c: Page size is 4096 bytes
D: [pulseaudio] main.c: Compiled with Valgrind support: yes
D: [pulseaudio] main.c: Running in valgrind mode: no
D: [pulseaudio] main.c: Running in VM: no
D: [pulseaudio] main.c: Optimized build: yes
D: [pulseaudio] main.c: FASTPATH defined, only fast path asserts disabled.
I: [pulseaudio] main.c: Machine ID is 70f066db93dc41f490990fac4dab47df.
I: [pulseaudio] main.c: Using runtime directory /var/run/pulse.
E: [pulseaudio] core-util.c: Failed to create secure directory (/tmp/pulsectl-tests.ojcHQR): Permission denied
E
======================================================================
ERROR: setUpClass (pulsectl.tests.dummy_instance.DummyTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "pulsectl/tests/dummy_instance.py", line 217, in setUpClass
    cls.instance_info = dummy_pulse_init()
  File "pulsectl/tests/dummy_instance.py", line 78, in dummy_pulse_init
    try: _dummy_pulse_init(info)
  File "pulsectl/tests/dummy_instance.py", line 179, in _dummy_pulse_init
    ' failed to start or create native socket at {}'.format(p) )
AssertionError: pulseaudio process failed to start or create native socket at /tmp/pulsectl-tests.ojcHQR/pulse/native

----------------------------------------------------------------------
Ran 0 tests in 4.123s

FAILED (errors=1)

[mk-fg]

I did it in sudo because it was complaining about not being able to get system mode

It shouldn't be needing system mode, and idk what's going on there at this point, maybe some weird distro build/patches/configuration (it has to get that implicit --system=true from somewhere I guess), and it wasn't the case last time apparently, so eh, whatever, probably not worth looking into, unless someone actually wants to run them and has issues :) Thanks anyway.

As a side-note, I'd highly recommend to never assume that something might be intended to run with "sudo" unless it's stated explicitly, and you're sure it's worth it - for probably obvious reasons (might do something weird or stupid to the system).

[mk-fg]

E: [pulseaudio] core-util.c: Failed to create secure directory (/tmp/pulsectl-tests.ojcHQR): Permission denied Also this directory name it gets from tempfile.mkdtemp() call above, which has to create that dir to get/set the path for it in env, but apparently it runs in a parallel universe or something, I don't even... ¯\_(ツ)_/¯

EDIT: no, to be fair, it just gets created as root with sudo and pulse then runs in system mode, drops permissions and can't access it, tries mkdir, etc - not that mystical at all, I'm just tired :)

[mfeif]

As a side-note, I'd highly recommend to never assume that something might be intended to run with "sudo" unless it's stated explicitly, and you're sure it's worth it - for probably obvious reasons (might do something weird or stupid to the system).

Thanks, yeah, I know. I have 20+ years working on Linux boxes, and this is a headless rPi that I control; I knew what I was doing in this case :-) and trusted your tests.

I'm running in system mode on this guy since it's headless and its only purpose is to be my stereo even if nobody is logged in. It's possible that my local config is confounding your tests in some manner. 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.

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.

TLDR; I see you're tired. If you WANT to track this down, I'm more than happy to help. If not, thank you SO MUCH for your help. This is the second time you've helped me on this (see #3 from 5 years ago!).

[mk-fg]

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.