Seemingly unable to detect playing audio - crashes when run as root

[MoralCode]

no matter what i do i cant seem to get swyh-rs to detect any playing audio on my linux (kubuntu 22.04) machine as detected by the RMS monitor option.

the only time i got it working was when I had a usb mic plugged in and saw a little movement of the RMS monitor and was able to get it to play on my sonos speaker (it was quiet and delayed due to the audio path being my laptop -> speakers -> usb mic -> my laptop/swyh-rs -> sonos).

since unplugging that mic nothing is being detected by swyh-rs. have tried multiple apps that produce audio, such as freetube (youtube client) and clementine.

the available audio sources listed in swyh are: default, samplerate, pulse, and four options named "hw:CARD=PCH,DEV=#" where # is 3,7,8,and 9 respectively.

i saw #31 (comment) while searching and that made me think to try running as root. when running as root it seems to encounter some (presumably minor) issues before detecting the four hw:CARD... devices from earlier and then crashing. I suspect it found a device that is not being handled right so i'll see if i can make it not crash but wanted to reach out in case i cant make it work.

heres the log that i get when trying to run as root:
log.txt

[dheijl]

I don't have access to my development environment now, but is it possible that audio monitoring is not enabled?
I use pavucontrol to enable monitoring of input devices on my Linux machines (Mint).

As for running as root: I will test as soon as i can.

[MoralCode]

can confirm that audio monitoring was the reason for the no audio. Problem resolved by opening pavucontrol, running swyh-rs, opening the recording tab, and setting the "from" dropdown to "monitor of < my BT headphones that were currently playing something>"

the root thing may technically be a different issue that i just happened to encounter while trying to chase this down (at the time i thought it may be some kind of permissions thing). happy to make a new issue for that if you want!

[MoralCode]

also for anyone else reading this with the same usecase of wanting to use some older sonos S1 era speakers as a set of computer speakers: i did notice a little bit of an "echo" effect while listening to the same audio (from a video) from both the sonos and my headphones using the method above, but i was quite impressed by how perceptually minimal the AV delay is when listening through just the sonos, even though this testing was done over wifi. According to this video it seems like AV delay seems to really start becoming perceptible starting at about 250-300ms of latency.

With the 80kb buffer mentioned here, which by my math is about 1.75 ms for 128kbps audio, it seems as though there is still plenty of room for additional delays (networking, sonos buffering .etc) before things start to get noticeably out of sync. While this may not be the best if you need things to be perfectly (technically) synchronized, "perceptually synchronized" is good enough for my usecase.

Edit: reading the linked comment in more detail, it seems like this low delay may not hold true for a stereo pair setup, but that isnt somehting particularly important to me

[dheijl]

I cannot reproduce the crash when running as root here, Linux Mint 21.1 Vera Cinnamon version (Ubuntu 22.04 based).

[MoralCode]

Well i was about to send a message saying the issue is no longer happening for me, but then it started happening briefly. I Still haven't found a reliable way to reproduce it, but I suspect it has to do with my headphones (Skullcandy Hesh 2 Wireless) going to sleep or something (i.e. after a little while of no audio being sent over bluetooth) while still being connected and maybe getting into some weird state.

that said i was also playing with settings like the "add virtual output device for simultaneous output on all sound cards" in Kubuntu Audio settings as well as unplugging and plugging in my Fifine K050 usb microphone, so its really not a great scenario

edit:
it also seems like the dmesg logs show these curious entries:

[ 2916.155284] input: Hesh 2 Wireless (AVRCP) as /devices/virtual/input/input33
[ 3081.313720] input: Hesh 2 Wireless (AVRCP) as /devices/virtual/input/input34
[ 5930.919113] input: Hesh 2 Wireless (AVRCP) as /devices/virtual/input/input35

i didnt think to look at dmesg until way later so i dont know for sure if they line up with the times that swyh-rs has crashed, but it seems somewhat likely.

edit 2: it appears as though turning the headphones off and then on again generates a new line like this in dmesg and sometimes causes the next run of swyh-rs to crash (maybe it depends on when the list of devices is fetched or if the OS provides a stale/old file (like /devices/virtual/input/input33) after a newer one exists for that device

[dheijl]

I don't have any experience with bluetooth audio devices, but I suppose that losing the connection with a battery powered device that goes to sleep can cause problems in the CPAL internal audio device state that gets out of sync with the actual device state in the kernel on reconnection. I have no idea if it is possible to detect these device changes in CPAL or if it is possible to handle this situation (without restarting the app).

[MoralCode]

Honestly, I wouldn't sweat it at this point:

• there should be enough info here for anyone else who comes across this to know what to poke (i.e. turning a bluetooth device on or off) to potentially create their own workaround
• It seems like I may be the only one affected by this as of now and it generally seems like a relatively low-impact issue
• its probably not worth the dev time on your end to fix - especially since my main issue was resolved by your first comment

I'll leave it to you to close/mark this issue however you prefer. Thanks so much for your insights and all the keywords in your comments that helped me narrow things down!

[dheijl]

For the moment CPAL does not support device disconnection/connection events:
RustAudio/cpal#373
So I'll leave this open and come back to it when CPAL implements this.