[FFmpeg-devel] [PATCH] ALSA for libavdevice
Mon Dec 29 12:43:11 CET 2008
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
Thanks for your efforts. I could reproduce the problem and submit an entry
to the ALSA bug tracking system:
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
,-> 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
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
if (snd_pcm_type(s->h) != SND_PCM_TYPE_HW)
"capture with some ALSA plugins, especially dsnoop, "
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 197 bytes
Desc: Digital signature
More information about the ffmpeg-devel