LWN: Comments on "Experimental applications of GStreamer" https://lwn.net/Articles/662014/ This is a special feed containing comments posted to the individual LWN article titled "Experimental applications of GStreamer". en-us Thu, 16 Oct 2025 09:19:57 +0000 Thu, 16 Oct 2025 09:19:57 +0000 https://www.rssboard.org/rss-specification lwn@lwn.net Audio location https://lwn.net/Articles/664394/ https://lwn.net/Articles/664394/ smurf <div class="FormattedComment"> Latency may be variable, but once you start a recording it, well, records like it's supposed to. Thus, if the sound of all speakers are on a single recording and you evaluate the differences in timing between speakers instead of the sounds' absolute arrival times, there's no problem.<br> </div> Fri, 13 Nov 2015 19:53:21 +0000 Audio location https://lwn.net/Articles/664227/ https://lwn.net/Articles/664227/ nye <div class="FormattedComment"> I don't see how that help in any way with the problem that the latency is wildly variable?<br> </div> Thu, 12 Nov 2015 15:31:15 +0000 Audio location https://lwn.net/Articles/663675/ https://lwn.net/Articles/663675/ smurf <div class="FormattedComment"> You didn't understand my idea; let me rephrase.<br> <p> As I understand it, the senders don't have delay issues, they're all on the receiving end.<br> <p> Thus, instead of pinging one speaker at a time and measuring the absolute time the pulse takes to arrive at the listener, you ping all of them at the same time, record that sound, and use digital processing to figure out the delays between pings. (Thus different frequencies, otherwise you can't tell the pings apart.) This way, delays on the receiver side won't matter, it's all a single sound recorded once by a single microphone.<br> </div> Sun, 08 Nov 2015 15:16:01 +0000 Audio location https://lwn.net/Articles/663177/ https://lwn.net/Articles/663177/ oldtomas <div class="FormattedComment"> <font class="QuotedText">&gt; Why would the absolute timing of audio at the receiver matter?</font><br> <p> It wouldn't if it were constant. But (from the article):<br> <p> "the Android-introduced delays varied between 30 to 100ms"<br> <p> I read that as having an uncertainty of roughly 70ms. Of course, if you could develop a solid statistical model of this uncertainty you could try to pick up the signal from the noise, but that sounds like a tall order compared to just cancelling out a (per-device) constant...<br> </div> Thu, 05 Nov 2015 11:24:28 +0000 Experimental applications of GStreamer - tiled streaming https://lwn.net/Articles/662656/ https://lwn.net/Articles/662656/ sciurus Yes, AWS offers <a href="https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using_cluster_computing.html">GPU instances</a> with GRID K520 and Tesla M2050 cards from NVIDIA. Sat, 31 Oct 2015 19:29:36 +0000 Audio location https://lwn.net/Articles/662455/ https://lwn.net/Articles/662455/ smurf <div class="FormattedComment"> Why would the absolute timing of audio at the receiver matter?<br> Send a ping to each speaker, at the exact same time but at different frequencies, then measure relative timing at the receiving end.<br> With known (fixed) speaker locations, calculating the receiver's position is a non-problem these days.<br> </div> Thu, 29 Oct 2015 18:50:52 +0000 Experimental applications of GStreamer - tiled streaming https://lwn.net/Articles/662446/ https://lwn.net/Articles/662446/ jnareb <blockquote>| <i>It would be better to use GPUs for the stitching and tiling, he said, but so far no cloud provider offers such a service.</i></blockquote> Actually they are cloud providers that offer GPGPU computing access. For example QwikLab, which offers paid CUDA and OpenACC courses (first lab in series is free) runs on Amazon cloud. Thu, 29 Oct 2015 17:04:28 +0000 Experimental applications of GStreamer https://lwn.net/Articles/662366/ https://lwn.net/Articles/662366/ paulj Any old arena in Amsterdam, or <a href="https://en.wikipedia.org/wiki/Amsterdam_Arena">Amsterdam Arena</a>? Thu, 29 Oct 2015 09:52:46 +0000