kiwiclientd sound device unavailable
At 1641 GMT 2023-05-13, all the JTDX instances on one of my Ubuntu 20.04 desktop machines threw a "sound device unavailable" error. I've had this happen a couple of times before, but unfortunately I didn't note when, so this is the first time I've looked into what might be causing it in hopes of preventing it happening again.
From the logs:
13 May 16:41:54 pulseaudio: GetManagedObjects() failed: org.freedesktop.DBus.Error.NoReply: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.
13 May 16:41:32 gsd-media-keys: gvc_mixer_card_get_index: assertion 'GVC_IS_MIXER_CARD (card)' failed
13 May 16:41:32 gsd-media-keys: Unable to get default source
13 May 16:41:29 systemd: Reached target GNOME Sound sample caching handling.
13 May 16:41:28 gnome-shell: Window manager warning: Ping serial 1073672245 was reused for window 0x280138b, previous use was for window 0x2203381.
13 May 16:41:28 systemd: Started GNOME Sound sample caching handling.
That's the only mention of GNOME sound sample caching mentioned in logs going back to 2023-03-15 (and no mention of it at all in logs of another Ubuntu 20.04 desktop here). All both machine do is chew on KiwiSDR RXs feeding JTDX. 1641 GMT is 0041 local, so I wasn't doing anything with it at the time... anyone have any ideas? Looking around about "GNOME sound sample caching" & gsd-media-keys is only making me want to drink a beer.
I don't know if the author of kiwiclientd keeps up with the forum (rikvanriel on github). You might have to ask him there if he has any ideas.
Of all the problems I've been having since switching over to kiwiclientd, this one might have nothing to do with kiwiclientd & I was hoping that somebody might have an idea.
The last I heard from Rik was a bit over 3 months ago, so stopped reporting what I've been seeing with DTs wandering all over the place, kiwiclientd sometimes completely spitting the dummy & the latest: the 0625 GMT nearly-daily hiccup that does not appear to be due to Kiwi GPS corrections as first thought.
I now wonder if anyone uses kiwiclientd continuously as I do. JT-modes (other than WSPR) are best streamed, otherwise one never gets the hashes for "non-standard" & "compound" calls - which helped me hear more DXCC entities than BD7MQB when he developed DIgiSkimmer, despite his clearly hearing better overall than I do (loop out the window, half way up block of flats, obstructed by other blocks for most of the compass rose).
One thing I've thought of trying, but have yet to do, is to make a long recording with kiwirecorder & see what the DTs are like with it over say 10-15 hours. I don't know anything about Python, but can see things like the python-libsamplerate bug code in kiwirecorder that's not in kiwiclientd. And one of the problems I see is ever-increasing DTs on one of the machines, which makes me wonder if there's something a bit wonky with sampling rates.
All a bit frustrating.
I use sox for fixing sample rate issues
WA2ZKD: What I've observed on 40m from roughly local mid-day shortly after spring equinox from a nearby station (~100 km distant) CQing to himself that from past observation seems to have a fairly stable clock - is that after ~4 hours, DT increases from 0 to 0.8 sec.
The first 0.1 sec change happened after ~15 minutes.
The second 0.1 sec change happened after another ~20 minutes.
The third 0.1 sec change happened after another ~17 minutes.
The fourth 0.1 sec change happened after another ~20 minutes.
The fifth 0.1 sec change happened after another ~20 minutes.
The sixth 0.1 sec change happened after another ~40 minutes - though in the interim it jumped back 0.1 sec & had a number of glitches where the DTs suddenly dropped by 0.5~1.2 sec.
The previous period included the now-dreaded daily 0625 GMT Kiwi hiccup.
The next 0.1 sec change happened ~13 minutes after the 0625 GMT glitch.
The next 0.1 sec changed happened 18-19 minutes after the last one (given the trend, I can't be bothered to be more precise).
The final 0.1 sec change happened ~20 minutes after the previous one (now I can't give a rat's about time precision).
Rounding I would imagine might further explain the inconsistencies in the intervals noted above. Despite that, it does seem to be somewhat linear.
Cheers for the sox recommendation - that looks to be a great way to decimate my FLAC collection for listening whilst out-&-about.
I don't know jack about diddly (or is that diddly about jack?) to do with python, so haven't a clue if the python-librsamplerate bug previously mentioned might have anything to do with this. I suspect I'm more likely to be successful at hacking that into kiwiclientd than jacking up the rad cap & driving sox under it. ;^)
I can only speak to the samplerate bug. Currently, the resample option in any python application does not do any fractional correction by fixed point math. I found that while trying to compensate the kiwi's slightly higher than 12,000 rate. sox can use FP and give you exact resampled data.
Well, ask about one thing that seemed like an easy one & end up finding out what probably explains the problems with JT-mode DTs I'm having with kiwiclientd - cheers for that, WA2ZKD!
Pardon me asking: what was the actual rate when the Kiwi's presenting 12k?