wrapping my head around clocksync

[ruben malchow]

hi,

i am currently using a handcompiled version 1.17.1 on fedora to play with the new clocksync element. to test cross-host syncing, i have three identical VMs, one acting as the "server", and two acting as "clients". currently, i am trying to get a basic setup to work with udpsink and udpsrc, although eventually, i would love to be able to tcp-stream vorbis.

my issues start at the very beginning: the second i start introducing clocksync, things get extremely choppy. so this works fine:

gst-launch-1.0 uridecodebin uri="http://[mp3 stream]" ! audioconvert ! queue !  alsasink

while this:

gst-launch-1.0 uridecodebin uri="http://[mp3 stream]" ! audioconvert ! queue ! clocksync ts-offset=100000 !  alsasink

gets extremely choppy (for any value of ts-offset)

what i really want is to have this:

server

   [any source] -> [normalize] -> [vorbis enc] ->  [tcp server sink]

clients:

   [tcpclientsrc] -> [vorbis dec] -> [clocksync] -> [alsa]

tcp or udp multicast doesnt really make a difference now - the point is more that i dont really have a good grasp of the model behind all this to easily build this. also, documentation on how to configure the clock is ... sparse? i would appreciate any simple examples and hints regarding the sync (which is, in my opinion, a really great addition).

.rm

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[ruben malchow]

hi again,

i have now come up with this:

server:

     gst-launch-1.0   uridecodebin uri="[mp3 stream]"   ! audioconvert   ! lamemp3enc    ! queue   ! tcpserversink host=192.168.71.163  port=4999

client:

     gst-launch-1.0   tcpclientsrc host=192.168.71.163 port=4999 do-timestamp=true   ! decodebin   ! audioconvert   ! queue   ! clocksync !  alsasink sync=false

... and this gives me a playable stream, and sync is ok over a LAN between several VMs ... but that's pure luck and the fact that it's a virtual setup with no wifi or competing traffic involved. i have to say though that even if one client is off (e.g. in the beginning), it usually converges again after a second or two.

some issues:

   - i wanted to use vorbis. not doing thet b/c it seems the problem with the format specification on the client side is not really solvable.

   - i am not using rtppay / depay here - mostly because i dont know which one to use on mp3

   - the second i set "sync" to "true", it essentially stops working - it still plays short pieces every now and then, but no continuous stream

i think i am probably making some mistakes. what's missing?

.rm

On Sat, Jun 27, 2020 at 5:08 PM ruben malchow <[hidden email]> wrote:

hi,

i am currently using a handcompiled version 1.17.1 on fedora to play with the new clocksync element. to test cross-host syncing, i have three identical VMs, one acting as the "server", and two acting as "clients". currently, i am trying to get a basic setup to work with udpsink and udpsrc, although eventually, i would love to be able to tcp-stream vorbis.

my issues start at the very beginning: the second i start introducing clocksync, things get extremely choppy. so this works fine:

gst-launch-1.0 uridecodebin uri="http://[mp3 stream]" ! audioconvert ! queue !  alsasink

while this:

gst-launch-1.0 uridecodebin uri="http://[mp3 stream]" ! audioconvert ! queue ! clocksync ts-offset=100000 !  alsasink

gets extremely choppy (for any value of ts-offset)

what i really want is to have this:

server

   [any source] -> [normalize] -> [vorbis enc] ->  [tcp server sink]

clients:

   [tcpclientsrc] -> [vorbis dec] -> [clocksync] -> [alsa]

tcp or udp multicast doesnt really make a difference now - the point is more that i dont really have a good grasp of the model behind all this to easily build this. also, documentation on how to configure the clock is ... sparse? i would appreciate any simple examples and hints regarding the sync (which is, in my opinion, a really great addition).

.rm

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[ruben malchow]

hi again,

i have now come up with this:

server:

     gst-launch-1.0   uridecodebin uri="[mp3 stream]"   ! audioconvert   ! lamemp3enc    ! queue   ! tcpserversink host=192.168.71.163  port=4999

client:

     gst-launch-1.0   tcpclientsrc host=192.168.71.163 port=4999 do-timestamp=true   ! decodebin   ! audioconvert   ! queue   ! clocksync !  alsasink sync=false

... and this gives me a playable stream, and sync is ok over a LAN between several VMs ... but that's pure luck and the fact that it's a virtual setup with no wifi or competing traffic involved. i have to say though that even if one client is off (e.g. in the beginning), it usually converges again after a second or two.

some issues:

   - i wanted to use vorbis. not doing thet b/c it seems the problem with the format specification on the client side is not really solvable.

   - i am not using rtppay / depay here - mostly because i dont know which one to use on mp3

   - the second i set "sync" to "true", it essentially stops working - it still plays short pieces every now and then, but no continuous stream

i think i am probably making some mistakes. what's missing?

.rm

On Sat, Jun 27, 2020 at 5:08 PM ruben malchow <[hidden email]> wrote:

hi,

i am currently using a handcompiled version 1.17.1 on fedora to play with the new clocksync element. to test cross-host syncing, i have three identical VMs, one acting as the "server", and two acting as "clients". currently, i am trying to get a basic setup to work with udpsink and udpsrc, although eventually, i would love to be able to tcp-stream vorbis.

my issues start at the very beginning: the second i start introducing clocksync, things get extremely choppy. so this works fine:

gst-launch-1.0 uridecodebin uri="http://[mp3 stream]" ! audioconvert ! queue !  alsasink

while this:

gst-launch-1.0 uridecodebin uri="http://[mp3 stream]" ! audioconvert ! queue ! clocksync ts-offset=100000 !  alsasink

gets extremely choppy (for any value of ts-offset)

what i really want is to have this:

server

   [any source] -> [normalize] -> [vorbis enc] ->  [tcp server sink]

clients:

   [tcpclientsrc] -> [vorbis dec] -> [clocksync] -> [alsa]

tcp or udp multicast doesnt really make a difference now - the point is more that i dont really have a good grasp of the model behind all this to easily build this. also, documentation on how to configure the clock is ... sparse? i would appreciate any simple examples and hints regarding the sync (which is, in my opinion, a really great addition).

.rm

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel