Liquidsoap

UDP transmission protocol

Details

  • Type: New Feature New Feature
  • Status: Closed Closed
  • Priority: Minor Minor
  • Resolution: Fixed
  • Affects Version/s: None
  • Fix Version/s: 1.0.0-beta3
  • Component/s: None
  • Labels:
    None

Description

Some people have expressed the need for a way of transmitting audio data over UDP. Of course some data might be lost or wrongly ordered but they don't mind (it is actually a feature for them).

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
David Baelde added a comment -
I have just commited a first version. Locally it works fine with output.udp(host="localhost",port=6666,%mp3,source) on one side and input.udp(host="localhost",port=6666,"audio/mpeg") on the other end. It should be used with care. It won't work with all protocols (won't be fixed) and may crash violently in some circumstances (that should be avoided). I could not test it between two distant machines because I need to work around firewalls and NAT.
Show
David Baelde added a comment - I have just commited a first version. Locally it works fine with output.udp(host="localhost",port=6666,%mp3,source) on one side and input.udp(host="localhost",port=6666,"audio/mpeg") on the other end. It should be used with care. It won't work with all protocols (won't be fixed) and may crash violently in some circumstances (that should be avoided). I could not test it between two distant machines because I need to work around firewalls and NAT.
Hide
Permalink
David Baelde added a comment -
I just tested a remote UDP link, with both machines behind routers doing NAT. On the receiver end I setup port forwarding for UDP on port 6666 and had to set host="0.0.0.0". For the emitter I just set the host to be the IP address of the receiver's router.

I also realized that %wav (corresponding to "audio/mpeg") won't work because it expects a header -- an optional headerless mode, even very crude (always s16le@44100Hz) could be useful for monitoring. Obviously Ogg formats are ruled out for the same reason. I could not test AAC nor MP4 yet.
Show
David Baelde added a comment - I just tested a remote UDP link, with both machines behind routers doing NAT. On the receiver end I setup port forwarding for UDP on port 6666 and had to set host="0.0.0.0". For the emitter I just set the host to be the IP address of the receiver's router. I also realized that %wav (corresponding to "audio/mpeg") won't work because it expects a header -- an optional headerless mode, even very crude (always s16le@44100Hz ) could be useful for monitoring. Obviously Ogg formats are ruled out for the same reason. I could not test AAC nor MP4 yet.
Hide
Permalink
Romain Beauxis added a comment -
We may be able to send a data header now for wav and ogg. I always forget why it is not advised tho.. Dare to write it again ? :)
Show
Romain Beauxis added a comment - We may be able to send a data header now for wav and ogg. I always forget why it is not advised tho.. Dare to write it again ? :)
Hide
Permalink
David Baelde added a comment -
Sending a header at the beginning of the UDP stream does not fit with the idea of UDP streaming. It'll only work if you're lucky, so I'd rather not implement it at all. I don't want to clog the code and spend extra time on it until I see a clear need. For now, besides artists, the potential need is low-latency monitoring. It can be done in MP3 or audio/basic for now, without headers; that should be enough for first tests.

Anyway, people will always need to specify a mime type for UDP inputs. This type can carry all the header information, as with audio/basic. When needed we can create conventions on more mime-types, for example audio/cd for stereo 44100Hz s16le (we can even come up or re-use a syntax for mime types describing all kinds of PCM streams). This should be a good plan for PCM. Concerning OGG I think there are much bigger problems than the header/mime-type, since the loss of one packet desynchronizes everything iirc.

Two more relevant improvements for UDP I/O in my opinion: (1) check why AAC+ doesn't work (while it does over TCP with icecast) and fix it; (2) possibly send metadata as out-of-band data. I'm not planning to touch those before I see a user's need, but I'll spend my coding time fixing release-critical bugs.
Show
David Baelde added a comment - Sending a header at the beginning of the UDP stream does not fit with the idea of UDP streaming. It'll only work if you're lucky, so I'd rather not implement it at all. I don't want to clog the code and spend extra time on it until I see a clear need. For now, besides artists, the potential need is low-latency monitoring. It can be done in MP3 or audio/basic for now, without headers; that should be enough for first tests. Anyway, people will always need to specify a mime type for UDP inputs. This type can carry all the header information, as with audio/basic. When needed we can create conventions on more mime-types, for example audio/cd for stereo 44100Hz s16le (we can even come up or re-use a syntax for mime types describing all kinds of PCM streams). This should be a good plan for PCM. Concerning OGG I think there are much bigger problems than the header/mime-type, since the loss of one packet desynchronizes everything iirc. Two more relevant improvements for UDP I/O in my opinion: (1) check why AAC+ doesn't work (while it does over TCP with icecast) and fix it; (2) possibly send metadata as out-of-band data. I'm not planning to touch those before I see a user's need, but I'll spend my coding time fixing release-critical bugs.
Hide
Permalink
Romain Beauxis added a comment -
Thanks!
Ideed, reading Vorbis's RTP RFC, sending correct headers in UDP seems to be a nightmare:
http://tools.ietf.org/html/rfc5215#section-3
Show
Romain Beauxis added a comment - Thanks! Ideed, reading Vorbis's RTP RFC, sending correct headers in UDP seems to be a nightmare: http://tools.ietf.org/html/rfc5215#section-3
Hide
Permalink
David Baelde added a comment -
The UDP I/O is still experimental (and, given its deliberate naivity, will probably remain experimental forever) but that's okay for now. We'll see if/how people use it before fixing the couple issues there are, and documenting it more.
Show
David Baelde added a comment - The UDP I/O is still experimental (and, given its deliberate naivity, will probably remain experimental forever) but that's okay for now. We'll see if/how people use it before fixing the couple issues there are, and documenting it more.

People

  • Assignee:
    David Baelde
    Reporter:
    Samuel Mimram
Vote (0)
Watch (0)

Dates

  • Created:
    Updated:
    Resolved: