7 ms·
> You don't need to install any third-party software Oh, so this is like a web browser thing? > Click here to download FarPlay Oh, so I _do_ need to install
by ReactiveJelly 5y ago
> You don't need to install any third-party software
Oh, so this is like a web browser thing?
> Click here to download FarPlay
Oh, so I _do_ need to install FarPlay. Just not any software that's a third party besides FarPlay. Which wouldn't make any sense.
- tyingq 5y ago>Just not any software that's a third party besides FarPlay. Which wouldn't make any sense. Heh. "Note for Windows: To use FarPlay on Windows, you must have an ASIO audio driver. We recommend the free ASIO4ALL."
- akiselev 5y agoComing soon to a Windows automatic update near you, next time you're running a business critical overnight batch job.
- deleted 5y ago[deleted]
- smoldesu 5y agoHope you're not planning to play with a backing track, ASIO4ALL notoriously does not play nice with multiple audio sources. It's almost like someone wanted to backport the horrors of ALSA to Windows because they missed how annoying it was having a single pair of inputs and outputs.
- whyoh 5y ago>ASIO4ALL notoriously does not play nice with multiple audio sources. Yep, that's because Asio4all uses WDM-KS and WDM-KS since Vista doesn't support multiple sources. Actual ASIO drivers made by sound card manufacturers usually don't have this limitation, as long as you keep the same sample rate everywhere. But it can also vary depending on who made the driver and/or on whether the source apps are using ASIO or a mix of ASIO and WDM/WASAPI. Getting low latency audio to work nicely on Windows can be messy (compared to macOS, at least).
- mkishi 5y agoRecommending ASIO first seems more like a holdover from a troubled past to me. These days, I can get ~1ms latency with shared-mode WASAPI on a 2012 then-budget i5 desktop, with on-board audio...
- jcelerier 5y agoWild. Even on beastly computers I'm never able to go below something like 256 samples at 48k with WASAPI
- fho 5y agoYou might want to check out audio processing on Linux with a (soft) real-time kernel. The choice of plugins is limited, but it is reasonable to run a 5 man band (including three guitar amp modelers and voice processing) at 2.8 ms (internal) round-trip latency (plus some ms for AD/DA) on a "some what beefy but still just a laptop"-laptop.
- jcelerier 5y agoMy main platform is Linux :) on it I run a RME Multiface II ; with it I can go down to 32 samples of latency and still do some useful stuff without even using a RT kernel (can only go down to 64 in Windows w/ ASIO). Recently I had a cool art project where we ran 48-channel ambisonic sound spatialization + live video effects, all that from a single Dell laptop sending audio through AES67 (so Ethernet) and video on 3 1080p outputs. Linux is incredible with the right hardware ! (shameless self-promotion: this was with https://ossia.io https://ossia.io score :-))
- fho 5y ago> 48-channel ambisonic sound spatialization Now I am jealous! I toyed around during my time at university, but never really got further than my crappy 4.0 setup at home :-)
- namibj 5y agoActually, the RT_PREEMPT stuff gives you worst-case blips around the 100-300 microsecond mark, and if it's just audio with remotely tolerant handling of buffer under/overrun, you can ignore those and use the more normal latency ceiling around 20-50 microseconds. Note: 192 kHz is 5.2 microseconds/sample, 48 kHz is 20.8 microseconds/sample. The 15 cm distance between the ears takes around 100 microseconds to traverse (at the higher speed-of-sound in the head, vs. free-air). The 1m distance of air for close-by human 1:1 talking takes a full 3 milliseconds to traverse. There is a non-profit [0] with hard-realtime applications (including CNC) that runs a few racks of systems with latency monitoring. For example, the blue rack3slot0 line [1] is a histogram for an almost-standard distribution kernel on an IvyBridge Xeon-E3 running a thread with timer interrupts every 200 microseconds for about 5.5 hours (100 M times, specifically), and recording the latency of that interrupt. As one can see, there were about 20 at-or-above 20 microsecond delay, and even then just barely over. With remotely decent under/overrun hiding, 10 microsecond latency should be easily usable. And yes, those systems had background load at normal priority and this realtime thread at high priority: > Between 7 a.m. and 1 p.m. and between 7 p.m. and 1 a.m., a simulated application scenario is running using cyclictest at priority 99 with a cycle interval of 200 µs and a user program at normal priority that creates burst loads of memory, filesystem and network accesses. The particular cyclictest command is specified in every system's profile referenced above and on the next page. The load generator results in an average CPU load of 0.2 and a network bandwidth of about 8 Mb/s per system. [0]: https://www.osadl.org/Realtime-Linux.projects-realtime-linux.0.html https://www.osadl.org/Realtime-Linux.projects-realtime-linux... [1]: https://www.osadl.org/Optimization-latency-plot-of-selected-RT.qa-latencyplot-optrt.0.html https://www.osadl.org/Optimization-latency-plot-of-selected-...
- authed 5y agono 4th party