Closed K6TD closed 2 years ago
an update..this might be a task priority issue and that scratchiness might be very short gaps.
this might be packet loss, or sample loss.
Could you share the audio recording? If it's not possible to directly embed the audio file here, you could upload it to soundcloud or youtube.
I've discovered the effect comes and goes, and I don't know the trigger, or the pattern. The morning (local time), I found the audio to be mushy and scratchy. It was about 30 minutes before I could record the Audi. By that time it 599 (preping for WPX CW). I have a handful of recordings with excellent audio quality. I will record when the audio quality bad, again, and upload.
Roger. You could record a brief video with your phone, next time you hear this mushy and scratchy audio.
Still trying to track down the cause of this. Recorded audio indicates dead silence (no audio) right before the noise. The stream is TCP into the NATs server, and then TCP back out of the NATS server, so packets really could only get lost in the NATS server. No evidence that's happening.
Suspect the VPN may be creating gaps in the audio flow, as it tries to put packets into a flow. You might call this scrunching.
Testing various ideas.
We did replaced the VPN server hardware with a new machine - gobs of memory, intel i7, built in crypto, PCI bus ethernet ports. Not much real effect.
The VPN is soft ether.
I might have found the problem. I was able to reproduce the "scatchy" audio, after experimenting with different combinations of audio channels and sampling rates. In the pbReader
(protocol buffers reader) audio source, I used to initialize a buffer for stereo samples which is then forwarded as part of an audio.Msg
to the audio Chain for futher processing. Eventually the audio.Msg
arrives at the scWriter
(soundcard writer) sink, where the audio samples are then adjust to the channels and sampling rate of the actual consumer (audio device).
It seems that under a particular combination of an allocated stereo buffer, but mono samples and meta information in audio.Msg
indicating mono samples causes then the scWriter
to wrongly adjust the audio samples. This then results in the mentioned scratchy audio.
I have fixed this behaviour in commit 2f239424
I will create a new remoteAudio release within the next days.
tested on 0.5.5. No scratchiness heard. Closing.
This is a query for other users.
My audio path from radio to headphones has a lot of scratchiness to it. Not white noise, more like impulse noise. I've arecord'ed from the same audio interface as the remoteAudio server is connected to - perfect audio. Two separate "users" have reported the same.
If anyone has any idea, I'd appreciate your thoughts.