search for: f567

...ice to update metadata often too. Ices seems best. I've already grepped the sources and glanced how ogg.h is used. Probably wouldn't take much to incorporate speex as speex.h is probably extremely similar. -- Roger http://www.eskimo.com/~roger/index.html Key fingerprint = 8977 A252 2623 F567 70CD 1261 640F C963 1005 1D61 Mon Jul 16 18:33:52 PDT 2007

...@eskimo.com> wrote: > > I've already grepped the sources and glanced how ogg.h > > is used. Probably wouldn't take much to incorporate speex as speex.h > > is probably extremely similar. -- Roger http://www.eskimo.com/~roger/index.html Key fingerprint = 8977 A252 2623 F567 70CD 1261 640F C963 1005 1D61 Fri Jul 20 14:18:21 PDT 2007

...orge.net/projects/dsctl/ https://sourceforge.net/project/screenshots.php?group_id=198579 (bottom line -- reception status -- is an example of what I'll be incorporating into the comment fields of the ogg stream.) -- Roger http://www.eskimo.com/~roger/index.html Key fingerprint = 8977 A252 2623 F567 70CD 1261 640F C963 1005 1D61 Sun Jul 15 22:39:02 PDT 2007

...ex.org related to ogg/vorbis). I'm wondering if this might significantly reduce delay times. One question I ponder is if user's players have the speex codec compared to the more popular vorbis/ogg codec. -- Roger http://www.eskimo.com/~roger/index.html Key fingerprint = 8977 A252 2623 F567 70CD 1261 640F C963 1005 1D61 Mon Jul 16 13:31:19 PDT 2007

...tags will probably have a change interval of around 1 second. (right?) (*Dsctl is a program used to monitor this device's alpha tags because only analog audio is being piped into the line-in of the sound card.) -- Roger http://www.eskimo.com/~roger/index.html Key fingerprint = 8977 A252 2623 F567 70CD 1261 640F C963 1005 1D61 Mon Jul 16 11:35:13 PDT 2007

You should look at the source code for oddcast. it has a neat way of adding metadata to the ogg stream. It uses libogg (which is it using to encode the vorbis stream) and sort of creates a new beginning of stream packet with the new metadata, so that icecast knows to pick up the change. If you aren't using ices to encode the audio, only to send it, I would suggest posting the metadata to

Hi, "Burst on connect" isn't going to change the buffering. It'll just affect how quickly the client starts playing. The main buffer in question here is that on the client. Sending a burst of data when the client connects will simply serve to fill the buffer up more quickly, which results in the player beginning to play sooner. It won't reduce any latency, and if the