<html>

<head>

<style>

.hmmessage P

{

margin:0px;

padding:0px

}

body.hmmessage

{

font-size: 10pt;

font-family:Verdana

}

</style>

</head>

<body class='hmmessage'>

Hi All<br><br>I sent this problem to forum so copying from there to here.<br><br>MSG1<br>Using alsa as audio output i am getting a error like "audio output is

starving (39734), playing silence".We know that mp3(libmad) decoding is

in mpga2fixed filter.My questions re "Which thread handle this

filter?Decoder or Alsa?" ,"What should i do for to fix this issue?"<br><br>MSG2<br>Update <br><br>I also checked pthread code for priority settings. From

this code if you don't give "-rt-priority" option it seems all threads

will have same priority.<br>So all threads will be prioritized by their

own work. Input (disk access speed or network access or etc.) ,

Decoder(fixed-floating math time) , output(alsa buffersizes ,consume

speed)<br><br>Am i missing something?<br><br><code>int __vlc_thread_create( vlc_object_t *p_this, const char * psz_file, int i_line,<br>                         const char *psz_name, void * ( *func ) ( vlc_object_t * ),<br>                         int i_priority, bool b_wait )<br>{<br>    int i_ret;<br>    vlc_object_internals_t *p_priv = vlc_internals( p_this );<br><br>    struct vlc_thread_boot *boot = malloc (sizeof (*boot));<br>    if (boot == NULL)<br>        return errno;<br>    boot->entry = func;<br>    boot->object = p_this;<br><br>    vlc_object_lock( p_this );<br><br>    /* Make sure we don't re-create a thread if the object has already one */<br>    assert( !p_priv->b_thread );<br><br>#if defined( LIBVLC_USE_PTHREAD )<b

 r>    pthread_attr_t attr;<br>    pthread_attr_init (&attr);<br><br>    /* Block the signals that signals interface plugin handles.<br>     * If the LibVLC caller wants to handle some signals by itself, it should<br>     * block these before whenever invoking LibVLC. And it must obviously not<br>     * start the VLC signals interface plugin.<br>     *<br>     * LibVLC will normally ignore any interruption caused by an asynchronous<br>     * signal during a system call. But there may well be some buggy cases<br>     * where it fails to handle EINTR (bug reports welcome). Some underlying<br>     * libraries might also not handle EINTR properly.<br>     */<br>    sigset_t set, oldset;<br>    sigemptyset (&set);<br>    sigdelset (&set, SIGHUP);<br>    sigaddset (&am

 p;set, SIGINT);<br>    sigaddset (&set, SIGQUIT);<br>    sigaddset (&set, SIGTERM);<br><br>    sigaddset (&set, SIGPIPE); /* We don't want this one, really! */<br>    pthread_sigmask (SIG_BLOCK, &set, &oldset);<br><br>#ifndef __APPLE__<br>    if( config_GetInt( p_this, "rt-priority" ) > 0 )<br>#endif<br>    {<br>        struct sched_param p = { .sched_priority = i_priority, };<br>        int policy;<br><br>        /* Hack to avoid error msg */<br>        if( config_GetType( p_this, "rt-offset" ) )<br>            p.sched_priority += config_GetInt( p_this, "rt-offset" );<br>        if( p.sched_priority <= 0 )<br>            p.sched_priority += sched_get_priority_max (policy = SCHED_OTHER);<br>        else<br>  

           p.sched_priority += sched_get_priority_min (policy = SCHED_RR);<br><br>        pthread_attr_setschedpolicy (&attr, policy);<br>        pthread_attr_setschedparam (&attr, &p);<br>    }<br><br>    i_ret = pthread_create( &p_priv->thread_id, &attr, thread_entry, boot );<br>    pthread_sigmask (SIG_SETMASK, &oldset, NULL);<br>    pthread_attr_destroy (&attr)<br><br>MSG3<br></code>I know that my system is fast enough also libmad optimized for arch. Then what is your opinion about this problem?<br><br>MSG4<br>if i re-added "AOUT_PTS_TOLERANCE" to if block problem fixed while

playing song.But at start of song audio is choppy now. A old bug cause

a new bug.<br>So doing this switched to old bug a need a fix for it. Any comments?<br><br>vlc/src/audio_output.c line 320<br><code>    /* Here we suppose that all buffers have the same duration - this is<br>     * generally true, and anyway if it's wrong it won't be a disaster.<br>     */<br>    if ( p_buffer->start_date > start_date<br>                         + (p_buffer->end_date - p_buffer->start_date)+ AOUT_PTS_TOLERANCE  )<br>    /*<br>     *                   + AOUT_PTS_TOLERANCE )<br>     * There is no reason to want that, it just worsen the scheduling of<br>     * an audio sample after an output starvation (ie. on start or on resume)<br>     * --Gibalou<br>     */<br>    {<br>    &nbsp

;   const mtime_t i_delta = p_buffer->start_date - start_date;         aout_unlock_output_fifo( p_aout );           if ( !p_aout->output.b_starving )             msg_Dbg( p_aout, "audio output is starving (%"PRId64"), "                      "playing silence", i_delta );         p_aout->output.b_starving = 1;         return NULL;     }</code> Any comments? Cheers curgan <br /><hr />check out the rest of the Windows Live™.

More than mail–Windows Live™ goes way beyond your inbox.

 <a href='http://www.microsoft.com/windows/windowslive/' target='_new'>More than messages</a></body>

</html>