0

I'm trying stream live audio to a wide range of clients in a web browser.

My current solution :

Dotnet core 3.1 console application

  1. receive the audio data over UDP
  2. trimming the first 28 bytes of each received packet
  3. and send the processed packet over UDP.

Node JS

  1. execute a Ffmepg as a child process to receive audio data packets over UDP from the console app, and encode each packet to audio WAV format
  2. Pipe out the result of the child process into a GET HTTP endpoint response

Browser

  1. HTML audio element with source value equals to the node js GET endpoint

Problem:

The solution is giving a good result, but only for one device(one to one), which is not what I want to achieve.

I've tried many solutions to make it applicable to a wide range of devices, such as using working threads and forking a child process, but none of them changes the result.

I believe that I've to make some changes to the node js implementation, so here I'll share it with you, hoping to get a clue to solve the problem. 

var express = require("express");
var app = express();
var children = require("child_process");

var port = 5001;
var host = "192.168.1.230";

app.listen(port, host, () => {
  console.log("Server running at http://" + host + ":" + port + "/");
});

app.get('/stream', (req, res) => {
  const ffmpegCommand = "ffmpeg";
  var ffmpegOptions =
    "-f s16le -ar 48000 -ac 2 -i udp://192.168.1.230:65535 -f wav -";

  var ffm = children.spawn(ffmpegCommand, ffmpegOptions.split(" "));

  res.writeHead(200, { "Content-Type": "audio/wav; codecs=PCM" });
  ffm.stdout.pipe(res);
});

If someone interested to see the full implementation, please let me know.

Yousef Alaqra
  • 79
  • 4
  • 12
  • Not exactly true. The on("data") event is asynchronous and thus fired when IO is available, meanwhile the main thread is able to handle other requests. All your operations are non-blocking, so it should just work. You can add more `console.log` to see exactly when things happen. By the time the first on("data") event is fired, it is already done executing the request handler – mati.o Jun 06 '20 at 15:43
  • @mati.o A good point to mention, but when I've hosted the project on IIS, only the first client was able to hear the audio. The others get 'pending' status in the network tap. – Yousef Alaqra Jun 06 '20 at 17:17
  • Honestly I haven't used IIS on my own, but it sounds like it could be that it is configured to throttle requests in some way. I had some similar issues with nginx when we have applied some limits in our configuration. My suggestion therefore is to simply run node.js without IIS (i.e make the port available to all clients) and see if the problem persists. I have a reason to believe it'll work and then we can look into what's wrong with the iis config – mati.o Jun 06 '20 at 17:32
  • @mati.o I've got the same result, only the first client can get a response. Also, to make another client to connect, I had to restart the server. – Yousef Alaqra Jun 06 '20 at 17:58
  • Well I just had this idea in mind that it could be the client. Have you tried with a different machine or other browser? Check this out: https://stackoverflow.com/a/20315352. I think if you add some query params that are different between each request it might work – mati.o Jun 06 '20 at 18:09
  • @mati.o I've tried different browsers, didn't work as well. Also, I've tried to use worker threads to handle each request, the same result. – Yousef Alaqra Jun 09 '20 at 13:11

0 Answers0