All of lore.kernel.org
 help / color / mirror / Atom feed
From: Hans de Goede <hdegoede@redhat.com>
To: Mauro Carvalho Chehab <mchehab@redhat.com>
Cc: Devin Heitmueller <dheitmueller@kernellabs.com>,
	Linux Media Mailing List <linux-media@vger.kernel.org>
Subject: Re: Some fixes for alsa_stream
Date: Wed, 15 Jun 2011 16:35:22 +0200	[thread overview]
Message-ID: <4DF8C32A.7090004@redhat.com> (raw)
In-Reply-To: <4DF8C0D2.5070900@redhat.com>

Hi,

On 06/15/2011 04:25 PM, Mauro Carvalho Chehab wrote:
> Em 15-06-2011 10:43, Hans de Goede escreveu:

<snip>

 >> Right, because ConsoleKit ensures that devices like floppydrives, cdroms, audio cards,
 >> webcams, etc. are only available to users sitting behind the console,
 >
 > This is a wrong assumption. There's no good reason why other users can't access those
 > devices.

This is not an assumption, this is a policy decision. The policy is that devices like
audiocards and webcams should be only available to local console users / processes. To
avoid for example someone from spying upon someone else sitting behind the computer.

<snip>

>>> 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.
>
> The code is doing a negotiation, in order to find a period that are acceptable
> by both. Ok, there are other ways of doing it, but sharing the same period
> probably means less overhead.
>

This is what we call a premature optimization, there is not all that much
overhead here, and demanding that both sizes will support a share period size
may not always fly, and may likely lead to unnecessary large period sizes
and thus too much latency in some cases.

<snip>

> If you do some tests with mplayer and a few audio devices, you'll find that
> the audio performance may degrade the video streaming up to some point where
> you can't see the video stream. It is wise to offer a few options to the
> user, in order to allow workaround on that.

Since we're doing the audio from a separate thread here, and do no syncing
that cannot happen here. Also the right thing to do is to fix the code
to work under all circumstances not offer a gazillion cmdline options
and let the user figure out which ones happen to work for him.

Regards,

Hans

  reply	other threads:[~2011-06-15 14:34 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-06-14  2:01 Some fixes for alsa_stream Mauro Carvalho Chehab
2011-06-14 12:48 ` Hans de Goede
2011-06-14 13:05   ` Mauro Carvalho Chehab
2011-06-14 13:39     ` Mauro Carvalho Chehab
2011-06-14 13:47     ` Hans de Goede
2011-06-14 13:52       ` Devin Heitmueller
2011-06-14 14:17         ` Mauro Carvalho Chehab
2011-06-14 14:37           ` Hans de Goede
2011-06-14 14:45             ` Mauro Carvalho Chehab
2011-06-14 14:48               ` Devin Heitmueller
2011-06-14 15:51                 ` Mauro Carvalho Chehab
2011-06-15 13:43               ` Hans de Goede
2011-06-15 14:25                 ` Mauro Carvalho Chehab
2011-06-15 14:35                   ` Hans de Goede [this message]
2011-06-15 14:51                     ` Mauro Carvalho Chehab
2011-06-15 15:45                     ` Mauro Carvalho Chehab
2011-06-16 12:29                       ` Hans de Goede
2011-06-16 14:38                         ` Mauro Carvalho Chehab
2011-06-16 15:11                           ` Hans de Goede
2011-06-16 15:35                             ` Mauro Carvalho Chehab
2011-06-16 18:19                               ` Hans de Goede
2011-06-16 18:28                                 ` Mauro Carvalho Chehab
2011-06-15 14:36                   ` Mauro Carvalho Chehab

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4DF8C32A.7090004@redhat.com \
    --to=hdegoede@redhat.com \
    --cc=dheitmueller@kernellabs.com \
    --cc=linux-media@vger.kernel.org \
    --cc=mchehab@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.