alsa output problem using libmad and mpga2fixed

[curgan]

Hi All,

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?"

Cheers
Celil

[curgan]

Update

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.
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)

Am i missing something?

Code: Select all

int __vlc_thread_create( vlc_object_t *p_this, const char * psz_file, int i_line, const char *psz_name, void * ( *func ) ( vlc_object_t * ), int i_priority, bool b_wait ) { int i_ret; vlc_object_internals_t *p_priv = vlc_internals( p_this ); struct vlc_thread_boot *boot = malloc (sizeof (*boot)); if (boot == NULL) return errno; boot->entry = func; boot->object = p_this; vlc_object_lock( p_this ); /* Make sure we don't re-create a thread if the object has already one */ assert( !p_priv->b_thread ); #if defined( LIBVLC_USE_PTHREAD ) pthread_attr_t attr; pthread_attr_init (&attr); /* Block the signals that signals interface plugin handles. * If the LibVLC caller wants to handle some signals by itself, it should * block these before whenever invoking LibVLC. And it must obviously not * start the VLC signals interface plugin. * * LibVLC will normally ignore any interruption caused by an asynchronous * signal during a system call. But there may well be some buggy cases * where it fails to handle EINTR (bug reports welcome). Some underlying * libraries might also not handle EINTR properly. */ sigset_t set, oldset; sigemptyset (&set); sigdelset (&set, SIGHUP); sigaddset (&set, SIGINT); sigaddset (&set, SIGQUIT); sigaddset (&set, SIGTERM); sigaddset (&set, SIGPIPE); /* We don't want this one, really! */ pthread_sigmask (SIG_BLOCK, &set, &oldset); #ifndef __APPLE__ if( config_GetInt( p_this, "rt-priority" ) > 0 ) #endif { struct sched_param p = { .sched_priority = i_priority, }; int policy; /* Hack to avoid error msg */ if( config_GetType( p_this, "rt-offset" ) ) p.sched_priority += config_GetInt( p_this, "rt-offset" ); if( p.sched_priority <= 0 ) p.sched_priority += sched_get_priority_max (policy = SCHED_OTHER); else p.sched_priority += sched_get_priority_min (policy = SCHED_RR); pthread_attr_setschedpolicy (&attr, policy); pthread_attr_setschedparam (&attr, &p); } i_ret = pthread_create( &p_priv->thread_id, &attr, thread_entry, boot ); pthread_sigmask (SIG_SETMASK, &oldset, NULL); pthread_attr_destroy (&attr);

[Rémi Denis-Courmont]

That message comes from the decoder tread.

[curgan]

I know that my system is fast enough also libmad optimized for arch. Then what is your opinion about this problem?

[curgan]

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.
So doing this switched to old bug a need a fix for it. Any comments?

vlc/src/audio_output.c line 320

Code: Select all

/* Here we suppose that all buffers have the same duration - this is * generally true, and anyway if it's wrong it won't be a disaster. */ if ( p_buffer->start_date > start_date + (p_buffer->end_date - p_buffer->start_date)+ AOUT_PTS_TOLERANCE ) /* * + AOUT_PTS_TOLERANCE ) * There is no reason to want that, it just worsen the scheduling of * an audio sample after an output starvation (ie. on start or on resume) * --Gibalou */ { 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; }

[Jean-Baptiste Kempf]

Share on vlc-devel mailing list!