[FFmpeg-devel] [PATCH] ALSA for libavdevice

Luca Abeni lucabe72
Mon Dec 29 20:01:24 CET 2008

Hi Nicolas,

On Mon, 2008-12-29 at 12:43 +0100, Nicolas George wrote:
> Le nonidi 9 niv?se, an CCXVII, Luca Abeni a ?crit :
> > Ok; since I had some non working alsa installations, I decided to have a
> > better look at this issue... I downloaded the source for the latest alsa
> > 1) It seems that my alsa library is configured to use
> > "pcm_dsnoop" (whatever it is :), whereas Nicolas is probably using
> > "pcm_hw". Now, I do not really know what "dsnoop" is, nor why my alsa is
> > trying to use it (I did not change anything in my alsa
> > configuration...).
> Thanks for your efforts. I could reproduce the problem and submit an entry
> to the ALSA bug tracking system:
> https://bugtrack.alsa-project.org/alsa-bug/view.php?id=4308

Good; thanks for taking care of this.

> >		     This is probably why Nicolas is not seeing the
> > problem I am experiencing. How can I use "pcm_hw" instead of this broken
> > dsnoop?
> I suppose you used something like "-f alsa -i ''"?

I used "-i default"

>  You just need to give as
> input the name of a PCM that does not have the dsnoop plugin in it. You
> probably want to use either "-f alsa -ac 2 -i hw" or "-f alsa -i plughw"
> (optionally with hw:42 instead of just hw if you want tu use the sound card
> #42 in your system).
> Can you confirm this works for you?

I tried "-i hw" and it worked perfectly, thanks!

> > I think that your current code is the best solution in the long term,
> > but we really need a fallback solution until alsa lib is fixed (or we
> > need to document how to use "pcm_hw" instead of "pcm_dsnoop").
> > Maybe a possible solution is to have a configure check for the presence
> > of snd_pcm_htimestamp(), and to provide some mechanism for allowing the
> > user to disable the usage of such function (if alsalib provides it, but
> > it is broken)...
> With the results of our common analysis of the problem, I do not think it is
> worth cluttering ffmpeg with workarounds for this bug: documenting that
> ffmpeg does not work with the dsnoop plugin is enough.

Yes, I now agree ;-)
We just need to document the fact that if "-i default" fails the user
should try "-i hw" or similar.

> As for where put that documentation, I am not really sure. Maybe something
> like that:
> 	if (snd_pcm_type(s->h) != SND_PCM_TYPE_HW)
> 	    av_log(s1, AV_LOG_WARNING,
> 		   "capture with some ALSA plugins, especially dsnoop, "
> 		   "may hang.\n");

Yes, this is a good idea.


More information about the ffmpeg-devel mailing list