[Suggestion] Delay Settings 90sec for Live CSS Matches

[Serce1975]

Is it possible to add a feature that could handle the delay of 90sek. if i watch my m8s in a match, i am in the same ts3 channel, but their ingame commands and the hltv broadcast with 90 sec delay didnt match (of course) .. so if i possibly record the ts3 voices and play it with 90sec delay it will match, u know what i mean? sry4bad-english. just for the case, i am testing a new member for the mainteam and i wanna watch him playing with the lineup, so it would be very nice, when i can rate his critical commands or his reaction to the commands by the captain..

i hope u understand my question

[dante696]

This idea does not sound bad for all these hardcore gamers.
But a delay of 18 seconds means, that you will timeout and the most user wan't a fast reply from their mates.

Why you don't put a delay in your software, when you put the video and voice together? (if there is a video in the end)

[Serce1975]

here i am again.. took a while but i saw your post now..

i think u didnt understand my scenario.. i am not talking about video and voice cuting. all had to be in realtime..

think of a counterstrike:source match 5on5 .. i am a spectator on HLTV with a delay of 90sec.. but i am in the same channel with the 5 playing members. my hltv stream is 90sec behind their commands. u know?

now the question is, how can i get a delay of 90sec in the channel? would be nice if ts3 can stream in another channel e.g. with that delay or something..

[kraze1994]

Hi,

Does TS3 support any type of client side buffer? Reason is that I have set up a couple of music streaming bots for TS3. They work great however when a little bit of ping is added to the mix they act up, it is not terrible but I would prefer it not happening.

I have tested this theory against a 0 ping environment and a 20 ping environment, the 20 ping set up was causing the audio to skip or pop.

My plan is to add a good 1-3 second buffer but I am not sure that is possible server side for TS3.

[Peter]

Hi,

the receiving client actually buffers incoming sound data, but this is not a configurable variable currently. It is optimised for low delay so losing a packet once in a while is considered "ok" when it gives us the benefit of faster (closer to real time) audio.

[kraze1994]

Hi,

the receiving client actually buffers incoming sound data, but this is not a configurable variable currently. It is optimised for low delay so losing a packet once in a while is considered "ok" when it gives us the benefit of faster (closer to real time) audio.

any plans to add a configurable delay? maybe by channel? I see that the current codec settings support lower bandwidth use by adding a delay, being able to make it longer would be great.

I can also see a lot of other uses for this when it comes to streaming or broadcasting scrims..etc

I should say that I am personally not looking for an 18 second delay, something along the lines of 5 seconds is good.