Re: Some fixes for alsa_stream

[Hans de Goede <hdegoede@redhat.com>]

Hi,

On 06/16/2011 04:38 PM, Mauro Carvalho Chehab wrote:
> Em 16-06-2011 09:29, Hans de Goede escreveu:

<snip>

>> Note that I've just pushed a patch set which includes rewritten period
>> / buf size negotiation and a bunch of cleanups in general. This removes
>> over 150 lines of code, while at the same time making the code more
>> flexible.
>
> You removed mmap support, but you didn't removed the alsa-mmap option at xawtv.
>

Ah, fixed.

>> It should now work with pretty much any combination of
>> input / output device (tested with a bt878 input and intel hda,
>> usb-audio or pulseaudio output).
>
> I'll run some tests later with the boards I have here.
>

Thanks.

>> I've also changed the default -alsa-pb value to "default" as we should
>> not be picking something else then the user / distro configured defaults
>> for output IMHO. The user can set a generic default in alsarc, and override
>> that on the cmdline if he/she wants, but unless overridden on the cmdline
>> we should respect the users generic default as specified in his
>> alsarc.
>
> While pulseaudio refuses to work via ssh, this is actually a very bad idea.
> Xawtv is used by developers to test their stuff, and they generally do it
> on a remote machine, with the console captured via tty port, in order to
> be able to catch panic messages.
>

I'm sure developers are quite capable of creating either an .alsarc, pass
the cmdline option, or change pulseaudio's config to accept non local console
connections.

We should try to have sane user oriented defaults, not developer oriented
defaults.

Also not all developers work the same way you do, so having a certain default
just so it matches your work flow also is a bad idea IMHO.

> For now, please revert this patch. After having pulseaudio fixed to properly
> handle the audio group, I'm ok to re-add it.
>
>> We could consider making the desired latency configurable, currently
>> I've hardcoded it to 30 ms (was 38 with the old code on my system) note
>> that I've chosen to specify the latency in ms rather then in a number
>> of samples, since it should be samplerate independent IMO.
>
> Yeah, having latency configurable sounds a good idea to me.

Done.

Regards,

Hans