public inbox for linux-media@vger.kernel.org
 help / color / mirror / Atom feed
From: Clemens Ladisch <clemens@ladisch.de>
To: Mauro Carvalho Chehab <m.chehab@samsung.com>
Cc: Takashi Iwai <tiwai@suse.de>, Hans de Goede <hdegoede@redhat.com>,
	alsa-devel@alsa-project.org, linux-usb@vger.kernel.org,
	LMML <linux-media@vger.kernel.org>
Subject: Re: [alsa-devel] Fw: Isochronous transfer error on USB3
Date: Thu, 09 Jan 2014 13:10:08 +0100	[thread overview]
Message-ID: <52CE91A0.1010901@ladisch.de> (raw)
In-Reply-To: <20140109092957.58092c3f@samsung.com>

Mauro Carvalho Chehab wrote:
> Clemens Ladisch <clemens@ladisch.de> escreveu:
>> Mauro Carvalho Chehab wrote:
>>> 	.period_bytes_min = 64,		/* 12544/2, */
>>
>> This is wrong (if the driver doesn't install other constraints on the
>> period length, like the USB audio class driver does).
>
> Ok, how should it be estimated?

This value specifies how fast the driver can report period interrupts,
i.e., how often it can call snd_pcm_period_elapsed().  In other words,
if the application configures the device for this minimum period size,
but if it is possible for this amount of bytes to be transferred
_without_ triggering an interrupt (by reaching the end of the URB), then
this value was too low.

The em28xx driver uses a fixed URB size, so actual interrupts happen
every 64 frames, so this value should be at least the number of bytes
that can be transferred in 64 ms (assuming a full-speed device).

Because you do not know the exact number of samples that will be sent
per frame, it is possible that the USB interrupt happens up to 63 ms
after the point where the period interrupt should actually have
happened.  This jitter could be reduced by using shorter URBs.

In any case, this driver does not need the integer constraint on the
period count.


Regards,
Clemens

      parent reply	other threads:[~2014-01-09 12:10 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-01-08 18:48 Fw: Isochronous transfer error on USB3 Mauro Carvalho Chehab
2014-01-08 20:14 ` Alan Stern
2014-01-09  8:17 ` [alsa-devel] " Clemens Ladisch
2014-01-09 11:29   ` Mauro Carvalho Chehab
2014-01-09 11:31     ` Mauro Carvalho Chehab
2014-01-09 12:10     ` Clemens Ladisch [this message]

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=52CE91A0.1010901@ladisch.de \
    --to=clemens@ladisch.de \
    --cc=alsa-devel@alsa-project.org \
    --cc=hdegoede@redhat.com \
    --cc=linux-media@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=m.chehab@samsung.com \
    --cc=tiwai@suse.de \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox