Re: Clock drift between wm8731 and aloop in sBitx
|
Rafael, A slightly unwieldy solution is to use IAX2 protocol that can be written in less than 100 lines of code and run an instance of Asterisk to provide all kinds of gateways. One could even stream to Skype!? I did write some channels foe asterisk when I was a young man and remember how to do the extensions. - f
On Wed, Jun 7, 2023, 6:08 AM Rafael Diniz < rafael@...> wrote: Hi Ashhar,
I like this idea. I think we could have both an optimized low latency
kernel / alsa setup, and built on top of it, an RTP media gateway. It
might be needed a samplerate converter (SRC is fine, aka libsamplerate)
to fix for small jitters and drifts from RTP sources and sinks that are
not clock synced with the wm8731.
The advantage of "keeping close" to alsa is keeping latency and cpu
usage low. For eg, one can specify the wm8731 to be the "driver" for a
alsa loopback through the "timer_source" parameters of the kernel
module, forcing any local application (like fldigi) to follow the
hardware dsp when accessing the alsa loopback, so no need for
resampling. Also, by using fewer layers of software above the driver,
will always help latency.
Anyway, I'm still trying to sort out the more lower level stuff. But
certainly RTP (SIP for the control plane / announcement ?) is the way to
go. I'm doing a recap in the AES67 and SMPTE 2059 to remember how the
sync is done on professional equipment which do not share a clock source.
Cheers,
Rafael
On 6/7/23 00:55, Ashhar Farhan wrote:
> Rafael,
> As you have better linux audio chops than I do, here is my plan to
> clean all this up:
> 1. The sbitx core will transmit RTP audio data, either PCM or Opus to
> a multicast address within the RPI.
> 2. The sbitx will also receive RTP audio from other apps over a
> separate RTP incoming port.
> This will simplify the sbitx audio system. Now, to use this with other
> apps, we have to define audio sources and audio sinks that map to the
> RTP ip/ports.
> This approach is used by Phil, KA9Q, in his sdr radio as well. Though,
> he uses multicast between various modules within his radio software,
> we need it to talk ALSA/Jack/Pipewire, etc.
> The key thing is to be able configure RTP ports are virtual audio
> sources/sinks where the clock sync is handled by the audio subsystem.
> - f
>
> On Wed, Jun 7, 2023, 5:07 AM Rafael Diniz <rafael@...> wrote:
>
>? ? ?After some outstanding drifts and latency on the sBitx, I realized
>? ? ?the
>? ? ?audio dsp and the alsa aloop were not locked. We need to use
>? ? ?"timer_source=" parameter for the snd_aloop module to indicate the
>? ? ?correct "timer source" for the virtual audio device, otherwise,
>? ? ?wm8731
>? ? ?and aloop clocks drift.
>
>? ? ?Will do some tests and write a more detailed report, as soon as I
>? ? ?get an
>? ? ?acceptable (low) latency. I ended up ditching all the gtk stuff in
>? ? ?sbitx
>? ? ?codebase and managed to reduce the latency, but most likely for even
>? ? ?more lower latency, there is a need to re-organize also the ALSA
>? ? ?part.
>? ? ?May be using
>? ? ?
>
>? ? ?as reference and adding the SSB code as alsa plugin could be a
>? ? ?good way
>? ? ?to go.
>
>? ? ?That being said, I managed to get my first VARA connection with the
>? ? ?sBitx, but there are still some loose ends to adjust.
>? ? ?: )
>
>? ? ?Cheers,
>? ? ?Rafael
>
>
>
>
>
>
>
|
