Vario sound stutter

[iglesiasmarianod]

I built the latest image and vario has a strange behaviour in my device. Every couple of seconds sound seems to freeze on a frequency, then it repeats the last played frequencies before correcting itself.
If sound where numbers and you expect 1, 2, 3, 4, 5 you get 1, 2, 3, 3, 3, 1, 2, 3, 4, 5.
Could not reproduce the problem with sensord_0.3.4 (stable version).
I've attached an audio file. You can hear the stutter around 4 secs and 15 secs.

Vario.mp4

[eku60]

Hello,

we noticed the same problem.
I assume it has to do with the change early in spring this year, so before bug #39 (#40) was corrected.
I have heard of another OV-user who has a corrected implemantation but don't know whether or not his corrections for that problem are already integrated in the variod.
Besides this, to my mind this is an issue of the variod, not sensord, and should be moved there.
When climb rate is increasing (let's sa yfrom 0-2m/s), then the increase stops or climb rate decreases (let's say from 2 to 1 m/s) and then increases again (let's say from 1 m/s to 3m/s) the sound starts again by 0 m/s.
It is very difficult to get an useful information on climbrate by sound, the vario indicator on the screen is ok. It is a variod-problem, I think.

Regards
eku60

[hpmax]

@iglesiasmarianod Sorry for the long delay.

1. If you aren't using the latest variod and sensord, please update to the latest.
2. Please take a look at issue Blips in MS5611 sensor data #23, and look at my post on August 1st. This appears to be important. Around 16.5 seconds into your reading I hear a pop/click noise that sounds like the FIFO buffer emptying. If that's happening that might explain the problem you have.
3. If the problem is still there after doing the first two things, we need to isolate this between variod and sensord. Please provide a log of the vario data. This could be done through xcsoar, and I think through variod and sensord.

I have trouble believing there are any more problems in variod, so I suspect that it's bogus info coming out of sensord.

[iglesiasmarianod]

@hpmax don´t worry and thanks for your reply, I've been pretty busy too so I wasn´t able to investigate a little further this issue.
I'll install this version and start flying with it to test it further. I see an increase in CPU usage and a pause in the input stream from the device monitor every time the sound stutters. Sometimes restarting OV fixes it.
I'll build the latest testing version and try it to see what happens.

[iglesiasmarianod]

Hi @hpmax, I updated my OV to the latest stable releases. Sensord 0.3.5 and variod 0.3.1. The stutter continues.
I then edited sensord.service to start the service as simple without deamonizing (Type=simple -f option) with the same result, the stutter is still there.
I'll try to use sensord-testing and variod-testing as they are, and modifying sensord.service to see if it changes anything.
If I still have the issue, I'll start logging vario data from XCSoar as you suggested.

[hpmax]

@iglesiasmarianod I have a completed and (mostly) functioning second gen board. I'm putting my efforts into developing new software for that (and resolving some minor hardware issues). At present the software will simply replace sensord and variod and hence may still be vulnerable to the FIFO buffer emptying although the new board has an ESP32 on it, which should be able to do real time audio synthesis preventing the issue you're seeing. Unfortunately, I have a ways to go before I am at that point.

[iglesiasmarianod]

I've tested the lastest sensord and variod and the problem is still there.
Values seem to be OK. Vario widget does not show a jump each time the sound glitches.
Data stream from variod to XCSoar freezes for a moment at every glitch. I'll try to log XCSoar device but I think we won't find anythin interesting in the logs.
@hpmax great! I'd love to see it when it is ready.
Do you have a way of logging variod or sensord output stream? Any idea?
I'm still testing Warrior. We had problems with variod disconnecting the socket before, when the change from armstrong to warrior was made.
I'll test Hardknott as soon as possible to see if the problem lies there.

[hpmax]

@iglesiasmarianod This freezing behavior sounds like it is more likely in variod or pulsation. I don't have a good answer for you other than to say that all three daemons (pulsation, sensord and variod) seem susceptible to it and it's made worse if the daemons are run as daemons. If you explicitly run them in "regular" mode (-f in variod/sensord, and some other option for pulseaudio) and then background them they seem much less inclined to exhibit that behavior.

It seems Max Kellerman has made a bunch of posts on meta-openvario and may be interested in figuring out a way to fix this. Perhaps check with him.

As for "ready" that's a moving target. I have working hardware (haven't tried installing a differential pressure or the POM block) although the new 12V->5V converter doesn't work. I have not used nor tested the ESP32 or audio amplifier. I have updated sensord to use the LPS22 instead of MS5611 although code quality isn't where it should be. It recognizes the LSM6DSM but doesn't use it. It recognizes the MMC5983MA and reads days but doesn't use it. I have added support for one of the two new differential pressure sensors. But it should be usable as a drop in replacement for the old sensorboard with my updated software.

[iglesiasmarianod]

I'll serach Max's posts to read them.
I've noticed that the glitch depends on the startup. If it starts OK, It works OK. If it fails, it fails until reset.
Seems random right now depending on each individual startup and not following any pattern.
I'll test variod with -f option, but most important I want to test hardknott as I'm starting to suspect a OS related problem.
Are you using Arduino IDE to code for the ESP32 or Eclipse?

[hpmax]

@iglesiasmarianod I am convinced it is OS related. I don't believe its a code issue.

As for ESP32... at present, I'm bypassing the ESP32 and running everything through sensord. I have no real experience doing ESP32 development and I wanted to reduce the number of variables for testing the hardware and new algorithms as quickly as possible.

[iglesiasmarianod]

@hpmax tested hardknott and seems the problem is not present.
I'll test some more and close this issue if it is solved.