On 10/11/06, Clemens Ladisch [EMAIL PROTECTED] wrote:
If you don't want to 'throw away' the samples that should have been
played during the underrun but instead want to play them (and all
following samples) later, call snd_pcm_forward() to skip over some part
of the buffer.
OK, I had assumed
Christopher Monty Montgomery wrote:
On 10/9/06, Clemens Ladisch [EMAIL PROTECTED] wrote:
Christopher Monty Montgomery wrote:
Hrm. that's non-atomic and as such involves a race and is not
reliable. Or am I missing something in the API? Does the xrun staus
persist until read?
The
On 10/9/06, Alan Stern [EMAIL PROTECTED] wrote:
On Mon, 9 Oct 2006, Christopher Monty Montgomery wrote:
On 10/9/06, Alan Stern [EMAIL PROTECTED] wrote:
So you're saying if the current uframe is N when you receive an URB whose
first slot belongs in uframe N+1, then you have to reject it,
On 10/10/06, Clemens Ladisch [EMAIL PROTECTED] wrote:
You could read the delay just after the write and check that it is at
least as big as the data you've written, but this can, of course, race
in the other way. (Well, you could think of that as a safety margin ...)
The race is more
On Tue, 10 Oct 2006, Christopher Monty Montgomery wrote:
What happens if, when you're done filling, the clock is exactly at the
slot? Unless you wait for the clock to move past the slot, you can't know
whether or not the slot will end up being processed. But you can't wait
during a
On 10/8/06, Alan Stern [EMAIL PROTECTED] wrote:
On Sun, 8 Oct 2006, Christopher Monty Montgomery wrote:
On 10/8/06, Alan Stern [EMAIL PROTECTED] wrote:
No, I'm just pointing out that it's not always possible to tell at
submission time whether the submission was made early enough.
On Monday 09 October 2006 7:18 am, Christopher Monty Montgomery wrote:
since most of the submissions
will be happening inside the interrupt handler and thus will be
running un-preemptible (am I correct here?).
IRQ handlers can be preempted for real in some realtime kernels,
where
On Mon, 9 Oct 2006, Christopher Monty Montgomery wrote:
But suppose you look at the clock and the clock isn't definitive one way
or the other?
Well, the clock would be definitive, just pessimistic. The worst case
is being too pessimistic by 125uSec, since most of the submissions
will be
On 10/9/06, Alan Stern [EMAIL PROTECTED] wrote:
So you're saying if the current uframe is N when you receive an URB whose
first slot belongs in uframe N+1, then you have to reject it, right?
No, that we try to fill the slot and if the clock is at/past the slot
when we're done filling, look to
On Sunday 08 October 2006 4:51 pm, [EMAIL PROTECTED] wrote:
When sample and playback are lockstep (read 64 samples, process, write
them for playback, read next 64 samples, process, write them for
playback), we will only ever be one URB deep.
Can't be guaranteeed. Never use less than two
On 10/9/06, David Brownell [EMAIL PROTECTED] wrote:
The gap is inherent in having let the stream empty. Once that happens,
given IRQ latencies there aren't many good controls over how much of
a gap exists. The original notion of SLOP would not have kicked in
there ... if your patches added
Christopher Monty Montgomery wrote:
On 10/6/06, Alan Stern [EMAIL PROTECTED] wrote:
According to Clemens, snd-usb-audio can be configured to use or to not use
dummy data, by the application. If it's doing the wrong thing your
application is therefore at fault.
If it uses dummy data, it
But the root cause is still that streaming ISO with just one URB is
not a viable approach ... the driver on top of usbcore was doing the
wrong thing.
I understand now that's the fundamental Linux design, but only Linux
seems to implement it this way. MacOSX can do 2ms sample/play
On 10/9/06, Clemens Ladisch [EMAIL PROTECTED] wrote:
Christopher Monty Montgomery wrote:
On 10/6/06, Alan Stern [EMAIL PROTECTED] wrote:
According to Clemens, snd-usb-audio can be configured to use or to not use
dummy data, by the application. If it's doing the wrong thing your
On 10/9/06, David Brownell [EMAIL PROTECTED] wrote:
Really? With URBs having 1 uframe periodicity?? I doubt it.
Maybe with ones having 1 frame (8 uframe) periodicity; in those
cases the system will often be fast enough.
Ah, no, one frame (8 uframe), not one uFrame.
Monty
Alan Stern wrote:
[...]
To satisfy the requirements, a driver only needs to make sure that the
stream never starves. It can easily do so, regardless of whether it
has any data available to send. It can even submit 0-length ISO URBs,
if need be, just to keep the stream alive.
Several USB
On 10/9/06, Clemens Ladisch [EMAIL PROTECTED] wrote:
Alan Stern wrote:
[...]
To satisfy the requirements, a driver only needs to make sure that the
stream never starves. It can easily do so, regardless of whether it
has any data available to send. It can even submit 0-length ISO URBs,
Christopher Monty Montgomery wrote:
On 10/9/06, Clemens Ladisch [EMAIL PROTECTED] wrote:
Christopher Monty Montgomery wrote:
If it uses dummy data, it never reports the xrun.
In that case, it cannot report the xrun immediately because returning an
error code from snd_pcm_write() (or
On 10/9/06, Clemens Ladisch [EMAIL PROTECTED] wrote:
Christopher Monty Montgomery wrote:
Hrm. that's non-atomic and as such involves a race and is not
reliable. Or am I missing something in the API? Does the xrun staus
persist until read?
The delay gets smaller when the device reads
On Mon, 9 Oct 2006, Christopher Monty Montgomery wrote:
On 10/9/06, Alan Stern [EMAIL PROTECTED] wrote:
So you're saying if the current uframe is N when you receive an URB whose
first slot belongs in uframe N+1, then you have to reject it, right?
No, that we try to fill the slot and if
For example, let's say an URB is submitted for slot S, just as S's
microframe is starting. ehci-hcd adds the URB into the hardware schedule;
was it in time for the controller to see it?
Right now, that attempt would be outright rejected. ehci-sched will
not (and never would) schedule into
On 10/8/06, Christopher Monty Montgomery [EMAIL PROTECTED] wrote:
Right now, that attempt would be outright rejected. ehci-sched will
not (and never would) schedule into the currently active frame. In
fact, it would not schedule into any frame within 'SCHEDULE_SLOP' of
the active frame. I
On Sun, 8 Oct 2006, Christopher Monty Montgomery wrote:
No way to know until the
microframe is finished. The only way ehci-hcd can make an accurate report
in this case is to _always_ report that the slot was missed -- not even
_try_ to add it into the hardware schedule -- even if it
On 10/8/06, Alan Stern [EMAIL PROTECTED] wrote:
On Sun, 8 Oct 2006, Christopher Monty Montgomery wrote:
[or are you worried about caching and propogation of changes?]
No, I'm just pointing out that it's not always possible to tell at
submission time whether the submission was made early
On 10/8/06, Alan Stern [EMAIL PROTECTED] wrote:
No, I'm just pointing out that it's not always possible to tell at
submission time whether the submission was made early enough.
Is that actually true? If the slot is filled, we look at the clock,
and the clock says definitively that the filled
On Sun, 8 Oct 2006, Christopher Monty Montgomery wrote:
I don't like the idea of having two separate pathways for reporting the
same kind of error. If one reporting technique is reliable and another
isn't, why keep the unreliable one?
When one can say 'the underrun is happening now' and
On Sun, 8 Oct 2006, Christopher Monty Montgomery wrote:
On 10/8/06, Alan Stern [EMAIL PROTECTED] wrote:
No, I'm just pointing out that it's not always possible to tell at
submission time whether the submission was made early enough.
Is that actually true? If the slot is filled, we look
On Fri, 6 Oct 2006, Christopher Monty Montgomery wrote:
On 10/6/06, Alan Stern [EMAIL PROTECTED] wrote:
I don't know the details of ehci-hcd, but this may well be unfeasible. It
would require checking the status of previous submissions every time a new
submission is made, which might be
On Sat, 7 Oct 2006, Christopher Monty Montgomery wrote:
Let's establish how to report missed slots, I'll update the patches,
and then try to figure out what's going on with usbaudio.
Okay, let's move on to discuss this. Part of the problem with our earlier
discussion has been that there are
On Saturday 07 October 2006 11:49 am, Alan Stern wrote:
On Fri, 6 Oct 2006, Christopher Monty Montgomery wrote:
On 10/6/06, Alan Stern [EMAIL PROTECTED] wrote:
I don't know the details of ehci-hcd, but this may well be unfeasible. It
would require checking the status of previous
Alan Stern wrote:
On Thu, 5 Oct 2006, Christopher Monty Montgomery wrote:
Are overrun and underrun synonyms here?
Sorry, a persistent thinko. s/overrun/underrun/g.
Except when doing input. In ALSA, we just call them xruns. :-)
What happens when, eg, an application does not submit more
Christopher Monty Montgomery wrote:
I *must* be able to trust that an isoch stream will not randomly crash
and burn unrecoverably. A stutter is bad enough, but having the only
underrun behavior be 'Oops! Sorry! You lose!' is not acceptable, and
I don't care how 'correct' it is to have a
On Thu, 5 Oct 2006, Christopher Monty Montgomery wrote:
On 10/5/06, Alan Stern [EMAIL PROTECTED] wrote:
The intent is that endpoint_disable is called upon close(); in my
testing (and from the code I read), close would in fact always result
in an endpoint_disable.
No, it doesn't.
On Fri, 6 Oct 2006, Clemens Ladisch wrote:
Christopher Monty Montgomery wrote:
I *must* be able to trust that an isoch stream will not randomly crash
and burn unrecoverably. A stutter is bad enough, but having the only
underrun behavior be 'Oops! Sorry! You lose!' is not acceptable, and
On 10/6/06, Alan Stern [EMAIL PROTECTED] wrote:
In my primary use case, the endpoint will lose its bandwidth
reservation,
What makes you think that?
Bandwidth fragmentation. If we release an ISO stream's bandwidth from
the middle of a schedule frame, we cannot currently recover the hole.
On 10/6/06, Clemens Ladisch [EMAIL PROTECTED] wrote:
Except when doing input. In ALSA, we just call them xruns. :-)
Yes, that is the better term.. I should be using it.
All three choices are possible, depending on how the application has
configured the device. Either application xruns get
On 10/6/06, Clemens Ladisch [EMAIL PROTECTED] wrote:
In the case of ALSA, it's the application's choice whether an underrun
should stop the stream.
Yes, I agree the application should have such a choice.
I had noticed, though, that I either never see underruns, or when an
underrun happens,
On 10/6/06, Christopher Monty Montgomery [EMAIL PROTECTED] wrote:
On 10/6/06, Alan Stern [EMAIL PROTECTED] wrote:
You still don't seem to understand. Kernel latency by itself _cannot_
cause a bandwidth reservation to be lost.
I call bullshit. A single well-placed printk inside the
On 10/6/06, Alan Stern [EMAIL PROTECTED] wrote:
On Fri, 6 Oct 2006, Clemens Ladisch wrote:
In the case of ALSA, it's the application's choice whether an underrun
should stop the stream. I don't know which application you were using,
but in the case of Jack, it was decided that it would be
On 10/6/06, Christopher Monty Montgomery [EMAIL PROTECTED] wrote:
NetBSD does not revoke bandwidth on XRUN.
BTW, I realize that NetBSD is overall far more screwed with respect to
ISOCH than we are. But they don't just shut down on xrun ;-)
Monty
On Wednesday 04 October 2006 6:07 am, Clemens Ladisch wrote:
Is it possible to tell the scheduler that the iso stream has stopped/
restarted, without calling usb_set_interface()?
Yes, just let the urb queue drain. I could imagine some of the sound
drivers aren't monitoring the queue closely
On Thursday 05 October 2006 12:21 pm, Christopher Monty Montgomery wrote:
I don't know the details of how ehci-hcd used to implement this. But
waiting until endpoint_disable is wrong.
endpoint_disable is where the budget is released, which has
little/nothing to do with the hardware
On Tuesday 26 September 2006 10:00 pm, Christopher Monty Montgomery wrote:
--- a/sound/usb/usbaudio.c2006-09-26 22:10:24.0 -0400
+++ b/sound/usb/usbaudio.c2006-09-26 22:35:43.0 -0400
@@ -838,6 +838,9 @@ static int start_urbs(struct snd_usb_sub
subs-running = 1;
On Friday 06 October 2006 11:48 am, Christopher Monty Montgomery wrote:
You still don't seem to understand. Kernel latency by itself _cannot_
cause a bandwidth reservation to be lost.
I call bullshit. A single well-placed printk inside the spinlock is
enough latency to cause all the
On Fri, 6 Oct 2006, Christopher Monty Montgomery wrote:
Sorry, I just realized we've been talking about the effects of two
different xrun cases.
No, we've been talking about xrun vs. reservation loss.
Xrun type 1: 'an xrun happened in the schedule'; we missed scheduling
a slot, but not
On Fri, 6 Oct 2006, Christopher Monty Montgomery wrote:
Would it be better to add a way for the kernel to inform the application
that an xrun occurred? Although I don't know how that would work...
What is wrong with returning a loss of sync condition upon next
request? It has precedent.
On 10/6/06, David Brownell [EMAIL PROTECTED] wrote:
On Thursday 05 October 2006 12:21 pm, Christopher Monty Montgomery wrote:
endpoint_disable is where the budget is released, which has
little/nothing to do with the hardware schedule itself. Once a USB
periodic endpoint is open()ed, it
On 10/6/06, David Brownell [EMAIL PROTECTED] wrote:
Hmm, in the current EHCI scheduler, the place which returns EL2NSYNC is
arguably just a bug that should get fixed ... it even includes the
comment someday, try to reschedule.
I'll point out we did discuss this and came to a different
On Fri, 6 Oct 2006, Christopher Monty Montgomery wrote:
Processing completion of a
given periodic URB will normally involve resubmitting it, so the queue
won't drain unless the driver explicitly stops its resumbit logic.
What if the high-level driver's buffer drains? It is possible I
On Fri, 6 Oct 2006, Christopher Monty Montgomery wrote:
When my recording has gaps, but ALSA claims buffer fill never fell
below 90%, I am filled with a developer's most righteous rage. (It
happens, I'll send you some of the recordings if you care. ALSA never
threw xrun, and it's
On 10/6/06, Alan Stern [EMAIL PROTECTED] wrote:
Notice that you didn't answer the question I asked. I asked why you
thought the reservation would be lost, and you replied by explaining why
the reservation could not be recovered once it was lost. My original
question still stands.
What else
On Fri, 6 Oct 2006, Christopher Monty Montgomery wrote:
On 10/6/06, Alan Stern [EMAIL PROTECTED] wrote:
Notice that you didn't answer the question I asked. I asked why you
thought the reservation would be lost, and you replied by explaining why
the reservation could not be recovered once
On 10/6/06, Alan Stern [EMAIL PROTECTED] wrote:
It is still the case that not being able to distinguish between normal
shutdown and xrun in case 2 is scary, again because USB bandwidth
allocation is fragile. The 'xrun and shutdown are the same' is
suboptimal only because of this
On 10/6/06, Alan Stern [EMAIL PROTECTED] wrote:
Why do you say that? In principle it's possible to report loss of sync
quite easily. uhci-hcd reports it by setting
urb-iso_frame_desc[n].status to -EXDEV. It won't release the bandwidth
reservation when this happens. I don't see any reason
On Fri, 6 Oct 2006, Christopher Monty Montgomery wrote:
As you've pointed out, there are two things to distinguish.
We need to report schedule xruns, meaning, missed slots. -EXDEX in
the urb status was mentioned at some point, as was 'urb's start_frame
is out of sync from expected'. Are
On Fri, 6 Oct 2006, Christopher Monty Montgomery wrote:
On 10/6/06, Alan Stern [EMAIL PROTECTED] wrote:
Why do you say that? In principle it's possible to report loss of sync
quite easily. uhci-hcd reports it by setting
urb-iso_frame_desc[n].status to -EXDEV. It won't release the
On Friday 06 October 2006 7:47 pm, Christopher Monty Montgomery wrote:
On 10/6/06, David Brownell [EMAIL PROTECTED] wrote:
On Thursday 05 October 2006 12:21 pm, Christopher Monty Montgomery wrote:
endpoint_disable is where the budget is released, which has
little/nothing to do with the
On 10/6/06, Alan Stern [EMAIL PROTECTED] wrote:
I don't know the details of ehci-hcd, but this may well be unfeasible. It
would require checking the status of previous submissions every time a new
submission is made, which might be a considerable extra load.
ehci-sched already knows if slots
On 10/6/06, Alan Stern [EMAIL PROTECTED] wrote:
According to Clemens, snd-usb-audio can be configured to use or to not use
dummy data, by the application. If it's doing the wrong thing your
application is therefore at fault.
If it uses dummy data, it never reports the xrun. If it doesn't
On Friday 06 October 2006 8:18 pm, Alan Stern wrote:
On Fri, 6 Oct 2006, Christopher Monty Montgomery wrote:
Something, somewhere, causes the reservation to be lost.
Basically you're saying that the old driver would sometimes lose a
bandwidth reservation. I'm not disputing that.
But
On 10/6/06, Alan Stern [EMAIL PROTECTED] wrote:
Basically you're saying that the old driver would sometimes lose a
bandwidth reservation. I'm not disputing that.
But this could be a result of the way snd-usb-audio was being used, and it
could also be a result of the way ehci-hcd was
On 10/7/06, Christopher Monty Montgomery [EMAIL PROTECTED] wrote:
Conceeded.
Misspelled
Monty
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share
On 10/6/06, David Brownell [EMAIL PROTECTED] wrote:
Not a good analogy. More accurate would be a jigsaw puzzle ... because
you can pull a piece out of the middle, and then safely put it back in
the same place.
I chose my analogy carefully. If we were doing better than we're
doing right now,
On 10/4/06, Clemens Ladisch [EMAIL PROTECTED] wrote:
I guess sox trips this because it opens the device, sets some sample
formats to check which are available, and then resets the device without
playing any data. (Many applications using the OSS API do this.)
Ah, that is indeed plausible.
On 10/5/06, Alan Stern [EMAIL PROTECTED] wrote:
Bandwidth is allocated in the USB budget as soon as the first URB of a
stream is submitted. That bandwidth remains allocated until the stream is
interrupted, which happens whenever there are no URBs queued for the
endpoint and the last
[BTW, Alan, I get the impression we did some amount of talking past
each other. Some of that might be terminology.]
The scheduler, as I modified it, is actually two pieces; the budgeter
(which reserves bandwidth and makes timing decisions) and the
scheduler (which inspects the budget and
On Thu, 5 Oct 2006, Christopher Monty Montgomery wrote:
On 10/5/06, Alan Stern [EMAIL PROTECTED] wrote:
Bandwidth is allocated in the USB budget as soon as the first URB of a
stream is submitted. That bandwidth remains allocated until the stream is
interrupted, which happens whenever
On 10/5/06, Alan Stern [EMAIL PROTECTED] wrote:
The question is, how does a stream get disabled?
ehci_endpoint_disable(). As patched, that will perform the final
refcount decrement and reap the ehci_iso_stream, which will also
release the budget.
No, that's not what I said. The way it's
On Thu, 5 Oct 2006, Christopher Monty Montgomery wrote:
No, that's not what I said. The way it's supposed to work is like this:
The bandwidth is released as soon as the last completion handler callback
returns, which has nothing to do with whether or not an overrun occurred.
Are overrun
On 10/5/06, Alan Stern [EMAIL PROTECTED] wrote:
The intent is that endpoint_disable is called upon close(); in my
testing (and from the code I read), close would in fact always result
in an endpoint_disable.
No, it doesn't. endpoint_disable() happens only at a few specific times:
when an
These patches are against kernels 2.6.18 through at least 2.6.18-git7.
patch 15: This fix is not actually to ehci-hcd, but is rather a fix to
usbaudio necessitated by fixing the isoch underrun detection/reporting
in ehci. usbaudio playback nominally causes one, specific harmless
underrun in
71 matches
Mail list logo
