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
> > wrote:
> > > On Wed, 28 Aug 2013, Clemens Ladisch wrote:
> > >
> > >> Sorry, what I said applies more to explicit sync endpoints. When using
> > >> implicit
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
Thanks; I'll include this when the patch is submitted.
Alan Stern
--
To unsubscri
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 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 surpr
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 us
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 wrote:
> On Thu, 29 Aug 2013, James Stone wrote:
>
>> On Wed, Aug 28, 2013 at 7:46 PM, Alan Stern
>> wrote:
>> > On Wed, 28
On Thu, 29 Aug 2013, James Stone wrote:
> On Wed, Aug 28, 2013 at 7:46 PM, 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
On Wed, Aug 28, 2013 at 7:46 PM, 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 ident
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 paramet
Alan Stern wrote:
> 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 sugge
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 u
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 c
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 interrupt
On Tue, 27 Aug 2013, James Stone wrote:
> This does not help at all with running jackd at lower latencies.
>
> With this patch, I get xruns at 128 frames/period or less with jackd
> (accompanied by iso underrun messages), whereas with vanilla 3.10.9
> (which now has both yours and Clemen's patche
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
> f
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
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
On Mon, Aug 26, 2013 at 7:37 PM, Alan Stern 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 very different from t
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 paramet
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, eve
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 wh
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
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 lo
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 t
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) * (f
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 versio
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
> i
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 wo
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
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
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
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.
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
33 matches
Mail list logo
