[HN Gopher] JackTrip WebRTC: high quality, uncompressed, ultra-l...
___________________________________________________________________
JackTrip WebRTC: high quality, uncompressed, ultra-low delay audio
streaming
Author : jarmitage
Score : 104 points
Date : 2021-01-28 15:05 UTC (7 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| jarmitage wrote:
| For anyone who is fatigued by web and telecomms audio quality, I
| highly recommend trying out JackTrip:
| https://ccrma.stanford.edu/groups/soundwire/software/jacktri...
|
| If you've ever been in a recording studio with headphone
| monitoring / studio talkback, it's like that. Really intimate.
|
| This project uses RTCDataChannel for audio, which is very neat,
| but it's a shame that once again audio on the web has to be
| hacked to perform well.
| rezonant wrote:
| Agreed, data channels for uncompressed audio is certainly the
| most interesting idea of this project for me, but it appears
| they are having trouble with the audio worklet processing time,
| so it's not an immediate slam dunk :-/
| TomMasz wrote:
| As a musician, I am thrilled that JackTrip and Jamulus are
| available to make real-time collaboration possible but they're
| not simple to install and configure for everyone. I spent
| numerous sessions trying to get a non-techie friend's Ubuntu
| laptop setup with Jamulus but we both got so frustrated we gave
| up. I hope the next generation brings with it easier setup,
| there's just so much potential.
| declnz wrote:
| +1
|
| I get the problem with JackTrip (though JamTrip[1] looks a good
| start).
|
| Out of interest, what were the problems with Jamulus? I've
| found it easier than expected (once I'd got Jack set up and
| happy / understood). On Windows / MacOS it's actually easier as
| there are are clear, well-trodden install guides (and no Jack /
| low-latency kernels to explain).
|
| [1] https://github.com/vicwomg/jamtrip
| spacechild1 wrote:
| Last time I've checked, Jamulus is not peer-to-peer but
| rather server-client and therefore has more latency.
| morsch wrote:
| I'd love for this to make a difference for simple video calls
| with relatives -- in my imagination, I set it up, and we find out
| we've been in the audio equivalent of the uncanny valley this
| whole time. But I'm afraid in reality, the default audio codecs
| used in WebRTC are probably good enough to make poor microphones
| and pure connection latency the bigger issue. Am I wrong?
|
| Obviously, even if I'm right, this has a target audience --
| musicians, interviewers and other people who talk for a living --
| for which it might be fantastic.
| ximm wrote:
| I am wondering whether using AudioWorklets actually has any
| benefits in this case.
|
| AFAIU the benefit in general is that they run in the audio thread
| so the data does not need to be handed over to a different thread
| for processing. In this case however, the data is handed over to
| the main thread anyway to be send over the data channel.
|
| Has anyone measured the impact of using AudioWorklets this way?
| jefftk wrote:
| This says ultra low delay, but how low? It seems to me like it's
| still going to be limited by the browser, and then you're going
| to have network latency on top of that?
|
| Testing in Chrome the lowest latency I can get is 23ms while in
| Firefox it's 14ms: https://www.jefftk.com/test/latency-demo-5
| gregsadetsky wrote:
| 30ms here in Chrome and 23ms in Firefox here. But yeah, same
| questions -- is this over the network (or no, that's the point
| of a p2p connection)? What is this measuring..?
| jefftk wrote:
| My tool is local: it measures the time from when JS says
| "send this to the speaker" until JS receives that audio back
| from the mic. It's the client-side round-trip latency.
|
| (As far as I know, there is no way to get the browser to tell
| you this latency, and you have to measure it.)
| lxe wrote:
| What's the bitrate for these streams?
|
| If you're on mobile, or corporate net, you might not be able to
| get "punched through" by the other party for actual p2p
| connection and will need a TURN server.
|
| I'm guessing that an uncompressed data channel with audio in it
| might send a lot of traffic through it.
| rexreed wrote:
| Is it possible to connect this to an RTMPS stream as well or does
| that defeat the purpose? Can only people Joined in the room get
| the stream?
| PaulDavisThe1st wrote:
| if you're in this space, consider trying out sonobus also. not
| the author (though he is a friend of mine), haven't tried it yet
| myself, but seems to have all the right stuff.
| spacechild1 wrote:
| Yes, SonoBus looks really promising! I was surprised and also a
| bit proud to learn that it uses a fork of my AOO library
| (https://git.iem.at/cm/aoo/). I have been in touch with Jesse
| for the last couple of days and I'm (passively) following the
| development.
|
| AOO is a C/C++ library for flexible on-the-fly multi-channel
| audio streaming and OSC messaging over local networks and the
| internet. The repo also includes Pure Data externals and
| Supercollider extensions.
|
| WARNING: AOO is still alpha and there are breaking changes
| between the pre-releases, but I hope to publish a final release
| soon!
| zaroth wrote:
| Truly is it uncompressed PCM WAV audio? In that case 44kHz 16-bit
| 1-channel is 705 kbps.
|
| Are there not any good nonproprietary lossless low latency audio
| codecs? A brief look at Wikipedia shows a couple that are 5ms or
| lower, but either they are proprietary or they are low bitrate.
| tleb_ wrote:
| Opus has frame sizes down to 2.5ms. See
| https://en.m.wikipedia.org/wiki/Opus_(audio_format)#cite_not...
| declnz wrote:
| Jamulus uses Opus for this reason (balance with quality) AIUI
| spacechild1 wrote:
| As do SoundJack, SonoBus and probably many other similar
| apps.
| staticfloat wrote:
| You pay a price for the super-small frame sizes; much worse
| compression ratios. Frame sizes smaller than 10ms disable the
| LPC and hybrid coding modes, which are quite advantageous.
| [0]
|
| In my experiments with transmitting realtime audio signals
| using Opus, 10ms frame sizes are acceptable for 1-way
| synchronicity (e.g. if you want the user to perform an action
| and hear the result as simultaneous with the action) but it's
| definitely the upper bound. From what I remember my signal
| processing professor say, the threshold to try and hit is 7ms
| total latency for truly undetectable processing, but I can't
| find a reference for that, so take it with a grain of salt.
|
| [0] https://www.opus-
| codec.org/docs/html_api/group__opusencoder....
| jarmitage wrote:
| See for example:
|
| Robert H. Jack, Tony Stockman, and Andrew McPherson. 2016.
| Effect of latency on performer interaction and subjective
| quality assessment of a digital musical instrument. In
| Proceedings of the Audio Mostly 2016 (AM '16). Association
| for Computing Machinery, New York, NY, USA, 116-123. DOI:
| https://doi.org/10.1145/2986416.2986428
|
| https://scholar.google.com/scholar?cluster=1347262219555289
| 9...
___________________________________________________________________
(page generated 2021-01-28 23:02 UTC)