Concatenating 'audio/x-wav' buffer and ser

问题:

This question is a followup to a previous question, that was resolved thanks to @thejh.

I'm trying to convert text to audio and serve the data to the client as 'chunked' data. So far my headers look like so:

res.writeHead(200, {
  'Content-Type': 'audio/wav',
   // I tried 'audio/x-wav' as well
  'Transfer-Encoding': 'chunked'
});

And then I'm converting snippets of text to audio in a queue (which I get back as base64 encoded data), and serving them like so:

var src = Base64Audio.replace("data:audio/x-wav;base64,","");
var binAudio = new Buffer( src, 'base64');
res.write(binAudio);

All the information is being transferred and sent to the client, but for some reason the browser (I'm testing it in Firefox 7.0.1) is playing it and stopping after the first chunk. Here's the result/demo showing the premature end of the audio, and this is the code being run on github.

Why is this? Is this because the x-wav data has meta data like an End or specified length in is header/meta-data? If so what is this meta data and is there some way of editing it so that the browser successfully concatenates the received chunks?

I'm aware of the Header 'Content-Length': Buffer.length but in this instance I don't know how long the entire stream is going to be.

Can anyone offer suggestions. Is it possible to Edit the buffers before they're sent such that the browser concatenates them properly?

回答1:

I think your best bet is to make this resemble an audio stream, as would be sent by icecast/shoutcast. I don't think FireFox will handle that by default (older versions do not), which is why there are so many lovely flash plugins to play streams.

You need to set a few more headers to resemble a stream:

HTTP/1.0 200 OK
Content-Type: audio/wav
Transfer-Encoding: chunked
icy-br: ##
ice-audio-info:bitrate=##;samplerate=#####
icy-description:Some Name
icy-genre:Alternative
icy-name:Name
icy-pub:0
icy-url:http://yoursite.com
Server:Whatever you want
Cache-Control: no-cache
Connection: Keep-Alive

回答2:

I don't know the answer to this, but have a look at how Shoutcast streams are coming across the wire. They are an infinitely long mp3 file, and similar concepts should apply if you take a look at how it's done.