[flac-dev] Flac HiRes decoding problems

[Klaus Schulz]

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