Dirk-Willem van Gulik
2002-Sep-08 16:23 UTC
[vorbis-dev] vorbis tool ogg123/oggenc running out of sync while streaming.
Or rather - the ogg123 seems to run faster than the oggenc. Based on the vorbis toots 1.0_1,3 I've got (on freebsd) a small streaming server which essentially takes the oss/vox audion input; uses the code from oggenc to make a stream and then a bit of apache 2.0 to dole that stream out over TCP to various clients: setup oss /dev/dspW0.0 16 bit stereo 44k1. create ogg/vorbis header setup tcp while(1) { read oss from /dev/dsp. cut and paste code from oggenc enced this with default settings if (accept) { add client do http GET/200 OK send ogg/vorbis header } for each client { if buffer empty fill buffer with most recent frame. if buffered send as much buffered as we can if error drop client } } One of the clients is a Sharp Zaurus running: http://ipaq.vmlinuz.org/ogg/ a native ogg123: ./ogg123 http://foo/oggie The apache server streams reliable and steadily at a 4 - 256kbit rate - and the TCP connection is clean and steady. And it certainly seems that the machine is encoding at a steady pace and fast enough. Now the problem I have is that regardless of how large I make the Zaurus its input buffer; the decoder always seems to run a little fast - and will generally deplete the input buffer after a minute or so. I.e. it nicely buffers 200-300k; and the after a minute or so is down to 0 on the input buffer - and will linger around that point. Is there any way to prevent this ? Is it normal to expect some PID like feedback loop to adjust the time/keep the buffer roughly ? Or are there clever time stamps in the protocol to ensure this - and should I look for a bug in ogg123 ? Thanks ? Dw --- >8 ---- List archives: http://www.xiph.org/archives/ Ogg project homepage: http://www.xiph.org/ogg/ To unsubscribe from this list, send a message to 'vorbis-dev-request@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.
Stan Seibert
2002-Sep-08 18:32 UTC
[vorbis-dev] vorbis tool ogg123/oggenc running out of sync while streaming.
On Sun, 2002-09-08 at 18:23, Dirk-Willem van Gulik wrote:> Now the problem I have is that regardless of how large I make the Zaurus > its input buffer; the decoder always seems to run a little fast - and will > generally deplete the input buffer after a minute or so. I.e. it nicely > buffers 200-300k; and the after a minute or so is down to 0 on the input > buffer - and will linger around that point. > > Is there any way to prevent this ? Is it normal to expect some PID like > feedback loop to adjust the time/keep the buffer roughly ? Or are there > clever time stamps in the protocol to ensure this - and should I look for > a bug in ogg123 ?I'm not sure if I understand the problem. As long as oggenc is encoding at faster than realtime, then you shouldn't have any streaming issues. Since ogg123 is multithreaded, the player works like this (simplified): [Input buffer] --> (Decoder thread) --> [Output buffer] --> (Playback thread)-->[Audio device] (Input buffer contains compressed Vorbis data, Output buffer contains decoded PCM audio) The decoder thread in this setup will run as fast as it can until one of two conditions occurs: 1) The input buffer is empty 2) The output buffer is full Then it will wait until the condition goes away. #2 is the usual blocking condition when playing from disk, and #1 is the usual condition when streaming. So having an empty input buffer is actually to be expected (unless you have a really small output buffer). Are you losing audio? If not, I wouldn't worry. --- Stan Seibert <p><p>--- >8 ---- List archives: http://www.xiph.org/archives/ Ogg project homepage: http://www.xiph.org/ogg/ To unsubscribe from this list, send a message to 'vorbis-dev-request@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.