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.
73, VR2BG.
Comments
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.
73, VR2BG.
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. ;^)
73, VR2BG.
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?
73, VR2BG.
12001.x, x=1-3
I just signed up for the forum after seeing these posts.
Now I know why the issue has not been showing here: I have not been using the resampling in kiwiclient, but instead have relied on resampling done by pulseaudio/pipewire at the system level.
Without resampling being done in kiwiclient, the issue has not been happening here.
I'm not entirely sure what to do about this issue. Could kiwiclient count the samples and look at timestamps in the stream (does the kiwi send timestamps?), and use that to occasionally drop or add a sample to get the sample rate fed to samplerate to match what we claim we are feeding samplerate?
Is there a better way forward?
Christoph added fractional resampling to kiwirecorder some time ago (see the
-r--resampleoption). So you can resample on the fly from whatever odd sample rate the Kiwi happens to be producing to, for example, exactly 12 kHz. So take a look at kiwirecorder.py and maybe incorporate the same scheme in kiwiclientd.If the high-quality libsamplerate Python package has been installed it will use that. Otherwise it falls back to low-quality interpolation.
I tried the -r earlier this year and founf that python didn't do it right. I ended up piping through sox . Has the Python thing been verified to be fixed?
No, I think it's okay. I just tried it and the results sound fine. Both for small fractional resampling (12001 => 12000) and larger (12001 => 6000). And doing a
make info, which causes the Makefile to do asox --info *.wav, shows the expected results.I see now there is this comment in the code. So maybe there was an issue when you tried it last:
## work around a bug in python-libsamplerate:
## the following makes sure that ratio * 512 is an integer
## at the expense of resampling frequency precision for some resampling frequencies (it's ok for 375 Hz)
per Christoph as of today "The python libsamplerate module is broken"
per Christoph as of today "The python libsamplerate module is broken"
More precisely, because the processing is done in chunks, as opposed to using the callback interface, there can be gaps, because
libsampleratemay not use all input samples.If
libsamplerateis installed you can avoid using it as follows:USE_LIBSAMPLERATE=False ./kiwirecorder.py ...per Christoph as of today "The python libsamplerate module is broken"
I'm sorry, I missed this. Where is this stated? (for future reference)
I'm sorry, I missed this. Where is this stated? (for future reference)
Here is my pull request which never got merged: https://github.com/tuxu/python-samplerate/pull/6
Well, if the guy is not going to merge Christoph's changes then maybe we should just incorporate all his work into kiwiclient. MIT license after all..
There's a future branch using
pybind11. It has the same issue, i.e., not exposing the number of used input samples. The way to go is probably to use the callback interface. This implies to have one additional thread per connection.both sox and soxi are useful tools for working on this kind of thing. Although sox started life as a Linux tool, there are MS and Mac versions of it.