Sennadar Forums

Thank you!

Oh, wow!

Thanks, Fel!

Goodness! It appears that your creative engines are running like Karrine FTL hyperspace engines.

I don't know how you do it, but thanks again for all you do.

Thanks mate, that's awesome, got lots of reading to do to catch up with Flat Space

Thanks so much for all that you provide for our entertainment.

Awesome chapter Fel. Really excited about this story.

Thank you Fel.

Excellent work, Fel

thanks fel

Awesome work. Thanks Fel

Many thanks Fel.

Thanks Fel

thanks for the new chapter

thanks a lot.

But I've one issue with the edits. And that's the depiction of audio/video transmission being being stretched or compressed because of the time dilation.

That might have been the case if the signals were analog signals where the playback clock is basically part of the signal. But it just doesn't make any sense for a digital transmission, where the transmission is just filling a buffer at whatever speed the data arrives, and the data itself contains information about the frames per second of the video and samples per second of the audio streams, which are then played back based on the clock in the local hardware.

The effects you would see is either playing for a bit, then stopping with a "buffering..." message, then playing again, and so on, instead of the playback being stretched out. Or a "buffer overflow" (unlikely, the computers shouldn't have any trouble buffering even years of A/V streams, much less a few seconds or minutes, so it would probably just simply work) instead of the playback being compressed.

cpsF21ZwUVHp wrote:thanks a lot.

But I've one issue with the edits. And that's the depiction of audio/video transmission being being stretched or compressed because of the time dilation.

That might have been the case if the signals were analog signals where the playback clock is basically part of the signal. But it just doesn't make any sense for a digital transmission, where the transmission is just filling a buffer at whatever speed the data arrives, and the data itself contains information about the frames per second of the video and samples per second of the audio streams, which are then played back based on the clock in the local hardware.

The effects you would see is either playing for a bit, then stopping with a "buffering..." message, then playing again, and so on, instead of the playback being stretched out. Or a "buffer overflow" (unlikely, the computers shouldn't have any trouble buffering even years of A/V streams, much less a few seconds or minutes, so it would probably just simply work) instead of the playback being compressed.

Agreed - if your using BG1 or whatever the secure biogenic connection to the ships is - there is no lag since its a biogenic connection.

Wolfee wrote:Agreed - if your using BG1 or whatever the secure biogenic connection to the ships is - there is no lag since its a biogenic connection.

Well, it's not lag from the connection that's the issue, it's that the two endpoints (one in empty space, on in a galaxy) will have time flowing at different speeds.

So even if there is no lag in the connection and the signal is transferred in real-time as it is being created, if one side has local time running twice as fast as the other, you could get the effects described in the story, where the A/V is running slower or faster than normal. But only IF the signal is an analog one, where the signal itself contains the clock that drives presentation at the receiver.

With a digital signal, the latency or bandwidth of the actual data transfer doesn't matter in regards to the rate at which the signal is presented at the receiver. You have a digital stream of data, and part of that data is the information "there is a video stream with 30 frames per second here". The received data is written into a FIFO buffer at whatever speed it arrives, and the system that displays the video is reading data from that buffer at whatever speed is needs to for displaying the 30 frames per second according to a *local* clock.

So if there is a mismatch between the speed that the data arrives and the speed the data is used for displaying, you have two possible outcomes:

If the data arrives faster than it is being displayed (10 seconds pass for the sender for every 5 seconds that pass for the receiver) then all you need is enough space in your FIFO buffer to keep buffering all the data as it arrives, and there will be no visible problem with the playback.

If the data arrives slower than it is being displayed (5 seconds pass for the sender for every 10 seconds that pass for the receiver) then the playback will have to stop once the fifo buffer is empty, showing a "buffering..." message or something like that till there are a few seconds of video in the buffer, then starts playing again (based on the, faulty, assumption that the video data will keep arriving at the same speed as it's being used), only to stop again when the buffer runs empty. Rinse. Repeat.