On Tue, 25 Sep 2012, Clemens Ladisch wrote:
> > I'm not completely sure how this stuff works, but I guess there should
> > be some way for an alsa client to rewind the stream, causing one or more
> > urbs to canceled and resubmitted?
>
> I'm not sure if cancelling and resubmitting iso URBs work i
Matthijs Kooijman wrote:
> I guess that just raising nrpacks by itself is not enough to make this
> work, since that creates a very big buffer that alsa clients can't
> touch, causing a big minimum latency.
Indeed.
> I'm not completely sure how this stuff works, but I guess there should
> be some
On Mon, 24 Sep 2012, Matthijs Kooijman wrote:
> Regardless of this, I'm still wondering if increasing the queue size
> would make sense, especially from a interrupts per second / power usage
> point of view. However, increasing MAX_QUEUE is not enough here: It only
> causes more urbs of 8 ms/urb t
Hi Alan,
On Sat, Sep 15, 2012 at 11:03:39AM -0400, Alan Stern wrote:
> On Sat, 15 Sep 2012, Matthijs Kooijman wrote:
>
> > Hi folks,
> >
> > I've spent some time this week trying to debug frequent hiccups in my
> > audio playback, on my USB sound card. The short version is that it seems
> > the
On Sat, 15 Sep 2012, Matthijs Kooijman wrote:
> Hi folks,
>
> I've spent some time this week trying to debug frequent hiccups in my
> audio playback, on my USB sound card. The short version is that it seems
> the 24 ms worth of queued URBs is not enough, since the urb complete handler
> is freque
Hi folks,
I've spent some time this week trying to debug frequent hiccups in my
audio playback, on my USB sound card. The short version is that it seems
the 24 ms worth of queued URBs is not enough, since the urb complete handler
is frequently called too late and sometimes more than 16ms (plus 8ms