Hi,
On 06/14/2011 04:45 PM, Mauro Carvalho Chehab wrote:
Em 14-06-2011 11:37, Hans de Goede escreveu:
Hi,
On 06/14/2011 04:17 PM, Mauro Carvalho Chehab wrote:
Em 14-06-2011 10:52, Devin Heitmueller escreveu:
<snip>
Yes.
The default for capture is the one detected via sysfs.
The default for playback is not really hw:0,0. It defaults to the first hw: that it is not
associated with a video device.
I have a really weird idea, why not make the default output device be "default", so that
xawtv will use whatever the distro (or user if overriden by the user) has configured as
default alsa output device?
This will do the right thing for pulseaudio and not pulseaudio users alike.
Pulseaudio sucks.
<sigh> Can we stop the pulseaudio bashing please, it is not really constructive. Pulseaudio
is happily used by many people and is the default on all major distros. So we will need
to support whether you like it or not.
Also usually when people complain about pulseaudio, they are actually being bitten by
bugs elsewhere, but blame pulseaudio, because that seems to be the popular thing
to do. And in this case as usual the problem is with the alsa code in xawtv, not in
pulseaudio. The alsa code in xawtv is buggy in several places, and makes assumptions
it should not (like capture and playback device having a shared period size).
See what happens when I pass "-alsa-pb default" argument to pulseaudio:
1) ssh section. User is the same as the console owner:
ALSA lib pulse.c:229:(pulse_connect) PulseAudio: Unable to connect: Connection refused
Cannot open ALSA Playback device default: Connection refused
Right, because ConsoleKit ensures that devices like floppydrives, cdroms, audio cards,
webcams, etc. are only available to users sitting behind the console, usually this works
by setting acls on the /dev/foo nodes, so if you're logged in to the console, you can
also access those same devices over ssh, as an unintended side effect. The pulseaudio
daemon actually asks ConsoleKit if the pid on the other end of the unix domain socket
belongs to a session marked as being behind the locale console. Which an ssh session is
not. So this is fully expected.
2) console, with mmap enabled:
Alsa devices: cap: hw:1,0 (/dev/video0), out: default
Access type not available for playback: Invalid argument
Unable to set parameters for playback stream: Invalid argument
Alsa stream started, capturing from hw:1,0, playing back on default at 1 Hz with mmap enabled
write error: File descriptor in bad state
...
write error: File descriptor in bad state
As already said pulseaudio does not support mmap mode, the reason we are getting
weird errors here is due to a bug in xawtv's alsa params setting code error handling,
which leads to the I don't do mmap mode error not getting caught.
3) console, with mmap disabled:
Alsa devices: cap: hw:1,0 (/dev/video0), out: default
Alsa stream started, capturing from hw:1,0, playing back on default at 1 Hz
write error: Input/output error
...
write error: Input/output error
This is a combination of the assumption there is a shared period size between
the input device and the output device + the broken error handling.
Actually you're lucky, in my case the non proper error handling leads to a
segfault.
I've just pushed an initial set of fixes to the xawtv repo. I'm working on
another set. First thing of that set will be removing the mmap support you
added since it is worthless, quoting from the alsa API documentation:
"If you like to use the compatibility functions in mmap mode, there are
read / write routines equaling to standard read / write transfers. Using
these functions discards the benefits of direct access to memory region.
See the snd_pcm_mmap_readi(), snd_pcm_writei(), snd_pcm_readn() and
snd_pcm_writen() functions."
Note the "Using these functions discards the benefits of direct access to
memory" bit. Properly implementing mmap support is quite hard actually,
and given that we're talking audio here, and thus not large amounts of
we can live with the small memcpy overhead just fine.
On the subject of the current mmap code, it is not only not useful it
is also buggy, asking for:
snd_pcm_access_mask_set(mask, SND_PCM_ACCESS_MMAP_INTERLEAVED);
snd_pcm_access_mask_set(mask, SND_PCM_ACCESS_MMAP_NONINTERLEAVED);
snd_pcm_access_mask_set(mask, SND_PCM_ACCESS_MMAP_COMPLEX);
err = snd_pcm_hw_params_set_access_mask(handle, params, mask);
Is wrong when using snd_pcm_mmap_readi(), snd_pcm_writei(), when using those
the access mode must be SND_PCM_ACCESS_MMAP_INTERLEAVED, and not one of
the other 2.
Regards,
Hans
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
