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
Klaus Schulz wrote:> 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.FLAC can be easily decode on very modest hardware.> The flac application is used as a realtime decoder to stdout (pipe) in a > typical Squeezebox server setup.Ok, this is suspicious. Can you reproduce the problem when not using a pipe? For instance, pipes usually have a fixed 4k buffer size and writes to a full pipe with block until the other end of the pipe is read. To test this, you could reduce the size and increase if frequency of reads on the read end of the pipe. Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/
As I understand, pipes use PIPE_BUF and that buffer varies from system to system. For example on my linux box: [BASH] ulimit -a: pipe size (512 bytes, -p) 8 Which is 4096 bytes. You can also look in /usr/include/linux/limits.h: #define PIPE_BUF 4096 /* # bytes in atomic write to a pipe */ On Thu, Dec 13, 2012 at 3:55 AM, Erik de Castro Lopo <mle+la at mega-nerd.com>wrote:> Klaus Schulz wrote: > > > 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. > > FLAC can be easily decode on very modest hardware. > > > The flac application is used as a realtime decoder to stdout (pipe) in a > > typical Squeezebox server setup. > > Ok, this is suspicious. Can you reproduce the problem when not using > a pipe? For instance, pipes usually have a fixed 4k buffer size and > writes to a full pipe with block until the other end of the pipe is > read. To test this, you could reduce the size and increase if frequency > of reads on the read end of the pipe. > > 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 >-- Jaren Stangret Computer Science Engineering/Mathematics University Of Minnesota -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.xiph.org/pipermail/flac-dev/attachments/20121213/838df790/attachment.htm
On 12/13/2012 10:55 AM, Erik de Castro Lopo wrote:> Klaus Schulz wrote: > >> 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. > FLAC can be easily decode on very modest hardware. > >> The flac application is used as a realtime decoder to stdout (pipe) in a >> typical Squeezebox server setup. > Ok, this is suspicious. Can you reproduce the problem when not using > a pipe? For instance, pipes usually have a fixed 4k buffer size and > writes to a full pipe with block until the other end of the pipe is > read. To test this, you could reduce the size and increase if frequency > of reads on the read end of the pipe. > > ErikMaybe this investigation at HA into decoding slowness and the ultimate fix/workaround is helpful: http://www.hydrogenaudio.org/forums/index.php?showtopic=98069 Christoph