[FFmpeg-devel] [PATCH] ALSA for libavdevice

[Nicolas George]

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

dsnoop is a plugin, the equivalent for capture to the playback-only plugin
"dmix". What they do is: they put the memory buffer of the hardware device
in a shared memory segment, thus allowing several process to
capture from / playback to the same device at the same time (which is a very
commonly wanted feature and rarely available in hardware) without the need
of a running server (like esd or artsd).

I suppose that most distributions come with a default setup that looks like
that:
                         ,-> dsnoop -.
default -> plug -> asym <             >-> hw
                         '->  dmix  -'

(asym is a plugin that can connect to a different PCM for capture and
playback; plug is a plugin that converts any input format into the nearest
possible output format)

As for me, I always set the device explicitly when I do capture, so I did
not bother to configure anything for the capture in my default chain.

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

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");

Adding more details, including a link to the bug-tracker entry, somewhere
would be nice, but I have absolutely no idea where to put it.

Regards,

-- 
  Nicolas George
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20081229/122a6e2d/attachment.pgp>