Skip to content

notes.org

Latest commit

 

History

History
117 lines (89 loc) · 4.64 KB

notes.org

File metadata and controls

117 lines (89 loc) · 4.64 KB

Random project Notes

TODOs

Consider volume control from the master

Consider splitting the channels to get 5.1 without cables.

e.g. play 2.1 directly (stereo + subwoofer), play center + sides over wifi.

Implement packet reordering upon arrival

Still doesn’t seem needed over my crazy LAN. Will wait for requests. I’ve noticed problem with duplicated packets. Not very problematic but numbering the packets in header would fix it and handle drops immediately.

Track stream-time instead of arrival-time.

  • Might fix desync on stream searching, jumping songs.
  • Fill fix certain outputs when more data is pumped into input than really playable. For example a player can decode a local mp3 and push it all into the buffer.

Handle input overflow case

Packetizer will wait for the chunks to be within a time-marking window.

But how long should it wait? How many chunks in the input buffer is ok?

  • Do a test with mpg321.

Handle input underflow

Never jump stream-time into the future.

Silence detection resets the time. Short silence can cause the time to jump forward.

Bugfixing

ctrl+s, ctrl+q on receiver causes sound artefacts

Fixing this can probably fix some other problems.

Replace datetimes with UTC timestamps

Handling correct datetimes seems costly and overly complicated.

[#C] Migrate most warnings to logging module.

REVERTED Idea: Insert silence every n-th chunk to make it less noticable

Still Idea: Or duplicate original chunks with certain properties but it sounds bad. Silence is inserted currently.

This seems to be not necessary for pyaudio where the output queue is much more controllable.

Convert receivers to use pyaudio (or sth) to minimize the latency

Queue getting empty case seems to need a closer look

It caused desync due to output buffers having varying levels of fill. With pressurised player the output buffers are flooded with silence in case of empty queue so that latency is constant.

Idea: Initial output buffer pre-fill to even-out latency

Did it in pressurised player during initialization.

Handle errors which should cause event loop to stop.

Should work although raises ugly exceptions.

Add additional frame type with a sender absolute time to do a time sanity check

Sanity check added and also fixed sync problem on packet loss

CANCELLED Add check for chunk table overflow to fix memleak if pulseaudio hangs

Happens on a native rpi audio card.

This shouldn’t happen now with pressurised player. IO is moved further from this queue and player queue length is controlled.

CANCELLED Expand timemark from 2-byte to 3-bytes to cover a whole hour

Use it for warnings if the time seems out of acceptable range (anything over 1 minute will be unacceptable).

Doesn’t seem so important and warning are now implemented using STATUS frames which also handles other problems.

Current timemark format

Create timemark:

now = current absolute UTC time mark = now + latency # Move by latency into the future. Now from the absolute time: 2017.02.23 23:14:29.123456: Take only seconds and milliseconds (µseconds / 1000)

  • Take seconds: 29
  • shift them: 29000
  • add miliseconds: 29123

This gives range from 0 to 59999 and fits 16 bits.

Closer to -30000 - 30000 in fact if taking into account lagging chunks.

Upon reception we might have:

------|minute start|-------|now|------|minute end|------- ^ - TIME MARK WITHIN MINUTE

Case 1: it falls later within current minute. Assume it’s the same minute, just later and create an absolute time based on current and timemark.

–|m start|----|now|----|m end,m+1 start|---- ^ - TIME MARK WITHIN MINUTE

Case 2: falls before current time within current minute. Assume it’s in fact happening in the next minute:

–|m start|----|now|----|m end,m+1 start|----|m+1 ends| ^ - ABSOLUTE HERE

This two cases allow to reassemble the absolute time.

Note: In cases of not synchronised time or great lags on packet reception I’ve added additional two cases for handling mark in the past. This reduces the mark resolution to 30 seconds into the future and 30 seconds into the past - well enough for practical solutions.