Re: [Flac-dev] Synchronizing a streaming client to the server Was: Idea to possibly improve flac?
The hearing tests which established the 20 kHz limit were based on sustained, pure tones. The 20 kHz limit is the average - some have a lower limit, some have a higher limit. But that value is basically right for sustained tones. The key is that our perception of audio is not completely described by our response to sustained tones. Our brain also analyzes transients, even in the first one quarter cycle of a waveform. Test have been done using manipulated digital data to show that humans can hear a difference if the transients are changed. In other words, different percussive sounds are perceived differently, even if the only thing changed about the waveform is the first fraction of a cycle. This is almost completely unrelated to sustained waveforms where every cycle is identical. There's even some research showing that the polarity of the initial half cycle is important to perception. The bottom line is that you end up having to preserve high frequencies that you might not be able to hear when they are sustained, just so you can preserve the full attack of percussive sounds. It might seem like a waste of bandwidth if you focus on the pure tones, since we can't really hear those, but the transient response is the real key to recording realistic sounds. The impulse response of a system describes how clearly it reproduces original sounds from nature. Sorry for my quick attempt to summarize this. A more thorough investigation of the research into human hearing and perception can be found in http://www.earthworksaudio.com/wp-content/uploads/ th_world_beyond_20khz.pdf Brian Willoughby Sound Consulting On Jan 7, 2011, at 19:33, David Richards wrote: > Also BTW if anyone has a link on some information about why 96khz > is better than 48/44.1 id like to see it, because I don't > comprehend why it would be. 24bit is a clear win to my ears... (but > don't bring it up on this list because I'd rather not digress into > madness) ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] Synchronizing a streaming client to the server Was: Idea to possibly improve flac?
On Jan 7, 2011, at 20:44, Ben Allison wrote: > The main problem is in the Ogg layer, in my opinion. I think you are right. What is the reason that the Ogg layer was chosen for streaming broadcast? My admittedly naive assumption was that Ogg is a file format, not a streaming format. > Imagine this extreme use-case with __completely made up__ numbers. > This > is a scenario where the server is encoding to FLAC on-the-fly from > a raw > PCM input, either from disk or a live stream. > > Let's say the FLAC block size is 1024 samples, or 23ms at 44100 Hz. > Let's say each silent block compresses to 1 byte. Let's also say > that the > Ogg packeting layer wants 4096 bytes before creating a page. Again - > these numbers are completely made up, but illustrate the point. In > this > example, it would take 95 seconds of digital silence before Ogg > decided to > send another page out over the network. I realize that these are made-up numbers, and I wouldn't expect a great deal of precision, but it would seem worthwhile to at least look at realistic estimates. The minimum FRAME blocking in FLAC would be 12 bytes for stereo, not just 1 byte. That's with 40-bit minimum FRAME_HEADER, 8-bit SUBFRAME_HEADER, 2 silent CONSTANT 16-bit audio samples, and 16-bit FRAME_FOOTER. This means the 4096-byte Ogg packeting layer would only represent 7.9 seconds of latency. I think it's perfectly reasonable for a client tuning in to a lossless broadcast to wait just under 8 seconds for pre-buffering of the stream. Better yet, ditch the Ogg packeting layer entirely, and use raw FLAC streaming. That should mean that any size packet is possible. TCP/ IP should allow shorter packets than the maximum, although it may be more efficient for broadcast traffic to have packets closer to the normal size for file transfers, which would be more like 3.4 seconds. I admit that I don't know for sure what restrictions there are on internet broadcast packets, but it can't be much worse. 3.4 seconds is a long time to go without a packet, but buffering of 6.7 seconds or more should easily take care of that. > If the input audio on the server is coming from a live-source (such as > simulcast of an FM station) or if the disk I/O is very slow, this > can be > extremely problematic. > > Ben Allison > Principal Software Engineer > Nullsoft, Inc. I don't see why live-source audio would be a problem. The system would simply buffer the required amount of uncompressed audio data before calling the FLAC encoder. The only cost would be latency, and all digital broadcast systems that involve codecs involve a serious amount of latency. I can hear a distinct delay between my HDTV set tuner and computer USB tuner, since each has a different amount of buffering in its pipeline, exacerbated by the digital audio system. Brian Willoughby Sound Consulting ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] Synchronizing a streaming client to the server Was: Idea to possibly improve flac?
Give it a go, I await your results :D On Sat, Jan 8, 2011 at 12:20 AM, Brian Willoughby wrote: > Well, in that light, I suppose it isn't reasonable to expect people to wait > 23 seconds for their internet streaming broadcast to start playing. > > Then again, maybe it could be sold as the "price" for lossless streaming! > ;-) > > Seriously, though, what about if the Ogg page is not part of the picture? > i.e., what about just using pure FLAC and IP? > > Brian Willoughby > Sound Consulting > > > On Jan 7, 2011, at 20:49, David Richards wrote: >> >> The actual non made up number for 44100 is 23 seconds. :D >> >> 4096 samples, 254 packets in an ogg page. > > > ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] Synchronizing a streaming client to the server Was: Idea to possibly improve flac?
Well, in that light, I suppose it isn't reasonable to expect people to wait 23 seconds for their internet streaming broadcast to start playing. Then again, maybe it could be sold as the "price" for lossless streaming! ;-) Seriously, though, what about if the Ogg page is not part of the picture? i.e., what about just using pure FLAC and IP? Brian Willoughby Sound Consulting On Jan 7, 2011, at 20:49, David Richards wrote: > The actual non made up number for 44100 is 23 seconds. :D > > 4096 samples, 254 packets in an ogg page. ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] Synchronizing a streaming client to the server Was: Idea to possibly improve flac?
The actual non made up number for 44100 is 23 seconds. :D 4096 samples, 254 packets in an ogg page. -David On Fri, Jan 7, 2011 at 11:44 PM, Ben Allison wrote: > The main problem is in the Ogg layer, in my opinion. > > Imagine this extreme use-case with __completely made up__ numbers. This > is a scenario where the server is encoding to FLAC on-the-fly from a raw > PCM input, either from disk or a live stream. > > Let's say the FLAC block size is 1024 samples, or 23ms at 44100 Hz. > Let's say each silent block compresses to 1 byte. Let's also say that the > Ogg packeting layer wants 4096 bytes before creating a page. Again - > these numbers are completely made up, but illustrate the point. In this > example, it would take 95 seconds of digital silence before Ogg decided to > send another page out over the network. > > If the input audio on the server is coming from a live-source (such as > simulcast of an FM station) or if the disk I/O is very slow, this can be > extremely problematic. > > Ben Allison > Principal Software Engineer > Nullsoft, Inc. > >> I just thought of something: Given the maximum supported network >> packet size, and the minimum number of channels (probably stereo) for >> a FLAC broadcast stream, it should be possible to calculate the >> absolute longest time that a single network packet could span. Once >> you know that time, you could simply double it, and then make sure >> the streaming client always buffers up at least that much time before >> playback is started. Voila - instant protection against starvation >> due to silent frames being compressed to ultra-tiny packets with a >> long delay. >> >> Some of the comments here have talked about low latency, but I would >> say that low latency has no place in an internet streaming >> broadcast. I mean, the listened have no frame of reference for >> latency anyway, so what does it matter if the latency is really high? >> >> Now that I think about it this way, I'd say that FLAC and OggFLAC >> should not have any real problems due to compression of silent >> frames. Any place there is a problem should be blamed on bad >> streaming client / player code, not on the format itself. >> >> Brian Willoughby >> Sound Consulting >> >> ___ >> Flac-dev mailing list >> Flac-dev@xiph.org >> http://lists.xiph.org/mailman/listinfo/flac-dev >> > > ___ > Flac-dev mailing list > Flac-dev@xiph.org > http://lists.xiph.org/mailman/listinfo/flac-dev > ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] Synchronizing a streaming client to the server Was: Idea to possibly improve flac?
The main problem is in the Ogg layer, in my opinion. Imagine this extreme use-case with __completely made up__ numbers. This is a scenario where the server is encoding to FLAC on-the-fly from a raw PCM input, either from disk or a live stream. Let's say the FLAC block size is 1024 samples, or 23ms at 44100 Hz. Let's say each silent block compresses to 1 byte. Let's also say that the Ogg packeting layer wants 4096 bytes before creating a page. Again - these numbers are completely made up, but illustrate the point. In this example, it would take 95 seconds of digital silence before Ogg decided to send another page out over the network. If the input audio on the server is coming from a live-source (such as simulcast of an FM station) or if the disk I/O is very slow, this can be extremely problematic. Ben Allison Principal Software Engineer Nullsoft, Inc. > I just thought of something: Given the maximum supported network > packet size, and the minimum number of channels (probably stereo) for > a FLAC broadcast stream, it should be possible to calculate the > absolute longest time that a single network packet could span. Once > you know that time, you could simply double it, and then make sure > the streaming client always buffers up at least that much time before > playback is started. Voila - instant protection against starvation > due to silent frames being compressed to ultra-tiny packets with a > long delay. > > Some of the comments here have talked about low latency, but I would > say that low latency has no place in an internet streaming > broadcast. I mean, the listened have no frame of reference for > latency anyway, so what does it matter if the latency is really high? > > Now that I think about it this way, I'd say that FLAC and OggFLAC > should not have any real problems due to compression of silent > frames. Any place there is a problem should be blamed on bad > streaming client / player code, not on the format itself. > > Brian Willoughby > Sound Consulting > > ___ > Flac-dev mailing list > Flac-dev@xiph.org > http://lists.xiph.org/mailman/listinfo/flac-dev > ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] Synchronizing a streaming client to the server Was: Idea to possibly improve flac?
On Fri, Jan 7, 2011 at 11:25 PM, Brian Willoughby wrote: > I just thought of something: Given the maximum supported network > packet size, and the minimum number of channels (probably stereo) for > a FLAC broadcast stream, it should be possible to calculate the > absolute longest time that a single network packet could span. Once > you know that time, you could simply double it, and then make sure > the streaming client always buffers up at least that much time before > playback is started. Voila - instant protection against starvation > due to silent frames being compressed to ultra-tiny packets with a > long delay. > > Some of the comments here have talked about low latency, but I would > say that low latency has no place in an internet streaming > broadcast. I mean, the listened have no frame of reference for > latency anyway, so what does it matter if the latency is really high? You can say that but I can also stick my fingers in ears and whistle whilst you do. 2kb of ram is enough for anyone... > Now that I think about it this way, I'd say that FLAC and OggFLAC > should not have any real problems due to compression of silent > frames. Any place there is a problem should be blamed on bad > streaming client / player code, not on the format itself. Its not in the format or the client / player code. Its in libflac as I have pointed out. -David > > Brian Willoughby > Sound Consulting > > ___ > Flac-dev mailing list > Flac-dev@xiph.org > http://lists.xiph.org/mailman/listinfo/flac-dev > ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] Synchronizing a streaming client to the server Was: Idea to possibly improve flac?
I just thought of something: Given the maximum supported network packet size, and the minimum number of channels (probably stereo) for a FLAC broadcast stream, it should be possible to calculate the absolute longest time that a single network packet could span. Once you know that time, you could simply double it, and then make sure the streaming client always buffers up at least that much time before playback is started. Voila - instant protection against starvation due to silent frames being compressed to ultra-tiny packets with a long delay. Some of the comments here have talked about low latency, but I would say that low latency has no place in an internet streaming broadcast. I mean, the listened have no frame of reference for latency anyway, so what does it matter if the latency is really high? Now that I think about it this way, I'd say that FLAC and OggFLAC should not have any real problems due to compression of silent frames. Any place there is a problem should be blamed on bad streaming client / player code, not on the format itself. Brian Willoughby Sound Consulting ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] Synchronizing a streaming client to the server Was: Idea to possibly improve flac?
There is a hack fix that won't break the standard. Disable constant subframes and fixed subframes on the encoding end. 100% compatible. Your going to be using all that bandwidth most of the time anyways, and when it goes down temporarily, that could actually cause a problem at the network level depending on the fancyness of your QoS and other routing razzle dazzle. Here is the other hack so that you don't get a logjam in the Ogg layer. https://github.com/oneman/libflac/commit/67e13364032404ebc1837af143fdd1cd81786c3a -David On Fri, Jan 7, 2011 at 9:12 PM, Brian Willoughby wrote: > > On Jan 7, 2011, at 16:48, Ben Allison wrote: >> The issue is that silent frames compress to a very small size, and >> the Ogg >> packeting layer can put more than one FLAC frame into a page. So >> if you >> have an extended period of silence with a live or rate-limited input >> stream, the client buffers may exhaust themselves before a new page >> can be >> put together and transmitted. > > Ah, yes, I remember reading about this. It does seem like an > unfortunate problem, and I would guess that both FLAC and OggFLAC > have the same issue. At the very least, I don't see how OggFLAC > could compress more than FLAC when using FLAC, and thus the problem > should be the same in both. > > However, if you've been following my suggestions about flagging > silence and other gaps in the broadcast content, then I think there > might be a common solution to both problems. With flags for silence > defined in the protocol, the streaming broadcast server would be able > to alert the clients to the situation where an extended period of > silence is about to occur. Maybe there would even need to be some > advance notice, otherwise the flags would come too late, just like > the silent frames. Seems like the streaming broadcast server could > define some sort of maximum time gap, and if a future frame is going > to exceed this maximum time, then a prior frame could be encoded with > a flag announcing the imminent "problem" - upon which the client > could simply prepare to go silent and resync. > > It still seems difficult, because the trailing audio right before the > silent frames could end up getting trapped in a FLAC block that takes > too long to arrive because it is mostly silent, but not completely > silent. Perhaps a "short" block is needed so that all of the non- > silent audio can be sent right away, along with a warning flag, and > then the client will know to produce silence (and perhaps resync) > until the super-compressed silent frames finally arrive. > > Unfortunately, this all seems like a significant deviation from the > FLAC streaming standard, unless variable block sizes can be allowed. > I must admit that I have not studied this closely, but I do seem to > recall that the block can is allowed to vary under certain > conditions. It might be the case that certain decoders only work > with fixed block sizes, but a streaming broadcast client would > obviously be a special case where support for small blocks could be > mandatory without causing a huge problem. > > Apparently, slim has something along these lines in their stream, but > I wonder whether they've fully taken advantage of the possibilities. > > Brian Willoughby > Sound Consulting > > ___ > Flac-dev mailing list > Flac-dev@xiph.org > http://lists.xiph.org/mailman/listinfo/flac-dev > ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] Synchronizing a streaming client to the server Was: Idea to possibly improve flac?
On Fri, Jan 7, 2011 at 7:36 PM, Brian Willoughby wrote: > This thread has raised several good topics. It's surprising that the > FLAC-Dev list has been silent for years, and now suddenly there are several > good ideas to discuss. I'll take credit for this, toot toot toot :D > > On Jan 7, 2011, at 15:04, David Richards wrote: >> >> I am interested in streaming lossless audio, FLAC is probably the best >> option for that. Currently the OggFLAC way of doing it mostly works >> with a few hacks in libflac and my version of edcast. It might be that >> the Ogg packaging layer is ill suited for this purpose, and an >> alternative model developed. I've seen that its possible to stream >> native flac with netcat, but thats not really the solution I'm looking >> for. > > I have not done much work with streaming. I have written a lot of serious > code that uses the FLAC library. I remember that there used to be separate > objects in the FLAC library for streams, and they were unique from the file > objects because you can seek backwards in a file, but you cannot seek > backwards in a stream. For some reason, it seems that these objects have > been removed in the latest versions of the FLAC library. > > Can anyone explain the issues with streaming pure FLAC? What does OggFLAC > add to make streaming possible, or even easier than pure FLAC? I thought > that OggFLAC was just a way to put FLAC blocks into the Ogg file format. > Apple's CAF specification would also allow FLAC blocks to be placed inside > their file container, although this still would not force iTunes to play > FLAC unless a decoder were installed in the system. > > What is it about netcat that you don't like? Can you describe what you're > looking for, and why the specific details are important? I was always under > the impression that the FLAC format was already designed for streaming, but > I must admit that I've never studied the issue. > > Ok dokie, basically libflac provides functions for working with streams as well as files, but thats as far as it goes and there is a bit more needed for a entire solution. So libflac is ready to go, but you need more that libflac to stream, in the same way that you need more than libflac to hear a flac being played... What I mean by this for those reading is that libflac provides functions for encoding and decoding from an arbitrary buffer rather than a file. netcat isn't right for what I think are obvious reasons, namely one to many transmission, it just doesn't scale in the correct way something like icecast and a vorbis stream would. I actually have never bothered to try it, but I think you actually have to hack libflac even for that because many programs that play flac will wait until the end of the silent (constant) subframes before continuing to decode so any silence gets you out of sync... Compatibility with icecast would really be the ideal way to handle it I think. I'm not sure how it might get in the way if your goal was super low latency, but I think it still may work in that case. OggFLAC currently works with icecast, thats why I started messing with it. It somewhat hijacks the Ogg part of the vorbis code in icecast from what I've seen.. I've been able to use it with about 1 second of latency just fine on localhost and other machines on my network. It doesn't support metadata updates, ie. chained ogg decoding, but I don't think any clients do either. I think wrote the only client that doesn't crash when listening to OggFLAC for extended periods too, lol. Mplayer will crash randomly, and VLC will stop and rebuffer randomly.. So in summary Icecast is a http 1.0 streaming music server, and if its oggflac getting fixed, native flac with perhaps some kind of small wrapper or modification, I think that should be a target protocol, everyone uses icecast. And if for some reason icecast doesn't suit the lowest latency situations, perhaps a small protocol could be designed to wrap native flac and provide network streaming, with a lib, and some sample senders/receivers. A problem with native flac and streaming IIRC is that you only get one metadata frame and thats at the beginning or end of the stream. I really don't think metadata et all such as coverart and all of this really needs to be fretted over, really all that is needed is a string or two, maybe 255chars each, one can be the title or currently playing information and the second one arbitrary, and something to handle this time sync stuff we have been talking about. Of course any of this should handle all capabilities of the flac format, ie streaming 8 channel 24bit/96khz audio. I've been doing two channel 24bit 44.1khz, and the bitrate is a bout 200-250K (thats big K) per second, I haven't tried 4 or 5 channel yet, but I intend to ( I will be building support into edcast2 for this). Also BTW if anyone has a link on some information about why 96khz is better than 48/44.1 id like to see it, because I don't comprehend why it would be. 24bit
Re: [Flac-dev] Synchronizing a streaming client to the server Was: Idea to possibly improve flac?
On Jan 7, 2011, at 16:48, Ben Allison wrote: > The issue is that silent frames compress to a very small size, and > the Ogg > packeting layer can put more than one FLAC frame into a page. So > if you > have an extended period of silence with a live or rate-limited input > stream, the client buffers may exhaust themselves before a new page > can be > put together and transmitted. Ah, yes, I remember reading about this. It does seem like an unfortunate problem, and I would guess that both FLAC and OggFLAC have the same issue. At the very least, I don't see how OggFLAC could compress more than FLAC when using FLAC, and thus the problem should be the same in both. However, if you've been following my suggestions about flagging silence and other gaps in the broadcast content, then I think there might be a common solution to both problems. With flags for silence defined in the protocol, the streaming broadcast server would be able to alert the clients to the situation where an extended period of silence is about to occur. Maybe there would even need to be some advance notice, otherwise the flags would come too late, just like the silent frames. Seems like the streaming broadcast server could define some sort of maximum time gap, and if a future frame is going to exceed this maximum time, then a prior frame could be encoded with a flag announcing the imminent "problem" - upon which the client could simply prepare to go silent and resync. It still seems difficult, because the trailing audio right before the silent frames could end up getting trapped in a FLAC block that takes too long to arrive because it is mostly silent, but not completely silent. Perhaps a "short" block is needed so that all of the non- silent audio can be sent right away, along with a warning flag, and then the client will know to produce silence (and perhaps resync) until the super-compressed silent frames finally arrive. Unfortunately, this all seems like a significant deviation from the FLAC streaming standard, unless variable block sizes can be allowed. I must admit that I have not studied this closely, but I do seem to recall that the block can is allowed to vary under certain conditions. It might be the case that certain decoders only work with fixed block sizes, but a streaming broadcast client would obviously be a special case where support for small blocks could be mandatory without causing a huge problem. Apparently, slim has something along these lines in their stream, but I wonder whether they've fully taken advantage of the possibilities. Brian Willoughby Sound Consulting ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] Synchronizing a streaming client to the server Was: Idea to possibly improve flac?
On Fri, Jan 7, 2011 at 8:29 PM, Brian Willoughby wrote: > Awesome! Can ya help a brotha' out and send some links to the slim > protocol? I suppose Google could find it for me, but if you're familiar > with the project then I'd appreciate an insider's pointers. alas, i got my copy of the source from a 3rd party that had already hacked it quite a bit to support a fairly high end playback device. my guess is that logitech's download/support section of their website would have it. but if you decide to look at it, stay away from the perl and stick with the C. > A friend has some old slim hardware, and I've been trying to help him with > converting files for playback, so I do have a little bit of experience with > the history. i'm not convinced that its necessarily the same kind of reset, since slim is not a broadcast server - each client has its own independent stream. but ... there is a way to sync multiple players, and that must involve some similar magic. --p ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] Synchronizing a streaming client to the server Was: Idea to possibly improve flac?
On Jan 7, 2011, at 17:18, Paul Davis wrote: > On Fri, Jan 7, 2011 at 7:36 PM, Brian Willoughby > wrote: >> I'd like to borrow these ideas, or at >> least similarly-inspired ideas, and have FLAC streaming designed such >> that the stream can tell the playback software when to reset. > > the internals of the slim protocol does this. its all open source. i > was doing some work on this in 2009 to get it to handle multiple > sample rates, which it wasn't really designed for, but the "reset" > concept is all there. Awesome! Can ya help a brotha' out and send some links to the slim protocol? I suppose Google could find it for me, but if you're familiar with the project then I'd appreciate an insider's pointers. A friend has some old slim hardware, and I've been trying to help him with converting files for playback, so I do have a little bit of experience with the history. Brian Willoughby Sound Consulting ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] Synchronizing a streaming client to the server Was: Idea to possibly improve flac?
On Fri, Jan 7, 2011 at 7:36 PM, Brian Willoughby wrote: > I'd like to borrow these ideas, or at > least similarly-inspired ideas, and have FLAC streaming designed such > that the stream can tell the playback software when to reset. the internals of the slim protocol does this. its all open source. i was doing some work on this in 2009 to get it to handle multiple sample rates, which it wasn't really designed for, but the "reset" concept is all there. ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] Synchronizing a streaming client to the server Was: Idea to possibly improve flac?
The issue is that silent frames compress to a very small size, and the Ogg packeting layer can put more than one FLAC frame into a page. So if you have an extended period of silence with a live or rate-limited input stream, the client buffers may exhaust themselves before a new page can be put together and transmitted. > This thread has raised several good topics. It's surprising that the > FLAC-Dev list has been silent for years, and now suddenly there are > several good ideas to discuss. > > On Jan 7, 2011, at 15:04, David Richards wrote: >> I am interested in streaming lossless audio, FLAC is probably the best >> option for that. Currently the OggFLAC way of doing it mostly works >> with a few hacks in libflac and my version of edcast. It might be that >> the Ogg packaging layer is ill suited for this purpose, and an >> alternative model developed. I've seen that its possible to stream >> native flac with netcat, but thats not really the solution I'm looking >> for. > > I have not done much work with streaming. I have written a lot of > serious code that uses the FLAC library. I remember that there used > to be separate objects in the FLAC library for streams, and they were > unique from the file objects because you can seek backwards in a > file, but you cannot seek backwards in a stream. For some reason, it > seems that these objects have been removed in the latest versions of > the FLAC library. > > Can anyone explain the issues with streaming pure FLAC? What does > OggFLAC add to make streaming possible, or even easier than pure > FLAC? I thought that OggFLAC was just a way to put FLAC blocks into > the Ogg file format. Apple's CAF specification would also allow FLAC > blocks to be placed inside their file container, although this still > would not force iTunes to play FLAC unless a decoder were installed > in the system. > > What is it about netcat that you don't like? Can you describe what > you're looking for, and why the specific details are important? I > was always under the impression that the FLAC format was already > designed for streaming, but I must admit that I've never studied the > issue. > > >> On Fri, Jan 7, 2011 at 5:58 PM, Tor-Einar Jarnbjo > ei...@jarnbjo.name> wrote: >>> Am 07.01.2011 23:38, schrieb David Richards: I'm also interested in another concept of lossless streaming with flac. Lets call it broadcast flac. A problem with streaming for long periods of time is that the sending and receiving computers clocks go out of sync, for example even if I stream myself on localhost, with >>> >>> This is not a FLAC specific problem, but has to be handled in all >>> situations >>> where the streaming server is in control of the transmitting data >>> rate. It's >>> caused by a playback device, which actual sample rate is slightly >>> higher >>> than the sample rate actually requested or a streaming source, >>> which system >>> clock is running slowly. Since these parameters (at least an exact >>> playback >>> sample rate) is hard to achieve, this is a rather common problem. >>> Or to >>> shorten it: If the data has a sample rate of 44100 and your sound >>> card >>> consumes more than 44100 samples per "sender-time" second, your >>> buffer will >>> eventually exhaust. If it's the other way around, your buffer may >>> overflow >>> if the client does not handle these cases properly. >> >> I am well aware its not flac specific, but such a standard way of >> handling such a matter could be part of the packaging for streaming >> flac. > I think that this would be a good opportunity to design a solution > that is specific to broadcast. At the sending end, the server should > have knowledge of when there are breaks in the content. If the > stream could send flags at these breaks, then the receiving client > could go silent and reset the synchronization. As you describe, the > situation only becomes a problem after long periods of time, but I > would guess that there are enough station breaks (or at least song > breaks) in a long broadcast that there would be a chance for a reset. > > CoreAudio is a pull model, and the API provides a time line that can > be used to find the audio samples for a specific time. However, > there are many cases where this time line gets reset. Usually, each > callback has a time stamp that occurs precisely after the previous > callback. Obviously, the audio should not glitch when the time line > is contiguous, and thus the data must be sample-accurate. However, > CoreAudio code must also deal with situations where the time line > starts over from 0, usually under control of the host application. > CoreAudio also has a flag in the callback to indicate when the > buffers are totally silent. I'd like to borrow these ideas, or at > least similarly-inspired ideas, and have FLAC streaming designed such > that the stream can tell the playback software when to reset. > > The typical process to deal with synchronization of separate
Re: [Flac-dev] Synchronizing a streaming client to the server Was: Idea to possibly improve flac?
This thread has raised several good topics. It's surprising that the FLAC-Dev list has been silent for years, and now suddenly there are several good ideas to discuss. On Jan 7, 2011, at 15:04, David Richards wrote: > I am interested in streaming lossless audio, FLAC is probably the best > option for that. Currently the OggFLAC way of doing it mostly works > with a few hacks in libflac and my version of edcast. It might be that > the Ogg packaging layer is ill suited for this purpose, and an > alternative model developed. I've seen that its possible to stream > native flac with netcat, but thats not really the solution I'm looking > for. I have not done much work with streaming. I have written a lot of serious code that uses the FLAC library. I remember that there used to be separate objects in the FLAC library for streams, and they were unique from the file objects because you can seek backwards in a file, but you cannot seek backwards in a stream. For some reason, it seems that these objects have been removed in the latest versions of the FLAC library. Can anyone explain the issues with streaming pure FLAC? What does OggFLAC add to make streaming possible, or even easier than pure FLAC? I thought that OggFLAC was just a way to put FLAC blocks into the Ogg file format. Apple's CAF specification would also allow FLAC blocks to be placed inside their file container, although this still would not force iTunes to play FLAC unless a decoder were installed in the system. What is it about netcat that you don't like? Can you describe what you're looking for, and why the specific details are important? I was always under the impression that the FLAC format was already designed for streaming, but I must admit that I've never studied the issue. > On Fri, Jan 7, 2011 at 5:58 PM, Tor-Einar Jarnbjo ei...@jarnbjo.name> wrote: >> Am 07.01.2011 23:38, schrieb David Richards: >>> I'm also interested in another concept of lossless streaming with >>> flac. Lets call it broadcast flac. A problem with streaming for long >>> periods of time is that the sending and receiving computers >>> clocks go >>> out of sync, for example even if I stream myself on localhost, with >> >> This is not a FLAC specific problem, but has to be handled in all >> situations >> where the streaming server is in control of the transmitting data >> rate. It's >> caused by a playback device, which actual sample rate is slightly >> higher >> than the sample rate actually requested or a streaming source, >> which system >> clock is running slowly. Since these parameters (at least an exact >> playback >> sample rate) is hard to achieve, this is a rather common problem. >> Or to >> shorten it: If the data has a sample rate of 44100 and your sound >> card >> consumes more than 44100 samples per "sender-time" second, your >> buffer will >> eventually exhaust. If it's the other way around, your buffer may >> overflow >> if the client does not handle these cases properly. > > I am well aware its not flac specific, but such a standard way of > handling such a matter could be part of the packaging for streaming > flac. I think that this would be a good opportunity to design a solution that is specific to broadcast. At the sending end, the server should have knowledge of when there are breaks in the content. If the stream could send flags at these breaks, then the receiving client could go silent and reset the synchronization. As you describe, the situation only becomes a problem after long periods of time, but I would guess that there are enough station breaks (or at least song breaks) in a long broadcast that there would be a chance for a reset. CoreAudio is a pull model, and the API provides a time line that can be used to find the audio samples for a specific time. However, there are many cases where this time line gets reset. Usually, each callback has a time stamp that occurs precisely after the previous callback. Obviously, the audio should not glitch when the time line is contiguous, and thus the data must be sample-accurate. However, CoreAudio code must also deal with situations where the time line starts over from 0, usually under control of the host application. CoreAudio also has a flag in the callback to indicate when the buffers are totally silent. I'd like to borrow these ideas, or at least similarly-inspired ideas, and have FLAC streaming designed such that the stream can tell the playback software when to reset. The typical process to deal with synchronization of separate systems is sample rate conversion. However, this introduces distortion into the audio, especially with real-time SRC. The only way to avoid SRC is to have some way to reset the alignment without dropping or adding samples. As I said above, if the broadcast server were to put flags in the stream to indicate silent breaks in the audio, then the playb
Re: [Flac-dev] Synchronizing a streaming client to the server Was: Idea to possibly improve flac?
On Fri, Jan 7, 2011 at 5:58 PM, Tor-Einar Jarnbjo wrote: > Am 07.01.2011 23:38, schrieb David Richards: >> >> I'm also interested in another concept of lossless streaming with >> flac. Lets call it broadcast flac. A problem with streaming for long >> periods of time is that the sending and receiving computers clocks go >> out of sync, for example even if I stream myself on localhost, with > > This is not a FLAC specific problem, but has to be handled in all situations > where the streaming server is in control of the transmitting data rate. It's > caused by a playback device, which actual sample rate is slightly higher > than the sample rate actually requested or a streaming source, which system > clock is running slowly. Since these parameters (at least an exact playback > sample rate) is hard to achieve, this is a rather common problem. Or to > shorten it: If the data has a sample rate of 44100 and your sound card > consumes more than 44100 samples per "sender-time" second, your buffer will > eventually exhaust. If it's the other way around, your buffer may overflow > if the client does not handle these cases properly. > I am well aware its not flac specific, but such a standard way of handling such a matter could be part of the packaging for streaming flac. >> Anyway what could happen is the client could do a little bit of >> re-sampling here or there to ensure its in sync with the servers >> clock. > > That is how streaming clients usually solve this problem, although is not > really improving sound quality. Its probably not a big deal if you don't resample all the time, just when your off by X amount, all of this would just be client side preferences. As long as the client side "knows" its off by X amount you could handle it in any number of ways, I'd be fine if its just crossfaded to the correct timing if was off by more than half a second, then no resampling would ever happen, you would just get a weird effect about once an hour, better than a buffer underrun or lag, or perhaps the client could look for a half second of silence and just cut it out. -David > > Tor > > > ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
[Flac-dev] Synchronizing a streaming client to the server Was: Idea to possibly improve flac?
Am 07.01.2011 23:38, schrieb David Richards: > I'm also interested in another concept of lossless streaming with > flac. Lets call it broadcast flac. A problem with streaming for long > periods of time is that the sending and receiving computers clocks go > out of sync, for example even if I stream myself on localhost, with This is not a FLAC specific problem, but has to be handled in all situations where the streaming server is in control of the transmitting data rate. It's caused by a playback device, which actual sample rate is slightly higher than the sample rate actually requested or a streaming source, which system clock is running slowly. Since these parameters (at least an exact playback sample rate) is hard to achieve, this is a rather common problem. Or to shorten it: If the data has a sample rate of 44100 and your sound card consumes more than 44100 samples per "sender-time" second, your buffer will eventually exhaust. If it's the other way around, your buffer may overflow if the client does not handle these cases properly. > Anyway what could happen is the client could do a little bit of > re-sampling here or there to ensure its in sync with the servers > clock. That is how streaming clients usually solve this problem, although is not really improving sound quality. Tor ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
