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 <[email protected]>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 > [email protected] > http://lists.xiph.org/mailman/listinfo/flac-dev > -- Jaren Stangret Computer Science Engineering/Mathematics University Of Minnesota
_______________________________________________ flac-dev mailing list [email protected] http://lists.xiph.org/mailman/listinfo/flac-dev
