Re: Audio Stream Buffer

sysread and syswrite (rather than print) let you avoid bufferring by stdio. I suggest you should be using it on both sides as you don't want stdio to be involved buffering. It would seem logical to read/write the same number of bytes rather than sending 128 and waiting on 512. You could do:

while( sysread(CLIENT,$stream,512) ){
    syswrite( AUDIO_OUT, $stream )
}
[download]

These simple steps may or may not resolve you issues.

Buffering only helps if you 1) get ahead of the game and 2) stay ahead of the game (unless you got far enough ahead to start) of course. Depending on the behaviour of aplay you could possibly just buffer X bytes to start, send that to aplay to fill its buffer, and then loop as above. This would only work if aplay accepts the entire initial stream without blocking so that the following loop is effectively just running in top up mode. Failing that you may need a dedicated local reader that can buffer and supply a consistent stream to your writer as suggested by Zaxo

cheers

tachyon

Comment on Re: Audio Stream Buffer Download Code

Replies are listed 'Best First'.
Re^2: Audio Stream Buffer by reds (Novice) on Jul 01, 2004 at 03:13 UTC
I'll change the read/write bytes to be the same. At one point, they were the same, but I changed it in the hopes that reading more initially would fill up aplay's buffer and provide me with the padding I needed to cover for the bursty 802.11b stream. I believe I will need the full-blown local reader that Zaxo suggested because aplay's maximum buffer size is very small. I think I need something several seconds long. As far as the capacity goes, the the audio format is a stereo signed 32 bit, big endian stream at 22050 Hz. I believe that this translates into 1.3Mb of data per second, which should be well within the capacity of an unladen, full strength, 802.11b connection.	[reply]

Replies are listed 'Best First'.

Re^2: Audio Stream Buffer
by reds (Novice) on Jul 01, 2004 at 03:13 UTC

I'll change the read/write bytes to be the same. At one point, they were the same, but I changed it in the hopes that reading more initially would fill up aplay's buffer and provide me with the padding I needed to cover for the bursty 802.11b stream.

I believe I will need the full-blown local reader that Zaxo suggested because aplay's maximum buffer size is very small. I think I need something several seconds long.

As far as the capacity goes, the the audio format is a stereo signed 32 bit, big endian stream at 22050 Hz. I believe that this translates into 1.3Mb of data per second, which should be well within the capacity of an unladen, full strength, 802.11b connection.

[reply]