On Thu, 29 Aug 2013, Alan Stern wrote:
On Thu, 29 Aug 2013, James Stone wrote:
On Wed, Aug 28, 2013 at 7:46 PM, Alan Stern st...@rowland.harvard.edu
wrote:
On Wed, 28 Aug 2013, Clemens Ladisch wrote:
Sorry, what I said applies more to explicit sync endpoints. When using
On 28.08.2013 20:46, Alan Stern wrote:
On Wed, 28 Aug 2013, Clemens Ladisch wrote:
Sorry, what I said applies more to explicit sync endpoints. When using
implicit sync, a playback URB is submitted for each completed capture
URB, with the number of samples per packet identical to the
On Mon, 9 Sep 2013, Daniel Mack wrote:
I gave this patch a try and I can confirm that it results in a
sigificant improvement for small sample buffers.
So feel free to add my
Tested-by: Daniel Mack zon...@gmail.com
Thanks; I'll include this when the patch is submitted.
Alan Stern
--
On Thu, 29 Aug 2013, James Stone wrote:
At 32 frames/period (reported round-trip latency 1.33ms), it starts up
but there are too many xruns for it to be usable.
After further testing (off-list), it turns out that 32 frames/period
works okay with three periods/buffer instead of two. Not
On Wed, Aug 28, 2013 at 7:46 PM, Alan Stern st...@rowland.harvard.edu wrote:
On Wed, 28 Aug 2013, Clemens Ladisch wrote:
Sorry, what I said applies more to explicit sync endpoints. When using
implicit sync, a playback URB is submitted for each completed capture
URB, with the number of
On Thu, 29 Aug 2013, James Stone wrote:
On Wed, Aug 28, 2013 at 7:46 PM, Alan Stern st...@rowland.harvard.edu wrote:
On Wed, 28 Aug 2013, Clemens Ladisch wrote:
Sorry, what I said applies more to explicit sync endpoints. When using
implicit sync, a playback URB is submitted for each
At 32 frames/period (reported round-trip latency 1.33ms), it starts up
but there are too many xruns for it to be usable.
James
On Thu, Aug 29, 2013 at 4:00 PM, Alan Stern st...@rowland.harvard.edu wrote:
On Thu, 29 Aug 2013, James Stone wrote:
On Wed, Aug 28, 2013 at 7:46 PM, Alan Stern
On Thu, 29 Aug 2013, James Stone wrote:
At 32 frames/period (reported round-trip latency 1.33ms), it starts up
but there are too many xruns for it to be usable.
Interesting. Can you try doing the same thing with just playback, no
recording? If that still gets underruns, please collect a
On Wed, 28 Aug 2013, Clemens Ladisch wrote:
Sorry, what I said applies more to explicit sync endpoints. When using
implicit sync, a playback URB is submitted for each completed capture
URB, with the number of samples per packet identical to the
corresponding capture packet, so the parameters
On Mon, Aug 26, 2013 at 7:37 PM, Alan Stern st...@rowland.harvard.edu wrote:
Clemens and everyone else:
Not having heard any responses to the patch posted last Wednesday, I
have updated and completed it. The version below is ready for testing.
Please let me know what you find.
It is not
Alan Stern wrote:
All the difficulty arises from the fact that we don't know beforehand
how many URBs will constitute an ALSA period since for playback
endpoints, the URB sizes can vary. [...]
the number of URBs per period is fixed, and the number of packets in
each URB is adjusted during
On 27.8.2013 09:19, Clemens Ladisch wrote:
The driver cannot control how many samples actually end up in a capture
packet,...
Does this reasoning apply to asynchronous playback too? I understand the
driver has some control, but has to satisfy the endpoint feedback requests.
Sorry if this is
Pavel Hofman wrote:
On 27.8.2013 09:19, Clemens Ladisch wrote:
The driver cannot control how many samples actually end up in a capture
packet,...
Does this reasoning apply to asynchronous playback too?
No.
I understand the driver has some control, but has to satisfy the endpoint
feedback
On Tue, 27 Aug 2013, Clemens Ladisch wrote:
There is no reasoning about capture endpoints.
The driver cannot control how many samples actually end up in a capture
packet, so it is possible that URBs end up being one USB frame longer
than a period, in which case the ALSA period interrupts
On Tue, 27 Aug 2013, Clemens Ladisch wrote:
Alan Stern wrote:
On Tue, 27 Aug 2013, Clemens Ladisch wrote:
The current algorithm uses very short capture URBs to ensure that _some_
URB is completed as soon as possible after a period ends.
[...]
I'd suggest to keep the old calculation for
Alan Stern wrote:
On Tue, 27 Aug 2013, Clemens Ladisch wrote:
The current algorithm uses very short capture URBs to ensure that _some_
URB is completed as soon as possible after a period ends.
[...]
I'd suggest to keep the old calculation for capture URBs. It would
make sense to use longer
Clemens and everyone else:
Not having heard any responses to the patch posted last Wednesday, I
have updated and completed it. The version below is ready for testing.
Please let me know what you find.
It is not very different from the previous version. I got rid of the
nrpacks module
On Wed, 14 Aug 2013, Clemens Ladisch wrote:
In other words, there should be enough URBs so that an entire ALSA
buffer can be queued at any time, subject only to the limit on the
maximum number of URBs and packets.
The URB queue adds latency, so it should never be made too big, even
for
Alan Stern wrote:
On Tue, 13 Aug 2013, Clemens Ladisch wrote:
The difference is that this version tries always to keep a period's
worth of bytes in the USB hardware queue.
Having truncated URBs is possible only when URBs are shorter than one
period,
No. URBs are truncated when a
On Tue, 13 Aug 2013, Daniel Mack wrote:
Does this seem reasonable?
I think so, yes. But I'd like to comment on the actual patch, and also
give it a try first of course. It took me some days to gather my setup
again, but if you send a revised version, I hope to be able to test it
in the
Alan Stern wrote:
On Mon, 12 Aug 2013, Alan Stern wrote:
Here's a revised version of the patch (still untested). The difference
is that this version tries always to keep a period's worth of bytes in
the USB hardware queue. This will provide better protection against
underruns when the
On Tue, 13 Aug 2013, Daniel Mack wrote:
Hi Alan,
On 13.08.2013 23:06, Alan Stern wrote:
On Mon, 12 Aug 2013, Alan Stern wrote:
On Mon, 12 Aug 2013, Takashi Iwai wrote:
So... Clemens, Daniel, Eldad, could you guys review the latest version
of Alan's patch? I'd love to sort this
On Mon, 12 Aug 2013, Alan Stern wrote:
On Mon, 12 Aug 2013, Takashi Iwai wrote:
So... Clemens, Daniel, Eldad, could you guys review the latest version
of Alan's patch? I'd love to sort this out for 3.12.
Here's a revised version of the patch (still untested). The difference
is that
Hi Alan,
On 13.08.2013 23:06, Alan Stern wrote:
On Mon, 12 Aug 2013, Alan Stern wrote:
On Mon, 12 Aug 2013, Takashi Iwai wrote:
So... Clemens, Daniel, Eldad, could you guys review the latest version
of Alan's patch? I'd love to sort this out for 3.12.
Here's a revised version of the patch
Alan Stern wrote:
On Mon, 12 Aug 2013, Takashi Iwai wrote:
So... Clemens, Daniel, Eldad, could you guys review the latest version
of Alan's patch? I'd love to sort this out for 3.12.
Here's a revised version of the patch (still untested).
- maxsize = ((ep-freqmax + 0x) *
At Thu, 1 Aug 2013 13:37:45 -0400 (EDT),
Alan Stern wrote:
On Mon, 29 Jul 2013, Clemens Ladisch wrote:
Alan Stern wrote:
Clemens remarked some time ago that keeping the queue full would be
trivial, if only he knew how full it needed to be. The answer to that
is given above. I
On Mon, 12 Aug 2013, Takashi Iwai wrote:
Here's what I've got. In turns out the predicting the optimum number
of URBs needed is extremely difficult. I decided it would be better to
make an overestimate and then to submit URBs as needed, rather than
keeping all of them active all the
At Mon, 12 Aug 2013 10:53:36 -0400 (EDT),
Alan Stern wrote:
On Mon, 12 Aug 2013, Takashi Iwai wrote:
Here's what I've got. In turns out the predicting the optimum number
of URBs needed is extremely difficult. I decided it would be better to
make an overestimate and then to submit
On Mon, 12 Aug 2013, Takashi Iwai wrote:
So... Clemens, Daniel, Eldad, could you guys review the latest version
of Alan's patch? I'd love to sort this out for 3.12.
Here's a revised version of the patch (still untested). The difference
is that this version tries always to keep a period's
On Tue, 30 Jul 2013, Takashi Iwai wrote:
At Mon, 29 Jul 2013 21:23:15 +0200,
Daniel Mack wrote:
On 29.07.2013 20:20, Alan Stern wrote:
data_ep_set_params() checks snd_usb_endpoint_implicit_feedback_sink()
in three places. It looks like only the second place is correct.
Can
On Mon, 29 Jul 2013, Clemens Ladisch wrote:
Alan Stern wrote:
Clemens remarked some time ago that keeping the queue full would be
trivial, if only he knew how full it needed to be. The answer to that
is given above. I have been trying to make the appropriate changes,
but I'm not
At Mon, 29 Jul 2013 21:23:15 +0200,
Daniel Mack wrote:
On 29.07.2013 20:20, Alan Stern wrote:
data_ep_set_params() checks snd_usb_endpoint_implicit_feedback_sink()
in three places. It looks like only the second place is correct.
Can you verify whether the other two are right, and
At Thu, 25 Jul 2013 10:50:49 -0400 (EDT),
Alan Stern wrote:
On Thu, 25 Jul 2013, Takashi Iwai wrote:
Besides, what's the reason for allocating 10 URBs if you're not going
to submit more than 2 of them at a time?
I don't know how you deduced 10 urbs in your example,
I made it
On Mon, 29 Jul 2013, Takashi Iwai wrote:
The existing code has a problem: Under some conditions the URB queue
will be too short. EHCI requires at least 10 microframes on the queue
at all times (even when an URB is completing and is therefore no longer
on the queue) to avoid underruns.
On Mon, 29 Jul 2013, Clemens Ladisch wrote:
Alan Stern wrote:
Clemens remarked some time ago that keeping the queue full would be
trivial, if only he knew how full it needed to be. The answer to that
is given above. I have been trying to make the appropriate changes,
but I'm not
On 29.07.2013 20:20, Alan Stern wrote:
data_ep_set_params() checks snd_usb_endpoint_implicit_feedback_sink()
in three places. It looks like only the second place is correct.
Can you verify whether the other two are right, and explain to me if
they are?
Which version are you looking at?
On Mon, 29 Jul 2013, Daniel Mack wrote:
On 29.07.2013 20:20, Alan Stern wrote:
data_ep_set_params() checks snd_usb_endpoint_implicit_feedback_sink()
in three places. It looks like only the second place is correct.
Can you verify whether the other two are right, and explain to me if
At Wed, 24 Jul 2013 11:43:58 -0400 (EDT),
Alan Stern wrote:
On Wed, 24 Jul 2013, Takashi Iwai wrote:
I don't understand. Consider a simple playback example. Suppose the
user wants to keep the latency low, so he requests 2 periods per
buffer. snd-usb-audio ignores this value and
On Thu, 25 Jul 2013, Takashi Iwai wrote:
Besides, what's the reason for allocating 10 URBs if you're not going
to submit more than 2 of them at a time?
I don't know how you deduced 10 urbs in your example,
I made it up. :-)
but in general,
ep-nurbs is calculated so that the driver
I have been studying the data_ep_set_params() function in
sound/usb/endpoint.c. This is the routine that calculates the number
of samples and I/O requests to keep on the USB hardware queue for PCM
audio, based on the ALSA parameters.
It uses the PERIOD_BYTES parameter but not BUFFER_BYTES. In
At Wed, 24 Jul 2013 10:41:43 -0400 (EDT),
Alan Stern wrote:
I have been studying the data_ep_set_params() function in
sound/usb/endpoint.c. This is the routine that calculates the number
of samples and I/O requests to keep on the USB hardware queue for PCM
audio, based on the ALSA
At Wed, 24 Jul 2013 11:22:00 -0400 (EDT),
Alan Stern wrote:
On Wed, 24 Jul 2013, Takashi Iwai wrote:
At Wed, 24 Jul 2013 10:41:43 -0400 (EDT),
Alan Stern wrote:
I have been studying the data_ep_set_params() function in
sound/usb/endpoint.c. This is the routine that calculates
On Wed, 24 Jul 2013, Takashi Iwai wrote:
At Wed, 24 Jul 2013 10:41:43 -0400 (EDT),
Alan Stern wrote:
I have been studying the data_ep_set_params() function in
sound/usb/endpoint.c. This is the routine that calculates the number
of samples and I/O requests to keep on the USB hardware
On Wed, 24 Jul 2013, Takashi Iwai wrote:
I don't understand. Consider a simple playback example. Suppose the
user wants to keep the latency low, so he requests 2 periods per
buffer. snd-usb-audio ignores this value and decides to use 10 URBs,
which is equivalent to setting the buffer
44 matches
Mail list logo
