Hi folks. My first post over here. While working on a music server optimzation (which ususally goes hand in hand with running pretty low buffers on realtime streams) I figured that certain HiRez flacs were causing XRUNS/hickups on my Linux server platform. The interesting thing is to run into XRUNS even though the stream gets send to a Squeezebox Touch which got a 20s buffer on its receiving end. However. Even a potentially short break of that flac decoding stream seems to cause a problem further downstream. What to do!?!? I did this and that. Nothing worked. I tested the integrity of those files. I also run them as .wav. That turned out to be OK. I'm running flac 1.2.1 on a 64bit Ubuntu server btw.. The interesting thing is that not all flacs behave the same. Some are running smooth. Others skip. Which is reproduceable. Than I found a thread discussion in the Squeezebox Server area about this very same subject. The discussed solution solution was: RE-ENCODING to alias 0. Higher compression level seemed to cause those hickups. Ok. It's not just me. I wrote a batch script and re-encoded all those flacs to alias level 0. However. The problem didn't go away in my (rather special) case. If I'm running the offline decoded .wav of those 24/96 files I do not have any problems. Hmmh. Next. I then looked up the flac formatting guide. I figured that the encoding options used by the majority of applications are just the basic aliases 0-8. What struck me was that the flac formatting guide recommends higher (whatever) blocksizes in case of >48khz HiRez files and also a residiual partition order of 2,2. Since I do not have a lot of background about the internals of the decoder. I can't make much sense out of the advanced features of the formating guide. I'd really appreciate if somebody could tell me what best options to choose for encoding HiRez flacs. My goal would be to achieve the most efficient realtime stream decoding. Probably I'd have to play with blocksize and -r. Another comment: I'm wondering if the flac formatting guide shouldn't be updated with information related to HiRes data. If the blocksize should be higher for Hirez as described in the guide there perhaps should be new aliases for Hirez material. I guess the majority out there is still using use those standard aliases which would apply for samplerates <= 48khz only. Thx a lot. Cheers Klaus -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.xiph.org/pipermail/flac-dev/attachments/20120221/05e1a54e/attachment.htm
Hi Klaus, I'm not really sure where to start with this one. Klaus Schulz wrote:> My first post over here. > > While working on a music server optimzation (which ususally goes hand in > hand with running pretty low buffers on realtime > streams) > > I figured that certain HiRez flacs were causing XRUNS/hickups on my Linux > server platform.What is a HiRez flac? How does it differ from a regular flac?> The interesting thing is to run into XRUNS even though the stream gets > send to a Squeezebox Touch which got a 20s buffer on its receiving end.XRUNS are a kernel/music player thing and not really anything to do with the FLAC library. In order to better understand this issue, you need to separate the decoding from the playback. Do you have two files, one which rarely/never displays the problem and one which usually/always displays the problem? Are you able to post those files to a public website where I can retrieve them and test them? Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/
Hi Eric. On Tue, Feb 28, 2012 at 7:57 AM, Erik de Castro Lopo <mle+la at mega-nerd.com>wrote:> Hi Klaus, > > I'm not really sure where to start with this one. > > Klaus Schulz wrote: > > > My first post over here. > > > > While working on a music server optimzation (which ususally goes hand in > > hand with running pretty low buffers on realtime > > streams) > > > > I figured that certain HiRez flacs were causing XRUNS/hickups on my Linux > > server platform. > > What is a HiRez flac? How does it differ from a regular flac? > >HireRez flac > 16/48 e.g. 24/96 flacs. Decoding demands are somewhat different from 44/16 especially if a high compression level on 24/96 is used and the file gets decoded in realtime. The subject is probably about realtime decoding efficiency. It's probably not that easy to trace this down. The flac application is used as a realtime decoder to stdout (pipe) in a typical Squeezebox server setup. As I said. People reporting ( me to) running into "hickups" when streaming e.g. level 8 24/96 hirez-flacs. Getting them down to compression level 0 solved some issues. It happened always on the some tracks. I'm not sure what happens. Perhaps a buffer underrun on the receiving end of flacs stdout stream under certain conditions. One idea that came up: When reading the flac instruction page I do have the feeling that those instructions and aliases are still made for <=16/48. The first thing that hit my eyes was the thing about different blocksizes to be used for material >=48khz. The whole world is using those standard compression level aliases which wouldn't be in line with the blocksize recommendations for HiRez. I'm wondering what the most efficient ( related to decoding performance and NOT compression factor ) parametrization for a 24/96 file would be. I'd like to give that a try.> The interesting thing is to run into XRUNS even though the stream gets > > send to a Squeezebox Touch which got a 20s buffer on its receiving end. > > XRUNS are a kernel/music player thing and not really anything to do > with the FLAC library. >I know. At least not directly. It's the pipe which breaks. The flac library ( or better the flac(.exe) applications could have some inefficiencies built in that show up on highly demanding HireZ realtime decoding.> > In order to better understand this issue, you need to separate the decoding > from the playback. Do you have two files, one which rarely/never displays > the problem and one which usually/always displays the problem? Are you > able to post those files to a public website where I can retrieve them > and test them? > >I think I'm not allowed to post them. Copyright. Is there a way to debug certain issues? Klaus Erik> -- > ---------------------------------------------------------------------- > Erik de Castro Lopo > http://www.mega-nerd.com/ > _______________________________________________ > flac-dev mailing list > flac-dev at xiph.org > http://lists.xiph.org/mailman/listinfo/flac-dev >-------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.xiph.org/pipermail/flac-dev/attachments/20120228/61efa20e/attachment.htm