On 20.04.2016, at 23:59, Marton Balint <c...@passwd.hu> wrote: > Signed-off-by: Marton Balint <c...@passwd.hu> > --- > ffplay.c | 5 +++++ > 1 file changed, 5 insertions(+) > > diff --git a/ffplay.c b/ffplay.c > index 804bcbc..89a34d2 100644 > --- a/ffplay.c > +++ b/ffplay.c > @@ -2578,12 +2578,17 @@ static int audio_open(void *opaque, int64_t > wanted_channel_layout, int wanted_nb > static const int next_nb_channels[] = {0, 0, 1, 6, 2, 6, 4, 6}; > static const int next_sample_rates[] = {0, 44100, 48000, 96000, 192000}; > int next_sample_rate_idx = FF_ARRAY_ELEMS(next_sample_rates) - 1; > + char driver_name[32]; > > env = SDL_getenv("SDL_AUDIO_CHANNELS"); > if (env) { > wanted_nb_channels = atoi(env); > wanted_channel_layout = > av_get_default_channel_layout(wanted_nb_channels); > } > + /* By using the default dmix sample rate we should be able to avoid the > + * ALSA resampler because using it causes small buffers and underruns. */
That only makes sense if the alsa device used actually uses dmix. Plus I am generally sceptical about such a hackish workaround (in particular making assumptions on internals like default sample rate) for what sounds like an ALSA issue (assuming we can't/shouldn't just request a larger buffer or query the "native" sample rate). _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel